ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
Tobba_ has quit [Read error: Connection reset by peer]
vegecode has joined #zig
<vegecode>
I'm trying to use Zig on an msp430 and I am really close I believe. The zig build system is emitting asm and I am then using the TI provided msp-gcc to compile and link it.
<vegecode>
The assembly contains a reference to memset, which makes sense as I call memset like this:
<vegecode>
This code is basically exactly pulled from andrewrk's clashos repo
<vegecode>
TI is saying that memset is undefined, which makes sense as I'm calling gcc with -nostdlib and have not provided an implementation of my own.
<vegecode>
My point of confusion comes from reading in the documentation for zig that Zig doesn't rely on libc, which provides memset usually, I think?
<vegecode>
Is there a flag or something to make zig include all calls to compiler functions in the asm file?
<vegecode>
Or are some of the functions still relying on libc implementations for now
<vegecode>
Also, I'm not really sure what the polite way is to ask for help. Hopefully people here enjoy problems to solve like me so this enter the room and dump it tactic is ok...
<vegecode>
linked in after assembly
<vegecode>
When I say include all calls in the assembly, I mean all code compiled into the assembly file, with no other object file expected to be linked in.
<MajorLag1>
I was under the impression that @memset was an llvm intrinsic.
<vegecode>
That makes sense, but llvm doesn't ship with a bunch of object files for all the possible targets I don't think. How do you get a hold of the compiled output then?
<vegecode>
Maybe the msp430 backend just doesn't have it?
<vegecode>
Well I found a stackoverflow post where some person is saying that llvm reduces the intrinsics to a libc call usually but that it is dependent on the target.
<vegecode>
It looks like mem.set from "std" does what I'm looking for I think.
<MajorLag1>
Probably. IIRC it is just `for(bytes) |*b| { b.* = value; }` but I wonder if that won't get optimized into the @memset llvm intrinsic.
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
zolk3ri has quit [Remote host closed the connection]
tyler has quit [Disconnected by services]
tyler has joined #zig
tyler has quit [Disconnected by services]
tyler_ has joined #zig
<vegecode>
It looks like it's not, but when using it I'm not sure how to make the slice(?) length be resolved by the linker. It's telling me it needs a constant expression
<vegecode>
Am I understanding what it's asking for at least?
<vegecode>
Because there is no size parameter, I thought that what was in the brackets dictated the size
<MajorLag1>
assuming you're somewhere near the latest master, I think what you've done here is provided it a pointer to an array instead of a slice. I'm still parsing it.
<MajorLag1>
I think this is what you intended:
<MajorLag1>
const len = @ptrToInt(&__bssend) - @ptrToInt(&__bssstart);
<MajorLag1>
var bss_ptr = ([*]volatile u8)(&__bssstart);
<MajorLag1>
mem.set(u8, bss_slice, 0);
<MajorLag1>
var bss_slice = bss_ptr[0..len];
<MajorLag1>
though I'm pretty sure bss_ptr has to use @ptrCast: var bss_ptr = @ptrCast([*]volatile u8, &__bssstart);
<MajorLag1>
Lots of syntax changes recently, so depending on what build version you're running things may be a little different.
<vegecode>
The first one said invalid pointer cast.
<vegecode>
Trying next
<vegecode>
Second one compiled but it wouldn't allow the volatile
<MajorLag1>
I'm afraid I wouldn't know why.
<vegecode>
Any idea how to even get a variable into the bss section? I tried a global variable initialized with "undefined" but no go.
<vegecode>
Thanks for your help, all I had to do was explicitly initialize it to zero. I think now I'm struggling with understanding linker provided variables. Goodnight.
<MajorLag1>
No problem.
vegecode has quit [Ping timeout: 260 seconds]
dbandstra has joined #zig
return0e has quit [Remote host closed the connection]
dsn has quit [Ping timeout: 260 seconds]
dsn has joined #zig
klltkr has quit [Ping timeout: 245 seconds]
Tobba has joined #zig
bheads has quit [Ping timeout: 240 seconds]
dsn has quit [Quit: Leaving]
JinShil_ has joined #zig
JinShil has quit [Ping timeout: 240 seconds]
dbandstra has quit [Quit: Leaving]
xtreak has joined #zig
very-mediocre has joined #zig
very-mediocre has quit [Ping timeout: 260 seconds]
very-mediocre has joined #zig
Tobba has quit [Ping timeout: 256 seconds]
jjido has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
JinShil_ has quit [Read error: Connection reset by peer]
JinShil_ has joined #zig
very-mediocre has quit [Ping timeout: 260 seconds]
xtreak has quit [Remote host closed the connection]
<GitHub65>
zig/master 811539f Alexandros Naskos: Added missing ?type in docs.
<GitHub65>
zig/master 85422d7 Andrew Kelley: Merge pull request #1136 from alexnask/typeinfo_improvements...
<GitHub65>
zig/master 1392313 Alexandros Naskos: @typeInfo now uses optional types instead of @typeOf(undefined)
btbytes has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bheads__ has joined #zig
btbytes has joined #zig
bheads_ has quit [Ping timeout: 276 seconds]
kristate has joined #zig
kristate has quit [Ping timeout: 256 seconds]
bheads_ has joined #zig
<alexnask>
Huh, didn't realize you could use type fields of comptime arguments in type expressions
<alexnask>
Well, I did, but never thought of it in a comptime self parameter context, this is pretty awesome
<alexnask>
That means you can have type-safe APIs over type erased values in comptime contexts
bheads has joined #zig
bheads__ has quit [Ping timeout: 268 seconds]
bheads_ has quit [Ping timeout: 260 seconds]
<andrewrk>
:)
<alexnask>
Btw, the reason I used a raw u8 pointer there is that I'm pretty sure it is impossible to use generics
<alexnask>
Since we need an array/slice of FnDefs at some point and we don't know what the types of the functrions actually are
<alexnask>
If you get what I mean :P
<andrewrk>
yeah it makes sense
Hejsil has joined #zig
<Hejsil>
alexnask, ye type erased comptime code is pretty useful.
btbytes has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<andrewrk>
Hejsil, thanks for the example - I read the llvm langref more carefully, and I'm going to adjust https://ziglang.org/documentation/master/#floatToInt to no longer say "this cast is always safe" to "if the integer part of the float cannot fit in the destination integer type, this invokes safety-checked undefined behavior"
<Hejsil>
Righto
<Hejsil>
Was not sure, since we defined @floatToInt as safe but with lose of precision
<andrewrk>
based on a more careful reading of llvm langref, I believe we are seeing a "poison value"
<andrewrk>
which is not undefined behavior, but nonsense data that makes any operations with other data become nonsense data
<andrewrk>
but zig treats llvm poison values the same as undefined behavior
<Hejsil>
Probably for the best too
<andrewrk>
right because a poison value is almost certainly a user bug
<andrewrk>
let's catch it right away
<andrewrk>
alexnask, I'm kind of worried that @reify might be too powerful
btbytes has joined #zig
<andrewrk>
it could be used to write convoluted code
<alexnask>
I can see how it could be used in confusing ways
<alexnask>
Imo it is fine as long as you don't get to generate arbitrary code/ASTs
<alexnask>
Although generating methods may seem too powerful, implementing it this way still means that the method code is accessible and is not simply a mixined string (like e.g. in Dlang)
<andrewrk>
that's true
<andrewrk>
Hejsil, here's a fun little puzzle: come up with the LLVM IR code for the @floatToInt safety, to detect if the value fit in the integer
<andrewrk>
one idea: fptoui with an i53 (whatever has the same number bits as the mantissa), and do a bounds check on the destination integer type range
<andrewrk>
another idea: fptoui the actual result, then uitofp back, and make sure the float difference < 1.0
Hejsil has quit [Quit: Page closed]
<andrewrk>
yet another idea: we could make @floatToInt not accept a DestType parameter. it always gives a i24, i53, or i113
<andrewrk>
and it's always safe
<andrewrk>
but you'll probably have to @intCast the result to get the int type you want
<andrewrk>
oh wait, this is flawed. max value of a f32 is way bigger than max value of a u24
_nipc has joined #zig
davr0s has joined #zig
<alexnask>
Right, I don't think there is any way to guarantee that the float fits into an int at compile time
darithorn has quit [Quit: Leaving]
<alexnask>
Does using an @OpaqueType() to represent the Self type in TypeInfos before reification sound horrificly hackish to you, btw? :P
<andrewrk>
hmm I'd have to see the details
<alexnask>
I'll write a quick little script, but basically the idea is that we can't refer to the type we are generating, when we need to in lots of cases
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
btbytes has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<alexnask>
This just uses @reify to generate a linked list type
<andrewrk>
I see
<andrewrk>
let me think about this
<andrewrk>
I do think that's a reasonable way to work around the problem
<andrewrk>
brainstorming here, another way to do this would be to make your own opaque type, and then @reify accepts an opaque type to apply the type info
alexnask has quit [Ping timeout: 264 seconds]
<andrewrk>
I think your way is better
timetoplatypus has quit [Ping timeout: 240 seconds]
davr0s has joined #zig
klltkr has joined #zig
very-mediocre has joined #zig
Ichorio has joined #zig
jjido has joined #zig
noonien has quit [Quit: Connection closed for inactivity]
andi3 has joined #zig
<andi3>
Hello, I want to implement a compression (LZW) in zig for which I need to store indices into a dictionary. The indices have to be 10bit uints (not 16bit) to make the compression work.
<andrewrk>
hi andi3
<andi3>
Is there any way to have an array of 10bit uints arranged in memory in perfect packing ?
<andi3>
this is an edge case but as edge cases matter I thought I might as well ask what the zig approach to this is
<andrewrk>
although we have packed structs, we don't currently have the concept of packed arrays
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<andrewrk>
you could have an array of 80 bit integers
<andrewrk>
then do a little bit of math when loading/storing
<andrewrk>
this might not be better than 16 bit ints though
<andrewrk>
we could talk about a proposal for packed arrays
<andi3>
ok currently in cpp I go through bit by bit and stuff it into a byte vector which is not very nice to read
<andi3>
I like your approach because the math is a bit easier/ less error prone but its certainly not perfect software/ has some overhead most of the time for up to 79 empty bits
<MajorLag1>
I've also come across a problem or two where packed arrays would be useful.
<andrewrk>
assuming a definition of "perfect" is "every input gets the correct output", I don't think there's a problem with the ability to represent a perfect solution
<andrewrk>
sounds like we're talking about ergonomics and optimality
btbytes has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jjido has joined #zig
andi3 has quit [Ping timeout: 260 seconds]
jjido has quit [Client Quit]
andi3 has joined #zig
<andi3>
yes
<andrewrk>
I think that a packed array feature would help ergonomics but not optimality. zig would be hiding the bit shifting you would otherwise be doing explicitly
very-mediocre has quit [Ping timeout: 260 seconds]
<andrewrk>
for example say you have a packed struct which is volatile, if you did bit shifting manually, you could submit 2 u4's to the MMIO with 1 store, whereas if they were bit fields, you would be doing 2 stores
<andi3>
okay so your point is that ergonomics might actually hurt optimality ?
<MajorLag1>
The same is true of packed structs though.
<andrewrk>
andi3, yes, although if it prevents bugs in practice, that can be a worthwhile tradeoff
<andi3>
afaik from a c background packed arrays do not exist because taking the address of a member would not be legal ? could zig solve this in some way/ I guess yes otherwise you would have said otherwise immediately ?
<MajorLag1>
On the other hand, writing userland functions to read/write packed bit streams is pretty straight-forward compared to dealing with packed structs in the same way.
<andrewrk>
it could work - in zig when you take the address of a packed struct field, the type of the pointer has metadata, and it cannot be passed to functions which expect normal, non-packed, aligned pointers
<andrewrk>
similarly with packed arrays, when you index them or take the address of an element, the pointer would have this metadata
<andi3>
okay that sounds nice
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
<andi3>
thanks for the answers, looking forward to seeing zig evolve
<GitHub90>
zig/master ee525c9 Andrew Kelley: langref: organize docs for inline loops and add note about when to use it
<alexnask>
This is another potential problem for method generation for @reify, even if you use an opaque type as a tag type there is no way you can define a function specialized for the type that will be reified
<alexnask>
Unless the compiler accepts a FnDef ptr to a generic function that is then specialized on the fly but I don't think that is elegant