<mikdusan>
elucent: I haven't seen anyone mention interest on working it
<mikdusan>
feel free to mark your interest in the issue and if you abandon it I believe you are able to edit (or even delete) your comment from the issue
<elucent>
awesome! i'll take a crack at it :)
_Vi has quit [Ping timeout: 272 seconds]
nephele_ has joined #zig
nephele has quit [Ping timeout: 272 seconds]
nephele_ is now known as nephele
Kingsquee has joined #zig
<Kingsquee>
so...what's the expected relationship between types that could be either scalar or simd backed?
<Kingsquee>
the language seems to be leaning toward @Vector(#, T), but T can only be a few base types
<Kingsquee>
I suppose anything that's not a base type would have to take on a form of T(#), with # being lane count
<Kingsquee>
and be internally specialized to lanecount=1
<daurnimator>
Kingsquee: # is not limited to just what processors support: vectors can be huge if you want
<Kingsquee>
I'm aware, but my point is that one is V(#, T) and the other is essentially T(#, V)
<daurnimator>
?
<Kingsquee>
'const f = Foo(16)' is not the same syntax as 'const f = @Vector(16, Foo)'
<daurnimator>
what is `Foo(16)`?
<Kingsquee>
Foo is type, 16 is lane count
<Kingsquee>
for base types, we describe that as @Vector(16, i32), for example
<daurnimator>
Foo is a function that returns a type you mean
<Kingsquee>
yes
<Kingsquee>
but for non-base-types, we describe it as Foo(16), with the @Vector(16, whateverbasetypeituses) internally
<daurnimator>
assuming there is a base type
<Kingsquee>
I am
<daurnimator>
Not exactly related, but you reminded me of a contributor friendly task: gimli has a vectored implementation available: someone should port it to the zig std library
<Kingsquee>
I've never been a fan of different syntaxes just for base types so this is kinda bugging me
<Kingsquee>
daurnimator: who has a what now
<Kingsquee>
(brb)
<Kingsquee>
a more concrete version of what I'm describing is a Q-format fixedpoint number
<daurnimator>
who has what now what?
<Kingsquee>
("<daurnimator> Not exactly related, but you reminded me of a contributor friendly task: gimli has a vectored implementation available: someone should port it to the zig std library")
<Kingsquee>
the most obvious description I can see for a signed version is something like Qi(Bitcount, IntegerBitcount, FractionalBitcount), but we can't do @Vector(4, Qi(8, 4,4))
<Kingsquee>
so without making a weird redundantly typed version of VectorQi, would make more sense to just add another parameter
<torque>
see the paragraph starting with "If a formatted user type contains a function of the type"
daex_ has joined #zig
<Kingsquee>
oh neat, t hanks torque
<Kingsquee>
so when ReleaseFast says "Safety checks disabled", does that include overflow checks on the '+' op
<Kingsquee>
or is that always around
<Kingsquee>
just wondering if I should spam '+%' everywhere
<Kingsquee>
hmm
<Kingsquee>
'pub fn foo(self: Q(Format), output_format: QFormat) Q(output_format) { .. }' "error: use of undeclared identifier 'output_format' (in return type)"
<mikdusan>
Kingsquee: `+%` no-safety-check in any build mode. `+` subject to build mode: on for debug,safe; off for small,fast
<mikdusan>
if your code _relies_ on overflow behavior, then use '+%' . otherwise, safety check is 👍 so use '+'
<Kingsquee>
mikdusan: interesting, thanks
<Kingsquee>
so if code _relies_ on not-overflowing, I guess it's @addWithOverflow?
<fengb>
That’s more robust yes
<fengb>
Or std.math.add if you prefer working with error unions
<Kingsquee>
mm, noted
<Kingsquee>
still confused as to why I can't pass output_format to the return fn
<mikdusan>
that's for explicit checking. what I mean with relying on overflow is... maybe you're handing out u8 numbers starting from zero. when it gets to 255, your algo actually expects i+=1 to make it 0 again
<mikdusan>
make it comptime?
<Kingsquee>
oof, yes
<mikdusan>
the error could be better; self-hosted compiler will have much more helpful errors and hints
<Kingsquee>
yeah, I understand
<Kingsquee>
so for stuff like Bit Shift Left: "b must be comptime-known or have a type with log2 number of bits as a"
<Kingsquee>
interesting that it can be comptime OR somecondition
<Kingsquee>
is that only something the compiler can do
<Kingsquee>
or is there some kinda maybecomptime logic I can write
<mikdusan>
I haven't tinkered much with shifting but maybe std.math.Log2Int and std.met.IntType can help
<mikdusan>
std.met.IntType
<mikdusan>
blah. std.meta.IntType
dddddd has quit [Ping timeout: 256 seconds]
darithorn has quit [Quit: Leaving]
daex_ has quit [Ping timeout: 256 seconds]
daex has joined #zig
ur5us has quit [Ping timeout: 265 seconds]
<Kingsquee>
hmm, yeah I see the documentation says shifting uses Log2Int
<Kingsquee>
also, is there a way to conditionally define a function based on a type-returning fn's parameter?
<z0ltan>
hey folks, i suppose the llvm+homebrew issue on macosx is going to be unresolved for a while, huh? I've reverted to an old working version (with manual CMakeLists changes) in the meantime
z0ltan is now known as antaoiseach
_Vi has joined #zig
wilsonk has joined #zig
Cogitri has quit [Quit: killed]
Cogitri has joined #zig
<Kingsquee>
...wait that's Log2T :I
antaoiseach has left #zig [#zig]
wootehfoot has joined #zig
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 258 seconds]
antaoiseach has joined #zig
Dominic[m] has joined #zig
elucent has quit [Remote host closed the connection]
dermetfan has quit [Ping timeout: 272 seconds]
xackus has quit [Read error: Connection reset by peer]
xackus has joined #zig
<antaoiseach>
so much silence
<antaoiseach>
:D
dermetfan has joined #zig
omglasers2 has joined #zig
_Vi has quit [Ping timeout: 252 seconds]
antaoiseach has left #zig [#zig]
ifreund has joined #zig
sammich_ has joined #zig
sammich_ has quit [Client Quit]
<Snektron>
Imagine if github allowed you to add code to your bug report, and then integrate that with CI which automatically tests if its still valid
<Snektron>
That would be nice
Kingsquee has quit [Quit: Konversation terminated!]
marijnfs has quit [Quit: leaving]
marijnfs has joined #zig
marijnfs has quit [Client Quit]
marijnfs has joined #zig
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
FireFox317 has joined #zig
marijnfs_ has joined #zig
daex has quit [Ping timeout: 256 seconds]
marijnfs has quit [Ping timeout: 256 seconds]
rappet has quit [Ping timeout: 246 seconds]
rappet has joined #zig
dddddd has joined #zig
<Dominic[m]>
I wonder if you could bolt that on by searching github issues for zig test blocks.
<ikskuh>
zig has both "detectable illegal behaviour" and "undetectabe illegal behaviour"
<fengb>
e.g. using uninitialized allocated memory
<pixelherodev>
Yeah
<ikskuh>
first class is captured in safe and debug mode
<pixelherodev>
but for supported types (pointer alignment, null pointer access, wrapping addition, etc), *in debug and release-safe* modes it's a crash
<grayhatter>
I'm just trying to point out, that undefined behavior is by it's very nature, ambigious... that is to say, expecting something from UB is a problem with the understanding of UB
<fengb>
There’s a task to add safety checks to everything but that’s a lofty goal
<fengb>
We’re transitioning towards calling it illegal
<fengb>
It’s only UB in release-fast / release-small modes
<pixelherodev>
and the idea is that you use the debug/safe modes to ensure there is no UB
<grayhatter>
fengb: is it actually UB though?
<pixelherodev>
It's defined as undefined
<fengb>
In release-fast yes
<pixelherodev>
;)
<fengb>
It’s the same as C
<pixelherodev>
Yeah in fast and small it's just UB
<grayhatter>
cool
<pixelherodev>
You should *always* use debug first
<grayhatter>
thanks
<pixelherodev>
Which lets you ensure your program doesn't have UB
<fengb>
In release-safe it should be safety checked and panicky
<pixelherodev>
Release-safe is for if you're rushing something to production and aren't certain you caught everything
<pixelherodev>
Release-fast/small are for, well, fast/small builds when you think it's safe to enable it
<pixelherodev>
release-safe gives you *some* speed and size advantages over debug mode without allowing in UB
<ikskuh>
release-safe is still 5 times faster than debug though
<pixelherodev>
("Release-safe is for..." <- purely my take; not official Zig stance ;)
<fengb>
Lots of speed actually. My emulator improves 30x
<pixelherodev>
True
<pixelherodev>
It's sorta like `-O2 -emit-runtime-checks` vs `-O2` as I understand it, so a lot of optimization is still performed
<fengb>
Yes, but the UB nasal demons can do some crazy stuff
<pixelherodev>
Yeah :(
<pixelherodev>
Like run Doom.
* pixelherodev
still finds that funny at least a month after first finding out about it
<fengb>
Like in safe mode, doing `catch unreachable` will add a runtime check. In fast mode, it’ll convince the optimizer this can never happen and start deleting code paths entirely
<pixelherodev>
`When GCC identified “bad” C++ code, it tried to start NetHack, Rogue, or Towers of Hanoi. Failing all three, it would just print out a nice, cryptic error message.`
<fengb>
I mean, running NetHack is a totally valid interpretation of UB
<hazeycode>
brilliant :D
<pixelherodev>
Reallllly tempted to have ZiggIRat scan for e.g. steam and run the first thing it finds
<ikskuh>
oh yeah, these were wild times :D
<pixelherodev>
but also, no.
<pixelherodev>
Or show a skull GIF
<fengb>
There should be a nasal demon emoji
<ikskuh>
Start Skullgirls
<fengb>
👺
<hazeycode>
rick astly is valid undefined behaviour
<fengb>
lol
<pixelherodev>
Ooh
<pixelherodev>
*That* I might do
<pixelherodev>
:P
<pixelherodev>
No I won't but I really want to :(
<pixelherodev>
Maybe I'll do something like `if (hostname == "pixtel")` (my laptop)
<fengb>
Embed the entire video in your executable
<fengb>
Encrypted of course
<pixelherodev>
That would be a copyright violation, I think.
<pixelherodev>
Ooh wait
<pixelherodev>
If it's encrypted, that's fair use.
<fengb>
But a license
<pixelherodev>
Definitely.
<fengb>
But
<hazeycode>
"you know the rules, and so do iiiiiiiiiii"
<fengb>
Buy
<pixelherodev>
I think I could just say "A bunch of programmers will be really really mad" and get a free license
<pixelherodev>
:P
<hazeycode>
"never gonna tell a lie, and hurt you"
<fengb>
I think it’s cheaper to get a music license. So make your own interpretation video
<pixelherodev>
Reminds me of Rust's Lovecraft panic
<hazeycode>
I mean, the song is literally about how zig treats undefined behaviour
<pixelherodev>
Ha
<pixelherodev>
That's - surprisingly accurate
<ikskuh>
C is more like " you don't know all the rules, but I do!"
<fengb>
The rules are simple: 1. That’s undefined behavior
<hazeycode>
just printing the lyrics would be amazing
<oats>
const rick = @embedFile("roll.mp4");
utzig has quit [Ping timeout: 240 seconds]
<fengb>
You forgot the encryption. rot13(rot13(@embedFile))
<oats>
lolol
<oats>
double rot13
<ikskuh>
i think rol13 is the better one
<fengb>
If triple DES makes it secure, then quadruple rot13 does too right?
<ikskuh>
sure!
<oats>
or double AES in CTR mode ¯\_(ツ)_/¯
moo is now known as wootehfoot
<oats>
ooh, I should implement AES in zig
<oats>
that would be fun
<oats>
maybe after I get the important things done today :P
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen1 has joined #zig
<fengb>
¯\_(ツ)_/¯ I just do stupid shit all day like reimplement wasm poorly
dingenskirchen1 is now known as dingenskirchen
<oats>
haha
<oats>
my kinda pasttime
return0e_ has quit [Read error: Connection reset by peer]
return0e has joined #zig
hazeycode has quit [Ping timeout: 240 seconds]
TheLemonMan has joined #zig
<TheLemonMan>
tritao, yo, are you on high sierra or something newer?
<tritao>
TheLemonMan yeah high sierra
<TheLemonMan>
tritao, what does `sysctl kern.osproductversion` return?
<tritao>
sysctl: unknown oid 'kern.osproductversion'
<mikdusan>
do we have a return discrepancy?: lib.std.os.linux.x86_64.clone() start function is `extern fn (arg: usize) u8` and man-page for libc says `int (*fn)(void *)`
<TheLemonMan>
mikdusan, the ABI doesn't really care, the u8 is usually zext'd to fill a whole reg
<mikdusan>
thx.
<TheLemonMan>
tritao, well shit, the documentation stated it was supported starting from high sierra
<mikdusan>
tritao: what is output for `sw_vers`
<TheLemonMan>
so it seems it's supported from 10.13.6 on
<tritao>
can we use `sysctl kern.osrelease`? that returns `kern.osrelease: 17.3.0`
<tritao>
`sw_vers`: ProductName:Mac OS X, ProductVersion:10.13.2, BuildVersion:17C88
<mikdusan>
maybe we should fallback to a mapping table if kern.osproductversion is not avail
<TheLemonMan>
yay one more table
<pixelherodev>
Latest microoptimization: increases performance by ~0.00224%
<pixelherodev>
Valgrind is measuring instruction fetches
<pixelherodev>
It's consistent (running the same build N times always gives the same result)
<pixelherodev>
(rebuilding again will as well, assuming deterministic optimizations)
<companion_cube>
I do think it's not very useful to optimize :D
<ikskuh>
yeah
<ikskuh>
don't optimize before your program does what it should do ;)
<pixelherodev>
Well of course :P
* ikskuh
looks at your JIT
<pixelherodev>
Here's a better one at least: 0.6%
<pixelherodev>
:)
<pixelherodev>
Had an index that was always being used as an offset to a constant
decentpenguin has joined #zig
<xackus>
if you change anything, the code layout might change completely
<pixelherodev>
Replaced that with a var initialized to the constant and replaced `index += ` with `current+addr` +=
<pixelherodev>
Now it's more than half a percent faster! Yay!
<ikskuh>
what xackus says
<ikskuh>
anything on these levels is just nise
<ikskuh>
*noise
<pixelherodev>
For beyond the current build, yes
<ikskuh>
on larger projects, it's better optimization to randomize link order and chose the best
<pixelherodev>
Not for typical Zig projects, since there's only one object file generally :)
<pixelherodev>
LTO should also mitigate that for GCC/Clang, I'd think
<pixelherodev>
(Not that I'm advocating its usage)
<mikdusan>
10.13.4 is first one to support sysctl_osproductversion
<ikskuh>
pixelherodev: yeah still things can change in-object
<ikskuh>
and no, it doesn't
<xackus>
I saw a presentation of a tool that randomizes code layout, you get a cool bell curve when you measure performance
ifreund has quit [Quit: WeeChat 2.8]
<ikskuh>
xackus: yeah saw the same talk, it explains pretty well where the problems are
<TheLemonMan>
mikdusan, what's the lowest osx version we support?
<mikdusan>
"10.13+"
<mikdusan>
you know what, I'm just going to implement reading the correct .plist file and solve this.
<TheLemonMan>
that's definitely the wrong angle to approach this problem
<TheLemonMan>
unless you like xml and plist
utzig has joined #zig
layneson has joined #zig
<mikdusan>
it's doing what apple does. the kernel value is set from the value in a .plist file at startup
<pixelherodev>
So basically, compiler optimization isn't really scientifically understood and so doing random garbage is just as likely to help as anything else?
ifreund has joined #zig
<pixelherodev>
mikdusan, 'doing what apple does' doesn't seem like a good justification IMO :P
<TheLemonMan>
I'd just get the kernel version and add a small switch to cover the 10.13 < x < 10.13.2 case
<TheLemonMan>
everything else is handled by the sane sysctl
<pixelherodev>
better than the minor performance gain: `144 insertions(+), 150 deletions(-)`
<pixelherodev>
Simpler code :)
<xackus>
it's just the butterfly effect
<mikdusan>
oh so _now_ you like tables
<pixelherodev>
The whole reason this optimization round started was because I realized I could generate a single MOV in a place I'd previously been generating two
<TheLemonMan>
I don't like mantaining up-to-date tables, see what we have to do to map Windows revisions to what's returned by the API
<TheLemonMan>
a small table for a couple of entries is fine
<pixelherodev>
Ooh, idea for an actual non-micro optimization :)
<ikskuh>
<pixelherodev> So basically, compiler optimization isn't really scientifically understood and so doing random garbage is just as likely to help as anything else?
<ikskuh>
nah, it'S quite good understood
<ikskuh>
but all optimizations are small-scale
<ikskuh>
and ignore larger effects
<ikskuh>
reordering functions in memory can greatly improve performance by using cache locality and similar effectss
<pixelherodev>
Right but, there's no way of actually predicting in advance what the actual effect will be
<pixelherodev>
(and yes that was an exaggeration)
<xackus>
I've rarely ever used a second monitor when I had a chance to
<xackus>
now I kinda want one just for irc
<ikskuh>
pixelherodev: the tool from the talk was randomizing the link order
<ikskuh>
and measures effects on every variant
<xackus>
there are also rare cases when speeding up some code can actually have an overall negative effect because of resource contention
<pixelherodev>
ikskuh, but that's my point
<pixelherodev>
It's randomizing
<ikskuh>
yes, but measuring
<ikskuh>
it's not possible to find a definite solution
<ikskuh>
#haltingproblem
<pixelherodev>
It's not measuring the code and saying "Well, we know that doing X will improve Y but make Z worse, so let's measure A and see the stacking effect of these reorders"
<pixelherodev>
There are no tools that directly measure
<pixelherodev>
Randomizing and checking the results is *not* measuring
<pixelherodev>
It's guessing and checking
<ikskuh>
it's measuring
<ikskuh>
but it's not "knowing beforehand"
<ikskuh>
because that's not possible
<ikskuh>
*all* optimizations are either heuristics (that made stuff faster in the past) or are logically deducable
<fengb>
Is there a way to inject lld options?
<sanaris>
well in PC code actually is faster or slower based on tonns of factors
<mikdusan>
fengb, with `zig build-exe` or similar? I don't think there is. but if you want to one-off experiment/troubleshoot I have a few suggestions
<sanaris>
when there is real need to create optimizations, people use special tools to clean caches and measure clocks of processors
<sanaris>
ofc these clean conditions are never met in reality
<shakesoda>
every time optimizers come up i think it'd be nice if i could just leave little love notes all over the place that the optimizer can use about the expected/desired properties of a given thing
<shakesoda>
on this note, the game i'm about to ship is severely backend/memory bound from early design decisions and it's a miracle the thing runs well enough to ship
<shakesoda>
cache behavior: middle finger emoji
<sanaris>
programs most of the time hit memory BW bottleneck and compiler/language/cpu have really nothing to do against that
<companion_cube>
shakesoda: can you elaborate? it'd be interesting to read this kind of post-morterm
<shakesoda>
yeah, it's sinister how much most regular profiling tools absolutely suck at showing you this, too
<companion_cube>
(well, post-shipping)
<fengb>
mikdusan: would it make sense to do a -mlld flag corollary to -mllvm
<shakesoda>
companion_cube: I might be able to but I'm not sure
<mikdusan>
fengb: for troubleshooting purposes would be very valuable. probably also useful for things zig doesn't support yet, but can't wait so do-it-yourself
<fengb>
Isn't that the end result of any game? "it's a miracle the thing runs well enough to ship"
<shakesoda>
a huge problem is designs based around graph processing using a lot of naive LL's to big stuff, and OO designs that hide so much work you can scarcely find the bottom
<fengb>
mikdusan: great, I'd hate to pollute the parser with a bunch of wasm only flags
<shakesoda>
the optimizer can do a lot against needing to inline the absolute hell out of things, but it can't help you from the horrid memory accesses that sneak in this way... as mentioned
<shakesoda>
just wasn't designed for this kind of load, as is tradition
<xackus>
yeah, linked lists are very cache hostile, especially without a custom allocator
<shakesoda>
another way to absolutely destroy your performance is overdoing the hashmaps
<shakesoda>
I was able to make those not hotspots anymore though
<xackus>
at least hashmaps are often a good choice, LLs almost never are
<shakesoda>
aye
<xackus>
and even if they are not the best, the damage is limited
<shakesoda>
yeah, I was able to make more than a strong enough case for getting the worst offenders refactored post-launch
<companion_cube>
shakesoda: have you an opinion on ECS? I'm hearing a lot about them in the context of rust, even though I'm not a game dev
<shakesoda>
companion_cube: yes, ecs is an absolutely wonderful tool and I've been designing my engines in ways you could describe that way for years
<companion_cube>
(I imagine you're writing C++)
<shakesoda>
i mean it's just a practical application of data oriented design, i.e. giving a shit about what the computer is actually doing
<shakesoda>
yeah, I'm dealing with C++ (yuck!!!)
<shakesoda>
I recall there being some really fancy ecs things for rust and I've got little interest in them. the ones I use in practice are almost all so simple it'd be pointless to make a library of it
utzig has quit [Ping timeout: 256 seconds]
cole-h has joined #zig
marijnfs_ has quit [Quit: Lost terminal]
<fengb>
Jon Blow has an amusing rant on ECS in Rust >_>
FireFox317 has joined #zig
<FireFox317>
Got a cross-compiled zig binary running on my mips router <3 🎉
<TheLemonMan>
*high five*
<FireFox317>
And it was so easy :O It just works™
<FireFox317>
Thanks TheLemonMan for the mipsel support in zig std. It also works for normal mips :)
<ikskuh>
FireFox317: LOL nice
<FireFox317>
Some weeks ago I put OpenWRT on the router, and i thought lets try running a zig binary on it :D
<shakesoda>
heh, i vaguely remember this rant (blow)
<fengb>
Andrew had a joke video where he pretended to rant about the rants
* mikdusan
shakes github
Akuli has joined #zig
dimenus has joined #zig
<companion_cube>
ugh, I don't have time to watch this 1h rant
<companion_cube>
so boring
<andrewrk>
it's not really that insightful either imo
<kristoff_it>
If anybody is interestered, while I wait for async/await to come to macos (:D), I'm going to stream on twitch the translation of a radix tree implementation from C to Zig. It's new stuff for me so don't expect it to be a perfect livecoding tutorial. I know what radix trees are from compsci classes but I've never implemented a serious version before.
<kristoff_it>
I'm starting 1h from now, more or less -> twitch.tv/kristoff_it
<kristoff_it>
(also if anybody knows other interesting implementations I'd be curious to compare them)
<FireFox317>
cool kristoff_it!
<TheLemonMan>
andrewrk, what about allowing `align(N)` on fields iff the structure is packed or, if it's not, only if the alignment is actually > than the minumum ABI alignment?
<andrewrk>
the goal is to prevent under-alignment?
<andrewrk>
TheLemonMan, the main purpose of the align(0) proposal, and under-alignment in general, as I see it, is for data structures that will be numerous in memory. so it is worth it for more instructions when processing the data, to save bytes in memory
<TheLemonMan>
if you care about the layout then just make it packed, no?
<andrewrk>
align(0) in non-packed structs allows to rely on the compiler to figure out where to put everything
eddyb[legacy] has quit [Max SendQ exceeded]
eddyb[legacy] has joined #zig
<FireFox317>
TheLemonMan, i pushed #5122 regarding mips support. Is the TLS stuff also correct for mips?
<TheLemonMan>
so align(0) allows for some weird-ass semi-packed/semi-regular structure types?
<TheLemonMan>
FireFox317, let me check
<TheLemonMan>
yeah, the offsets are always the same
<FireFox317>
TheLemonMan, okay thanks!
<andrewrk>
TheLemonMan, yes
<TheLemonMan>
have you tried running the test suite?
<FireFox317>
Nope, not yet. Can I somehow cross-compile the test suite too? Because this router is not powerfull enough to run the zig compiler
<TheLemonMan>
sure thing, just `zig test -target mips-linux-musl std.zig`
<andrewrk>
FireFox317, yes you can. in your zig source checkout: ./zig build test -Dskip-release -Denable-qemu
<FireFox317>
andrewrk, will do it without qemu, i can transfer the test binaries to the router i guess?
<andrewrk>
yes that will work too
<TheLemonMan>
you'll have to disable some tests though or use LLVM10 with D78011 applied
<fengb>
Alright, I have no clue how to enable arbitrary linker args
<mikdusan>
i'd like to see internal align repr better. like an optional u8 for power. when null, it is abi-align. struct can have convenience function as_bytes() or as_bits(). the power would be starting from bits. =0,1,2 mean bitalign. =3, and higher mean bytealign. and set_byte_align and set_bit_align
<andrewrk>
fengb, zig intentionally does not expose arbitrary linker args. what is your use case?
<fengb>
I want to attach --import-memory to wasm lld
<fengb>
And didn't want to pollute the general args parsing
<andrewrk>
that sounds like something that should be handled explicitly rather than as the user handing zig a black box and saying "give this mysterious black box to your backend linker component"
cole-h has quit [Quit: Goodbye]
<fengb>
Yes probably. Should it just be --import-memory to zig?
<andrewrk>
maybe --wasm-import-memory. I failed to find docs on what that does in my quick search
cole-h has joined #zig
<TheLemonMan>
andrewrk, align(0) is a special case then, what about every other N < abi-align?
<fengb>
Imports shared memory from the host env instead of owning a separate one
<andrewrk>
TheLemonMan, I see those as similar cases to align(0). for example here we can save space in an array of these: struct{ a: u64 align(4), b: u32 } but without the bit shifting of align(0)
<andrewrk>
I get that the struct alignment code is really messy and fragile and I have plans to improve that, but does it mean we need to change the language?
dingenskirchen has quit [Ping timeout: 256 seconds]
<andrewrk>
fengb, keep in mind that a non-llvm (and non-LLD) backend is planned (and in progress!)
marijnfs has joined #zig
<TheLemonMan>
again, why not `packed struct` and call it a day? if you're trying to micromanage the layout that's the best solution IMO
<andrewrk>
so you want to do align(0) on normal structs but not other kinds of under-aligning? that seems inconsistent
<mikdusan>
it's a disposition thing; defaults count and with a non-packed struct, align(0) is the exception to the rule. can be convenient
<andrewrk>
here's the current plan: structs and packed structs are the same except (1) field order is declaration order in packed structs (2) the default alignment of structs is ABI alignment; default alignment of packed struct fields is align(0)
<andrewrk>
what's the counter-proposal?
<via>
if you want to control padding and alignment in a struct, why not just do that with explicit padding? like you would with a C packed struct
dingenskirchen has joined #zig
dingenskirchen has quit [Remote host closed the connection]
<andrewrk>
here's one use case: flags. struct OpenFlags {read: bool align(0), write: bool align(0), special: enum{a,b,c,d} align(0) }
<andrewrk>
why should I specify padding here? I dont care about padding
<via>
what does that have to do with packing structs then?
dingenskirchen has joined #zig
<via>
packing is when you specifically care about the in memory layout
<via>
it would be when i need read and write to be 1 bit each, maybe 4 bits of padding for reserved space, then the enum, taking 4 bits or whatever it takes
<TheLemonMan>
let's take a step back, I feel the the problem here is that we want more than packed/nonpacked structure
<via>
i'm concerned that implementing per-field alignment for packed structs cretaes a lot of complexity
<andrewrk>
that's a reasonable argument. this is getting a bit involved and I would like to focus on some code, so I would request that if you want my engagement in this discussion, move it to https://github.com/ziglang/zig/issues/3802
<via>
ok, sorry
<TheLemonMan>
eg. packed with field-reordering
<via>
i also cannot imagine a world where i would want a packed struct to be subject to compiler reordering
moo has joined #zig
<TheLemonMan>
here's one use case: flags.
wootehfoot has quit [Ping timeout: 256 seconds]
<TheLemonMan>
maybe handling flags as a bitfield can be done even today with some comptime magic
<via>
TheLemonMan: i don't follow, you want the compiler to optimize a struct to keep all fields with no padding together, but nothing else? if anything, i just feel like that should be part of a 'optimize for space' option
<via>
but `packed` should just mean 'give me explicit control over the fields in memory'. or, call it something else, but that is definitely needed somehow
<TheLemonMan>
via, yeah that's what I said, we probably want more control over the layout
<via>
those are just optimzations though -- you can largely do what you want with just normal explicit packed structs. on the other hand though, there is a lot that cannot be done without having traditional packed structs (namely, i can't really use zig embedded until it works)
<via>
it just feels to me like perfect flexibility/annotations-for-the-compiler are preventing something simpler but necessary
<TheLemonMan>
nobody's talking of taking away regular packed structures
<via>
ok
<via>
though i think most of the issues around how packed structs don't work are waiting for a better more flexible way to do things. maybe i've misinterpretted
<TheLemonMan>
the point was, why would you want to underalign some fields in a non-packed structure? If you care about space saving/memory layout then why not a packed struct?
<via>
okay, fair enough
Biolunar has quit [Quit: leaving]
<sanaris>
Well, to be able to build Zig I was kinda forced to setting LLD_LLD*_LIB variables on src based system
<TheLemonMan>
plumm, GH is having connectivity problems
<plumm>
okie
r4pr0n has joined #zig
waleee-cl has joined #zig
<FireFox317>
andrewrk, are you going to stream some work being done on the self-hosted compiler? :D
moo has quit [Ping timeout: 256 seconds]
sanaris has quit [Remote host closed the connection]
r4pr0n has quit [Remote host closed the connection]
r4pr0n has joined #zig
<xackus>
anyone had --verbose-ir segfault by dereferencing null in render_node_extra?
nickster has joined #zig
<FireFox317>
verbose-ir always crashes when it is run on a big file i.e. hello world. you have to overwrite the panic handler and export _start to make sure that none of the std library is pulled in
<tritao>
mikdusan, ah just noticed you are working on a patch as well
<tritao>
yours seems more comprehensive for older OS versions so i guess thats the way to go
Xavi92 has joined #zig
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
foobles has joined #zig
<foobles>
heyo
<foobles>
in the c++ compiler, is there a strict formatting guideline? because when I copied + pasted some code it auto indented differently from normal
<foobles>
and Im wondering if i need to change it bakck
<Snektron>
i recommend following the existing style
ifreund has quit [Ping timeout: 256 seconds]
ifreund has joined #zig
foobles has quit [Remote host closed the connection]
foobles has joined #zig
ifreund has quit [Ping timeout: 265 seconds]
dingenskirchen has quit [Remote host closed the connection]
<Snektron>
old_mem should already be aligned to the page size right? so should that check be `new_align <= max(page_size, old_align)` instead?
<pixelherodev>
I prefer it as is
tritao has quit [Remote host closed the connection]
<pixelherodev>
It's IMO more readable
<pixelherodev>
Oh wait
FireFox317 has quit [Ping timeout: 256 seconds]
<pixelherodev>
I think I misunderstood you
<Snektron>
Its about functionality yea
<pixelherodev>
I'd ask for an explanation, but I'm not functional enough to comprehend it (pun intended)
<Snektron>
Well thats what i was trying to do actually
kristoff_it has quit [Ping timeout: 258 seconds]
nycex has quit [Remote host closed the connection]
nycex has joined #zig
<mikdusan>
what's the preferred mechanism for test inclusions in a file. I'm seeing the old `test "" { _ = @import("subdir/foo.zig"); }` and also a new one `std.meta.refAllDecls(@This());`
<Snektron>
Referencing all declarations will check if they contain semantic errors, but since it also references imports it also imports tests of all used files
<Snektron>
I think you have to be careful with it though, for example you might accidentally reference stuff belonging to the wrong platform
<mikdusan>
ah got it. if we wanted conditional includes of sub-dir-based tests, then refAllDecls is not going to work
marijnfs has quit [Quit: Lost terminal]
r4pr0n has quit [Quit: r4pr0n]
<pixelherodev>
`error: expected type '[]u8', found '*const [4:0]u8'` gah
<afontain_>
add a const
* pixelherodev
facepalms
<pixelherodev>
thanks
<afontain_>
helm has great messages in such case. maybe telling that the type would be compatible if there was a const would be nice