ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<daurnimator>
Misc thing: I use sublimetext. commenting doesn't work in the zig syntax
<daurnimator>
normally I press ctrl+/ to comment out a line
<andrewrk>
I pasted the LLVM IR at the bottom, you can see the load/store is 32 bit and align(1)
<diltsman>
I see that. But reads/writes tothe 4-bit fields wouldn't generate a 32-bit write...
<diltsman>
Dealing with memory mapped I/O on ARM has lots of bitfields that must be read/written in 32-bit aligned chunks.
juster has joined #zig
<andrewrk>
I think I'm going to run into this problem soon, I picked up my arm OS project
<andrewrk>
I don't understand yet though, why would you expect the u4 fields to have anything to do with 32 bits? that would overlap with the next fieldf
<andrewrk>
I think I need to see some code examples to understand the use case better
<andrewrk>
in short though, if you need writes of minimum 32 bits then your fields should be minimum 32 bits.
<diltsman>
Yes, that could be done. I wonder how the optimizer would handle that. As long as field accesses are done through functions rather than the fields directly it wouldn't obfuscate use too much.
<andrewrk>
the volatile memcpy call in debug mode is unfortunate. we could potentially detect this in zig and emit integer loads/stores instead of memcpy
<andrewrk>
hmm I also think you need _unused: u8 at the end
<andrewrk>
oh good there is actually no memcpy call in debug mode. it got lowered to normal loads/stores
<diltsman>
I didn't realize that Zig was on Compiler Explorer. Matt Godbolt is a great guy and a good speaker.
oconnor0 has quit [Ping timeout: 268 seconds]
oconnor0 has joined #zig
Zaab1t has joined #zig
<diltsman>
andrewrk: If I am reading that right, it is loading the upper 8 bits, then the middle 16, then the lower 8 from the struct. Not a 32-bit load.
oconnor0 has quit [Quit: Quit]
<diltsman>
It looks like in debug it generates a 32-bit load, but in release it generates byte and half-word loads.
m4ge123 has joined #zig
<andrewrk>
diltsman, I think the volatile didn't get correctly propagated. let me try something.
<andrewrk>
I found a problem, working on a solution
steveno has quit [Remote host closed the connection]
<diltsman>
MajorLag, I'm trying to figure out why it generates two loads and a store for the bitCast. It should be able to load, modify in register, and store.
<andrewrk>
diltsman, it's because zig emits a memcpy intrinsic to llvm and does not mark it volatile. so llvm is free to lower it in any way
<andrewrk>
I'm working on it now
<andrewrk>
I described the problem in the issue #1761
<diltsman>
andrewrk: I was refering to his bitcast workaround.
<andrewrk>
ah, my mistake
<diltsman>
It loads two values into r1, then stores r1 on the stack.
<diltsman>
Never mind. It is an indirection. I see the double load.
<andrewrk>
this is solved in my copy elision branch
<andrewrk>
which is not merge ready yet
<MajorLag>
andrewrk, if I have `fn foo() T { var x: T = undefined; //do stuff with x; return x; }` would that be elided in the branch code? Or does this require something like @returnValue()?
<andrewrk>
MajorLag, that's the "part 2" of copy elision that my current branch does not solve
<andrewrk>
so a second proposal must be accepted to solve this use case. and this "part 2" thing is much, much easier than part 1
<andrewrk>
an interesting component of that is going ot be that in the case of a function returning ?T, E!T, or E!?T, `@returnValue()` would refer to the *T only
<andrewrk>
I haven't figured out how to introduce this concept into the language in a clear way
errpr has joined #zig
<andrewrk>
hmm I just thought of one though. I'm going to propose it in an issue
<MajorLag>
ok, that'll make what I'm currently working on a bit less convoluted eventually. On a different subject, there isn't a way to set the active tag of a union other than to assign it a new value right? And the only way you can do that is `union = T{.Field = x, }`, right? I'm writing code that serializes and deserializes unions, it writes the active tag out, then the value. On read it reads in the tag to know what valu
<MajorLag>
can't see a way to assign it. `@field(union, field_name) = field_val;` throws an invlad union tag access assert.
<MajorLag>
Any ideas?
<MajorLag>
I can't do `union.* = UnionType{.field_name = field_value};` because I have no way of expressing that since `field_name` is a `[]const u8`.
<andrewrk>
MajorLag, that's right
<andrewrk>
did your message get cut off?
<MajorLag>
possibly.
<andrewrk>
" know what valu"
<andrewrk>
oh I think I might know what you're talking about. I opened an issue for this recently.
<MajorLag>
"know what value to expect. Problem is, I can't see a way to assign it. `@field(union, field_name) = field_val;` throws an invlad union tag access assert."
<MajorLag>
Only workaround I can think of is to manually access the bytes of the tag and change them.
<andrewrk>
does the proposed solution look ok to you?
<MajorLag>
yeah, that'd work just fine.
<andrewrk>
ok I accepted it so it's now planned
<andrewrk>
this might be one of those "easy" issues that people were asking for
<MajorLag>
well... if I could change one thing: it'd be nice to do `@unionInit(Type, name, undefined);` which currenlty wouldn't work I think. Reasoning is that if the union is value is, say, a big struct then I want the serialization code to fill in the values in-place instead of creating a new instance and copying it in. Copy elision mike make that unnecessary anyway eventually.
<andrewrk>
it would work with undefined, just like UnionName { .FieldName = undefined }
<MajorLag>
oh, then I'm totally cool with it.
<andrewrk>
it would be semantically equivalent to that syntax, except with a comptime string for FieldName rather than a token
<andrewrk>
compiler builtins are actually modeled as semantic constructs rather than function calls
<MajorLag>
yeah that makes sense.
<andrewrk>
for untagged unions, `x = UnionName { .FieldName = undefined }` is a no-op in release mode. only in debug mode does it do anything, which is change the secret debug tag
<MajorLag>
the one that differentiates between a union that hasn't been assigned anything yet and one that has?
<MajorLag>
fortunately, there's no sane way for me to serialize untagged unions in the general case, so I just don't. The caller can implement their own serialization function for the type the same way we can implement custom formatters.
<MajorLag>
fortunate in that I don't have to deal with it I mean.
<andrewrk>
not sure I understand your question - in debug mode, unions with automatic container layout (non extern non packed) actually have a secret tag, and zig always knows which field is active. I don't think I made it support a meta "undefined" state, but that would be a good idea.
<andrewrk>
you wouldn't want to use this secret tag (which you could only access with pointer hacks) for serialization because it wouldn't work in release modes where the secret tag is omitted
<MajorLag>
right, I wouldn't plan to support it because the tag's existence is invisible to the user anyway. I could have sworn an issue involving un-initialized unions having a seemingly valid tag value came up.
<MajorLag>
905?
<andrewrk>
ah, yes, that's what I was referring to
Zaab1t has quit [Quit: bye bye friends]
<diltsman>
Is there a way to specify a function parameter as volatile?
<andrewrk>
you mean a non-pointer parameter?
<andrewrk>
how would that work?
<MajorLag>
andrewrk: in my testing, it looks like the secret tag sticks around in release-fast, and also is still present in all modes if you assign a tag and that tag is > u32 (though it is always set to 0).
<diltsman>
andrewrk, I'm used to how C uses volatile. What I want, is a self parameter to be volatile.
juster has quit [Quit: Leaving]
<andrewrk>
how about: self: *volatile T
<andrewrk>
MajorLag, if that's true that's a bug
<MajorLag>
I'll write it up. It is easy to show.
<andrewrk>
thanks
<diltsman>
Thanks, that works for me.
<errpr>
I'm having a problem. My program never halts if I link to window's xinput1_4 DLL
<andrewrk>
errpr, are you broadcasting coding videos?
<errpr>
no
<diltsman>
I compile this: pub const PIO = packed struct{var mem: [82]u32;};var pioa = PIO{.mem=undefined};
<diltsman>
I get this error: error: no member named 'mem' in struct 'PIO'
<andrewrk>
errpr, your types look like they might be worth double checking. For example, you could `const win = @import("std").os.windows;` and then use `win.HINSTANCE` `win.DWORD` etc
<andrewrk>
hmm they look ok though
<errpr>
I ripped the types from MajorLag
<andrewrk>
is this a problem with the direct x API? does an equivalent C program work?
<errpr>
checking that now
<andrewrk>
is this related to XInputEnable?
<errpr>
XInputEnable doesn't change it
<errpr>
I tried setting it to true and false
<andrewrk>
diltsman, `var` is making `mem` a global variable in the namespace of your struct rather than a field
<andrewrk>
that actually should be a compile error that says "variables must be initialized"
<andrewrk>
packed struct{mem: [82]u32,}
<andrewrk>
errpr, oh, maybe this has something to do with DLL destructors
<diltsman>
That makes sense. That is gonna catch me a few times before I get it down.
<MajorLag>
andrewrk: nevermind the second part of that debug tag issue, further testing reveals it was just alignment padding where I didn't expect it.
<andrewrk>
hmm never mind there is no such thing as a DLL destructor
<errpr>
the C version exits properly
<andrewrk>
errpr, I have one more idea to try. add --verbose-link to your zig build command, and then repeat the test using link.exe (msvc's linker). I expect that to have the same behavior.
<andrewrk>
Then replace the xinput1_4.lib from the linker line with the path on your system to xinput1_4.lib provided by microsoft
<andrewrk>
see if that changes anything
<andrewrk>
another thing to try is the C object linked with zig using zig's generated .lib file
<andrewrk>
I can also try to reproduce this on my system
<errpr>
hmm my link.exe says its GNU
<andrewrk>
zig is supposed to generate msvc compatible objects on windows
<errpr>
okay swapping that out with MSVC link.exe fixed it
<andrewrk>
even with zig-generated xinput1_4.lib ?
<errpr>
yeah
<andrewrk>
interesting. that points toward an LLD bug, which is nice because the LLD team is actually quite active and responsive
<andrewrk>
if we can put together a high quality bug report and report it upstream, I think it should be fixed within 1 release cycle, which means zig 0.4.0 (with llvm/clang/lld 8.0.0) would have the fix
<andrewrk>
if we can reproduce it with clang+lld, that would bring some quick attention
<errpr>
I don't understand compilers :)
<benjikun>
errpr: What are you making?
<andrewrk>
errpr, thanks for the report. I'll take it from here.
<errpr>
benjikun I'm following handmade hero, a video series on making games with no libraries
<andrewrk>
ahhh
<benjikun>
That's nice
qazo has joined #zig
jjido has quit [Quit: Leaving.]
j`ey has joined #zig
<j`ey>
where does the backtrace code live
<j`ey>
?
<j`ey>
(or even the default panic handler)
<j`ey>
found it: std/special/panic.zig
<andrewrk>
j`ey, that's the default panic handler. you can override it by putting your own `pub fn panic(...` function in your root source file
<j`ey>
interested in 'dumpCurrentStackTrace(first_trace_addr)' :)
<benjikun>
std/debug/index.zig
<benjikun>
if you hadn't already found it
<andrewrk>
j`ey, be warned, I'm pretty sure that code leaks memory. there's a few TODO items to make it more friendly to calling sometime other than when you're about to crash
<j`ey>
benjikun: thanks, I had
<j`ey>
remembered I had a local copy of te zig code, so could grep/vim it :)
<andrewrk>
although if you're just debugging something, it should be fine
<j`ey>
didnt even know "var a: type = i32;" was a thing in zig
<andrewrk>
it's required to use `const` unless inside a comptime scope
<j`ey>
what do you mean by "pointer operator"?
<j`ey>
oh, just saying a type is a pointer.. I think
<andrewrk>
the operator that takes a type, and returns a type which is a pointer to it
<andrewrk>
in zig `*i32` is actually a prefix operator, operating on an expression, which is i32, and then the result of the expression is the type *i32
<j`ey>
can you remind me how to set debug/opts on godbolt?