<eleanor-nb>
I'm trying to cast a union whose variants are all 32-bit packed structs to a u32, but the tag is part of it in safe builds and it ends up being size 5. Anyone know how to extract just the payload?
<Snektron>
You could make it extern
<Snektron>
That removes the tag even in safe builds, and gives it a defined layout
<pixelherodev>
Alternately, you can get the specific type and cast that
<pixelherodev>
e.g. if it's a union(enum) of a and b, where a and b are both 32-bit packed structs, you could do something like `switch (val) { .a => |v| @bitCast(u32, v)...}`
<eleanor-nb>
Extern did not work. Will try switch.
<pixelherodev>
the "fix" here is to get stage2 finished :P
<ky0ko_>
is there an easy way that i can grab things like the target arch, host os, and build date as strings in zig
ur5us has joined #zig
eleanor-nb has quit [Remote host closed the connection]
klltkr has quit [Ping timeout: 246 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
KoljaKube has quit [Ping timeout: 260 seconds]
klltkr has joined #zig
klltkr has quit [Ping timeout: 240 seconds]
ky0ko_ has quit [Remote host closed the connection]
<daurnimator>
ky0ko: build date is evil
cole-h has joined #zig
marnix has joined #zig
<andrewrk>
holy pull requests, batman!
<andrewrk>
ya'll have been busy today
<andrewrk>
pixelherodev, yes that's exactly right
<andrewrk>
daurnimator, my personal opinion is that I'm fine with `inline` when the person has done performance testing
<andrewrk>
which it appears is the case for frank's pr
<daurnimator>
andrewrk: it didn't make a difference in release-fast; but did in release-safe
<daurnimator>
he wants to leave it in there so that release-safe is fast
<daurnimator>
is that.... reasonable?
<andrewrk>
that's good enough for me
<andrewrk>
it's possible for that to actually sabotage perf in a theoretical other implementation of the zig language, but it's also possible that it would be reasonable in all cases
<andrewrk>
it's a bit of a smell because it actually limits what the compiler is allowed to do, possibly sabotaging a really sophisticated optimizing compiler. but that's all just theoretical vaporware, and it's pretty easy to adjust the code in the future if necessary. so personally, my policy is no inline, unless you need it semantically to elide call frames, or if you've tested perf and it measurably helps
<andrewrk>
on the other hand there could be a possible argument about release-small getting worse
<andrewrk>
I think in this specific case we should let jedist1 have his preference
ur5us has quit [Ping timeout: 260 seconds]
<andrewrk>
alright I for sure need to do a pull request merging day tomorrow
marnix has quit [Ping timeout: 264 seconds]
radgeRayden has quit [Ping timeout: 272 seconds]
cole-h has quit [Quit: Goodbye]
ur5us has joined #zig
Biolunar has quit [Ping timeout: 260 seconds]
Biolunar has joined #zig
craigo has joined #zig
FireFox317 has joined #zig
Biolunar has quit [Ping timeout: 272 seconds]
Biolunar has joined #zig
kushalp has quit [Ping timeout: 260 seconds]
procnto has quit [Ping timeout: 260 seconds]
karrick has quit [Read error: Connection reset by peer]
r0bby has quit [Read error: Connection reset by peer]
kwilczynski has quit [Read error: Connection reset by peer]
tracernz has quit [Ping timeout: 260 seconds]
kwilczynski has joined #zig
kwilczynski has quit [Max SendQ exceeded]
procnto has joined #zig
kushalp has joined #zig
r0bby has joined #zig
karrick has joined #zig
kwilczynski has joined #zig
tracernz has joined #zig
ur5us has quit [Ping timeout: 244 seconds]
KoljaKube has joined #zig
dingenskirchen has joined #zig
FireFox317 has quit [Read error: Connection reset by peer]
<KoljaKube>
Is there a way to generate a function call? I have all information about the function at comptime, except the argument values.
<ifreund>
@call()?
<KoljaKube>
I can't seem to construct the tuple correctly
<ifreund>
can't really help there without some context
<ifreund>
with --release-fast it doesn't crash but instead prints garbage
<pixelherodev>
In C, if I have a struct, the address of the first member is defined as the address of the struct, so I can ptrCast between them at will - but Zig structs don't have defined layouts, right?
<pixelherodev>
andrewrk: do we have any concrete plans for an abstraction over the various allocations in link.zig?
<pixelherodev>
If not, I'm about to make the situation *worse* (TextBlock equivalent for Hex :)
<daurnimator>
pixelherodev: your first statement there is correct
<daurnimator>
pixelherodev: *however*, currently zig structs do layout in order; doing it in optimized order/adding things for debugging is an open TODO
<daurnimator>
ifreund's error message suggests to me that tuples with comptime known members get 0 runtime size
<fengb>
They do. It takes quite a bit of effort to build a dynamic tuple type
<fengb>
Gotta convince the compiler the value is not comptime known so this escapes with a "stack variable"
<pixelherodev>
daurnimator: that's not defined though.
<pixelherodev>
It's behavior that exists presently in the *compiler* which is explicitly *not* guaranteed by the language
<daurnimator>
well yeah
<daurnimator>
that's what I said
<pixelherodev>
Point being that we should act as if that's not present for now
<pixelherodev>
*Especially* within stage2 ;)
<daurnimator>
it was used as a (failed) hack around a compiler bug
<fengb>
Let’s randomize the layout :P
<daurnimator>
use one bug to fight another
<fengb>
Although that might be tricky with incremental compilation
<daurnimator>
fengb: use the buildid as a seed
<pixelherodev>
I think it's worth defining the first member as at the same address as the struct itself, and optimizing everything *else*
<pixelherodev>
There's a number of useful tricks that allows that make it easier to write cleaner code
drewr has quit [Quit: brb]
drewr has joined #zig
<pixelherodev>
A good example is with multiple struct types with a shared interface (e.g. link.File in stage2)
<pixelherodev>
If we had such a definition, its `destroy` function could become `base.deinit();base.allocator.destroy(base):` instead of a switch requiring three lines for each possible link file type
<pixelherodev>
Though the destruction might be trickier, since the size would be different...
mrhistory has quit [Remote host closed the connection]
dddddd has joined #zig
craigo has quit [Ping timeout: 240 seconds]
mrhistory has joined #zig
nycex has quit [Ping timeout: 240 seconds]
nycex has joined #zig
stripedpajamas has joined #zig
<KoljaKube>
I hate compiler crashes :-/
philtor has joined #zig
CodeSpelunker has joined #zig
xackus has quit [Ping timeout: 240 seconds]
xackus has joined #zig
SimonN has joined #zig
SimonNa has quit [Ping timeout: 256 seconds]
<pixelherodev>
ifreund, andrewrk: ping
Akuli has joined #zig
dingenskirchen has joined #zig
<ifreund>
pong
<pixelherodev>
For wasm codegen, did you handle debug info?
<pixelherodev>
s/codegen/updateDecl
<pixelherodev>
Hmm, doesn't look like it (found the PR :)
<pixelherodev>
Ah, I see what you did
<pixelherodev>
Drats, doesn't help me
<ifreund>
sorry to disappoint :P
<pixelherodev>
no worries :P
<pixelherodev>
I'm just going to end up generating debug info and then discarding it, apparently
cren has joined #zig
dongcarl has quit [Read error: Connection reset by peer]
dongcarl has joined #zig
craigo has joined #zig
cren has quit [Ping timeout: 260 seconds]
dongcarl has quit [Read error: Connection reset by peer]
dongcarl has joined #zig
dongcarl has quit [Read error: Connection reset by peer]
dongcarl has joined #zig
dongcarl has quit [Read error: Connection reset by peer]
dongcarl has joined #zig
dongcarl has quit [Read error: Connection reset by peer]
dongcarl has joined #zig
sawzall has quit [Read error: Connection reset by peer]
WilhelmVonWeiner has joined #zig
<pixelherodev>
andrewrk, ifreund, alexnask[m]: proposal, after talking with ikskuh elsewhere re: spu-ii backend. Instead of adding a HEX backend, a PE backend, a MACH-O, etc; we refactor link.File.Elf into an "abstract binary" output - that is, fully separate codegen from linking. We produce raw code + debug info into an in-memory structure, and then have a separate structure containing either ELF, PE, HEX, etc.
<pixelherodev>
This should still be doable incrementally with miniscule or no overhead, and simplifies the logic drastically. I pinged you all because IIRC you're all working on relevant components which would be affected by such work (DWARF, PE, etc)
dingenskirchen has quit [Quit: dingenskirchen]
<pixelherodev>
It means a lot of code deduplication as well, since we don't need e.g. TextBlock logic per link file type
<pixelherodev>
Thoughts?
wootehfoot has joined #zig
<ifreund[m]>
probably won’t work for wasm, from what I’ve seen of elf
<ifreund[m]>
could be a very good move for the rest though
cren has joined #zig
<ikskuh>
ifreund[m], can you explain the differences required for wasm (and thus: other target types as well)
<ikskuh>
there is also JVM and .NET formats to consider
<ikskuh>
which require even more metadata than Wasm
sawzall has joined #zig
<ifreund[m]>
well, for wasm the codegen is very closely tied to how things are laid out in the binary. Even with the indirection used for function calls many other things rely on indexes into arrays of items in the binary
<ifreund[m]>
I don’t seem a way to make a good abstraction over that way of doing things and elf
<pixelherodev>
ifreund[m]: how's that different from the GOT?
<ifreund[m]>
well, there’s no way to do indirection for globals in wasm for example
<pixelherodev>
Ahh, so you *don't* have a GOT?
<ifreund[m]>
not for everything
<ifreund[m]>
for functions there’s a way to do it
<ifreund[m]>
i have a vague idea of how we might be able to just not use globals, but not too sure about that yet
<pixelherodev>
Even if it's not good for WASM, it can still simplify ihex, PE, ELF, etc
<pixelherodev>
andrewrk, alexnask[m]: would love to hear your thoughts when you have a chance
<ifreund>
pixelherodev: so to make sure I'm clear on the proposal, the idea is to codegen into a buffer in memory and the rewrite the file on every update from this memory, saving the in-memory generated code across compilations?
<ifreund>
Thinking about this a bit more and I think it could work for wasm, we just have to be a bit smarter
<ifreund>
could actually simplify things a good deal and would certainly lead to smaller generated file sizes
<ifreund>
the idea would be that we use some custom escape sequence in the wasm codegen which we could check for when writing from the in-memory buffer to the file and replace with the proper index for that round of generation
<pixelherodev>
ifreund: for wasm, it could also separate wasm the *architecture* from wasm the *format*
<pixelherodev>
You could more tightly integrate wasm codegen with the normal pipeline
<pixelherodev>
It wouldn't be rewriting the file fully on every update
<pixelherodev>
For ELF, it would basically maintain all the info we have currently
<pixelherodev>
So it *would* still track symbol tables and such
<andrewrk>
pixelherodev, this is too complicated for IRC, if you want this idea to happen, I suggest to open a proposal on the issue tracker. the better you explain things, the better the chance of it happening
<pixelherodev>
andrewrk: makes sense, I'll do so at some point today, a bit busy with Coyote rn
<andrewrk>
fair enough
<pixelherodev>
Give me an hour or two :)
<ifreund>
pixelherodev: I'm not sure you can separate wasm the architecture from wasm the format, they are very tightly coupled
<pixelherodev>
ifreund: the more I hear about WASM, the more I wish they'd just used something like RISC-V with a custom ABI
<ifreund>
I don't think there any other format for the wasm "architecture" and you certianly cant put any random byte code in the wasm format
<pixelherodev>
Wasm byte code can still exist in a ArrayList(u8) separate from the file though
<pixelherodev>
The only thing special about wasm is the fact that people actually agreed to use it
<ifreund>
true
<pixelherodev>
Any ISA would've been good for that, if people would just agree on it
<companion_cube>
wasm doesn't have the limitations a real ISA does, does it?
<companion_cube>
like number of registers
<ifreund>
nope you get infinite
<pixelherodev>
You could also do that with e.g. LLVM IR
<companion_cube>
so it's higher level
<ifreund>
and its also inherently sandboxed
<pixelherodev>
Or any other SSA form
<companion_cube>
pixelherodev: LLVM IR is what NaCl was
<companion_cube>
and it's bad because it's unstable
<pixelherodev>
I didn't mean *literally* LLVM IR
<pixelherodev>
Of course LLVM IR is a terrible choice for it lol
<pixelherodev>
There's a reason I've largely ditched my LLVM backend
<pixelherodev>
TBH, Wasm amuses me greatly
<pixelherodev>
It's a technical solution to a social problem :P
<companion_cube>
it's great that there is such a solution
xackus has quit [Ping timeout: 256 seconds]
cren has quit [Quit: Swirc IRC client]
xackus has joined #zig
LanceThePants has joined #zig
jayschwa has joined #zig
<ifreund>
pixelherodev: your proposal is also the only way I see to reasonably apply multithreading to wasm
sawzall has quit [Ping timeout: 264 seconds]
sawzall has joined #zig
<fengb>
The web was the only place to get a bunch of devs to agree on any standard >_>
<fengb>
And by a bunch, I really just mean Emscripten + Google + Mozilla. I'm not sure how they strongarmed Safari into it
LanceThePants has quit [Ping timeout: 256 seconds]
<pixelherodev>
fengb: POSIX. SystemV. RISC-V. I can keep going :P
<Sahnvour>
andrewrk: have you had a chance to look at #5999 ?
<fengb>
None of those are widespread binary standards
<andrewrk>
Sahnvour, breifly - planning to do a deeper dive today. I agree with your conclusion that there is use for both implementations
<fengb>
I'd love to see RISCV develop further, but adoption hasn't really taken off yet
CodeSpelunker has quit [Remote host closed the connection]
CodeSpelunker has joined #zig
<Sahnvour>
okay
<companion_cube>
oh god, apparently in C you can use `-1` as a literal for an unsigned integer?
<companion_cube>
to express "all bits to one"?!
<ifreund>
companion_cube: yeah that's a common pattern
<companion_cube>
that's… horrible
<Sahnvour>
life is too short to type all those FF
<companion_cube>
(and people say C is simple, lol)
<ifreund>
it is
<ifreund>
though zig is simpler
<companion_cube>
I don't call these kinds of smartassery "simple" :p
cole-h has joined #zig
<fengb>
Simple for the bits. Your semantics be damned
<ifreund>
It's easier than counting out all the F's
<ifreund>
the semantics are simple: overflow is well defined for unsigned integers
<ifreund>
well, underflow in this case but you get the point
<ifreund>
I guess one could argue that MAX_INT or whatever should be used instead
<companion_cube>
in rust you write `!0` apparently
<ifreund>
not as nice as std.math.maxInt(u32) though
<companion_cube>
yeah, max int would be more logical
<companion_cube>
I mean, a *valid* value for the type
<jayschwa>
~0 seems clearer in my opinion
<fengb>
!0 is max?
<companion_cube>
jayschwa: yeah anyway, bitwise not
<fengb>
Ah I like ~0
<ifreund>
~0 is better indeed
<fengb>
Although... are literals defined as ints? short max isn't the same as ~int
<pixelherodev>
companion_cube: `0 - 1` is valid for unsigneds
<pixelherodev>
(in C)
<andrewrk>
~0 works in zig but you have to give an integer type
<ikskuh>
writing "~0" in c is equivalent to "-1"
<andrewrk>
~@as(T, 0)
<andrewrk>
i wish @as was syntactically cleaner
<ikskuh>
andrewrk: I think the function call syntax was cleaner
<ikskuh>
~T(0)
<ikskuh>
but i understand why it was removed
<companion_cube>
pixelherodev: 0 - 1 is not the same as `-1`
<companion_cube>
(or so I hope)
<ikskuh>
companion_cube: why should that be different?
<companion_cube>
one is a literal, a raw value; the other one is an expression
<companion_cube>
(which underflows)
<companion_cube>
so I'd say `0-1` should be allowed
<companion_cube>
but `-1` in an unsigned type is like allowing `42` in the bool type
<ikskuh>
well, for C it's the same outcome anyways
<ikskuh>
for zig as well
<ikskuh>
"0-1" is evaluated to "comptime_int -1"
<KoljaKube>
Why was the function call syntax removed? Language simplicity?
<ikskuh>
so it's the same as writing "-1"
<ikskuh>
KoljaKube: yeah, it removed the ambiguity of "func(foo)" and "cast(foo)"
<ikskuh>
soo "foo(bar)" is *always* a function cast
<KoljaKube>
Mhkay
<KoljaKube>
It *is* a bit annoying in testing.expectEqual though ;-)
<ikskuh>
yeah
<ikskuh>
i also like `as` as a binary operator:
<ikskuh>
"10 as i32"
<ifreund>
the you need parens though
<ifreund>
(10 as i32) + 5 vs @as(i32, 10) + 5
nvmd has joined #zig
<ikskuh>
same number of parens :D
<ifreund>
unless you make it super high precedence, but then it lookes weird
<ikskuh>
nah i think it should bind quite tight
<ifreund>
so 5 + 10 as i32
<ikskuh>
hm
<ikskuh>
there#s the ambiguity proposal with the operator precedence parens enforcement thingy
<ikskuh>
which would enforce parens anyways
<pixelherodev>
ikskuh: it's always a wat?
<pixelherodev>
;)
<ikskuh>
so you could do "(5 + 10) as i32" or "5 + (10 as i32)"
<pixelherodev>
"function cast" ;)
<ikskuh>
oh *facepalms*
chivay has quit [Quit: RIP]
chivay has joined #zig
<KoljaKube>
TypeInfo.ErrorUnion is the type of !foo, right?
<pixelherodev>
Not quite
<pixelherodev>
!foo *is* an error union
<pixelherodev>
TypeInfo.ErrorUnion is the type of @typeInfo(!foo) IIRC
<pixelherodev>
Or possible @typeInfo(!foo).ErrorUnion ?
<KoljaKube>
OK, yeah, I misspoke
ur5us has joined #zig
<pixelherodev>
Time for the Great Writeup.
<pixelherodev>
This will be fun
dongcarl has quit [Read error: Connection reset by peer]
dongcarl has joined #zig
dongcarl has quit [Read error: Connection reset by peer]
<pixelherodev>
andrewrk: filed as #6079 :)
CodeSpelunker has quit [Quit: CodeSpelunker]
dongcarl has joined #zig
Akuli has quit [Quit: Leaving]
st4ll1 has joined #zig
xackus has quit [Ping timeout: 260 seconds]
dongcarl has quit [Read error: Connection reset by peer]
dongcarl has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
<ifreund>
you know, it would be kinda useful to have slices with u32 len instead of usize for wasm stuff
<ifreund>
I don't like having all the @intCasts
mrhistory has quit [Remote host closed the connection]
<andrewrk>
yeah I know
<ifreund>
good news is that I fixed that problem I commented about
<ifreund>
just need to figure out how to fit my commit message summary in 50 chars then i will push it :D
dongcarl has quit [Read error: Connection reset by peer]
dongcarl has joined #zig
<fengb>
"did stuff"
<ifreund>
I guess the next thing to do is to figure out how to write wasm test cases
<ifreund>
incremental compilation works for my trivial code
<andrewrk>
nice!
<ikskuh>
\o/
<pixelherodev>
Nicely done!
<pixelherodev>
I got progress on ihex backend today, but I need to wait for the results of the proposal before I go further
<pixelherodev>
What I might do instead is work on an ELF loader so I can do SPU II work w/o an ihex backend
<pixelherodev>
Doesn't even need an *ELF* loader, really; it just needs to load from link.File.Elf
<ifreund>
how bad would it be to keep all the code generated in memory and rewrite the output file from the in memory code on each update?
<andrewrk>
ifreund, main idea there is to reduce memory usage
<companion_cube>
ifreund: sounds like a job for memory-map :p
<andrewrk>
it's very difficult to handle errors properly with memory mapping files
<ifreund>
yeah that's the downside. This would make things significantly simpler for wasm and is the only reasonable thing I've currently thought up to make multithreading possible
<andrewrk>
ifreund, that being said, even zig with llvm compiled in, stripped, is 122MiB. so maybe it's worth considering
<andrewrk>
I would be on board with exploring this approach for wasm
<ifreund>
the idea would be to do codegen in parallel inserting some custom escape sequence for function ids
<ifreund>
then write all the code to the file replacing the escape sequences with the right ids
<andrewrk>
makes sense
<ifreund>
goes for all the stuff wasm uses indexes for really, not just functions
<andrewrk>
so flush would be doing a lot of work, but mostly copying already-computed bytes
<andrewrk>
right?
<ifreund>
yeah that's right
<andrewrk>
yeah that's perfectly reasonable
<ifreund>
we'd also generate much smaller binaries
dongcarl has quit [Read error: Connection reset by peer]
<andrewrk>
if that's the case it might actually be faster compiler perf
<andrewrk>
it's planned anyway to have a way to serialize the in-memory state so that you don't have to keep the compiler alive to do incremental compilation. so this strategy I think is in line with the design
<ifreund>
yeah, there'd also be no copying around data within the output file
dongcarl has joined #zig
<andrewrk>
elf is unusually flexible; before diving into it I was expecting to have to do a strategy like you are describing, having the incrementally updated thing be a bespoke file format that zig uses
<andrewrk>
the bespoke file format being the thing that zig serializes its in-memory data between compilations
<ifreund>
yeah makes sense
<ifreund>
we could also potentially write this data to disk right away and then copy between files in low-memory situations
<andrewrk>
yep I think it's a reasonable design path to go down
<Snektron>
Whats an allocFn's len_align supposed to be when @sizeOf(T) > 1<<29?
<ifreund>
alright so I guess I'll see this initial wasm PR through to the end (just need test cases) and then I'll get to work on the redesign :D
<andrewrk>
Snektron, len_align should almost always be 0
<andrewrk>
ifreund, if you do `./zig build test-stage2 -Denable-wasmtime` then it should already be hooked up to run them
<ifreund>
oh lol, andrewrk's fancy new allocator just reminded me that I forgot to deinit() my new ArrayList
<andrewrk>
get rekt
<fengb>
I need to update zee_alloc yet again :(
<fengb>
Bit rot is real
<ifreund>
andrewrk: sweet, the challenge will just be reading and understanding the test harness then
<andrewrk>
ifreund, you might be able to just add a case to test/stage2/compare_output.zig and not really worry about the harness
<Snektron>
andrewrk: it seems like the len_align is calculated regardless
<Snektron>
For large allocations that results in an overflow
dongcarl has quit [Read error: Connection reset by peer]
<Snektron>
I'd fix it, but i don't know the exact intention
<ifreund>
andrewrk: that looks promising, do you know if I can pass args to wasmtime?
<ifreund>
right now I'm testing with wasmtime --invoke main
dongcarl has joined #zig
<andrewrk>
ifreund, rebase to after 96a27557e2ef53b8d1d3132f02c83b716c966277 which I just pushed
heitzmann has quit [Quit: WeeChat 2.9]
<ifreund>
will do
<andrewrk>
I believe that wasmtime will invoke _start by default
<andrewrk>
can you just name your function _start?
heitzmann has joined #zig
<ifreund>
oh I think you're right, will see if it also prints the return value of the function once I resolve conflicts with the macho stuff which touched adjacent lines
<andrewrk>
Snektron, hmm that's an important bug find, thanks for reporting. have you looked at the doc comments on mem.Allocator? they explain the purpose of len_align
<Snektron>
yes, but what i mean is what len_align is supposed to be for those large allocations
<Snektron>
If its fixed to always be 0, a part of the interface is lost
<pixelherodev>
andrewrk: I have no issue with waiting for you to do it :)
dongcarl has quit [Read error: Connection reset by peer]
<pixelherodev>
It does mean that ihex is on hold
<andrewrk>
Snektron, if it's a large allocation of u8 then it would be len_align=1 so no problem there
<pixelherodev>
So I *will* need to look for ELF->SPUII loader
<pixelherodev>
a good way to do a *
<Snektron>
A right, i was trying to allocate a large buffer with static size
<andrewrk>
the problematic situation we're talking about would be a struct whose abi size was greater than 1 << 29 which is pretty wild
<ifreund>
I was gonna say, that might be hard to find :D
<Snektron>
[1024][1024][1024]u8
dongcarl has joined #zig
<andrewrk>
in this case the existence of len_align is pure overhead
<andrewrk>
the only problem it is supposed to solve is allowing allocators to return more bytes than requested
<andrewrk>
but the problem is if you request an array of 10 Foos you don't want the allocator to give you 10.5 Foos back
<pixelherodev>
I mean, I'd be impressed if it did. Especially if a Foo was a u1 :P
<Snektron>
Why not? can't the extra memory be used for something else
<pixelherodev>
no
<pixelherodev>
Not really
<pixelherodev>
[10.5]u8
<pixelherodev>
??
<pixelherodev>
What are you going to use the rest of the memory for, a u4?
<Snektron>
Not in that case obviously
<pixelherodev>
you mean e.g. [10.5]u16 storing an extra u8?
<Snektron>
Hm, i suppose i'm mixing up between the user interface of an allocator and its implementation
<pixelherodev>
There's no real reason to do that though
<pixelherodev>
The cost of handling that in code would exceed any gains
<Snektron>
No, what i was thinking of was allocator A requesting memory from allocator B, where B returns extra memory which in turn can be used by A
<pixelherodev>
ahh
<Snektron>
but in that case you'd request an u8 anyway i suppose
<pixelherodev>
Huh
<pixelherodev>
That's a pretty good reason for allocators to always request u8s :P
<Snektron>
slice of u8*
<andrewrk>
len_align is irrelevant to u8s
<andrewrk>
it matters for structs which have >1 abi size
<andrewrk>
I think I should do some perf testing with ArrayList and GeneralPurposeAllocator and if removal of len_align doesn't really impact anything then it should be removed
<andrewrk>
it would be a shame to overengineer allocators for nothing
dongcarl has quit [Read error: Connection reset by peer]
dongcarl has joined #zig
<Snektron>
Its an interesting point on how to handle stuff like that
<Snektron>
I assume the main effect you want to create is returning an array close to page_size when allocating an ArrayList from a PageAllocator
<andrewrk>
yeah that was one of the motivating use cases
<Snektron>
I've thought about that before, the simplest solution i could think of involved adding a simple '
<Snektron>
'preferred size' field to the allocator
<Snektron>
But i imagine that it can benefit from having that be decided dynamically
<pixelherodev>
I'm thinking for Thor 0.2 (rewriting it now!) I should load raw RISC-V and remove the builders entirely, and take a page from stage2's book and generate machine code directly instead of overengineering and using a builder + assembler again...
<Snektron>
One situation i can imagine is having a node-based allocator return the extra space if theres some extra space left
<Snektron>
but the problem becomes how to decide to return that vs keep it and manually performing the extra allocation
<Snektron>
i mean saving that memory for other allocation calls
<pixelherodev>
allow_extra: bool
<pixelherodev>
?
<pixelherodev>
Basically, the caller tells the allocator whether the caller has a use for any extra memory
<Snektron>
Yes, but then you run into the issue of returning [10.5]Foo
<Snektron>
So i suppose thats what len_align is for now
<Snektron>
(with len_align = 0 for allow_extra = false)
<pixelherodev>
andrewrk: idea for codegen: all the various gen* functions should call genAsm with comptime-known arguments instead of generating raw bytes. This means genSetReg would turn into genAsm("mov", .{blah}) for instance
<pixelherodev>
This makes the source much more readable and removes the need for a lot of the comments that are currently in place
<pixelherodev>
Or, at the least, consolidates them all in one place
<pixelherodev>
This one I'm happy to tackle if you think it's a good idea
<andrewrk>
I'd like to avoid comptime string manipulation here
<pixelherodev>
It wouldn't really be manipulation, it'd be exact comparison (e.g. all forms of mov would have *exactly* "mov") but I see your point
<Snektron>
Wouldn't that just result in a giant switch on the name in genAsm?
<pixelherodev>
basically, yeah
<pixelherodev>
That's the idea
<Snektron>
Sounds like overengineering to me
<pixelherodev>
Not quite - this is purely for readability
<pixelherodev>
to avoid having, say, `0x49, 0x83, 0x19`
<pixelherodev>
That'd become `genAsm("blah")`
<pixelherodev>
I don't really care how we achieve it, I just think it'd be useful to make it more readable
<ifreund>
I mean, comments can go a long way
<pixelherodev>
Yes, but they're duplicated
<pixelherodev>
e.g. x64 REX comments
<ifreund>
or just a namespace filled with constants
<pixelherodev>
We do stuff like `SOME_CONSTANT | (@as(u8, reg.id()) << 3) | @as(u8, r2.id()`
<pixelherodev>
)
dongcarl has quit [Read error: Connection reset by peer]
dongcarl has joined #zig
<Snektron>
I'd extract into functions which do exactly that
<Snektron>
and just return a [N]u8
<andrewrk>
remember every problem you solve is opportunity cost for other problems
<andrewrk>
and there are some important problems left to solve in stage2
<pixelherodev>
True
jayschwa29 has joined #zig
<pixelherodev>
Are astgen structs blocked on anything?
jayschwa29 has quit [Remote host closed the connection]
dongcarl has quit [Read error: Connection reset by peer]
jayschwa has quit [Ping timeout: 245 seconds]
dongcarl has joined #zig
<ifreund>
when does link.File.file get set to null?
<ifreund>
it's happening between my test cases but not during manual incremental updates with --watch
<pixelherodev>
grep for it?
<pixelherodev>
I can look if you want
<pixelherodev>
Ahh
<pixelherodev>
It happens in makeExecutable
<pixelherodev>
It has to close it (and then set it to null) so it can be run - but makeExecutable shouldn't be called for wasm...
<pixelherodev>
ifreund: you need to change makeExecutable into a nop for wasm
<pixelherodev>
link.File.makeExecutable
<ifreund>
yeah that's totally it, thanks
<pixelherodev>
Np :)
<pixelherodev>
Always happy to help
<ifreund>
now the real question is why wasmtime outputs what I assume is floats interpreted as integers instead of formatting the float
<ifreund>
e.g. 1109917696 instead of 42.0 as a f32
<ifreund>
(it's not my code that's causing this, happens with handwritten wasm as well)
<ifreund>
and yep just checked. that's the IEEE-754 representation of 42.0 interpreted as an unsigned integer
dongcarl has quit [Read error: Connection reset by peer]
dongcarl has joined #zig
dongcarl has quit [Read error: Connection reset by peer]