ChanServ changed the topic of #zig to: zig programming language | https://ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
Barabas has quit [Ping timeout: 245 seconds]
<andrewrk> man we just can't catch a break from windows CI
<cr1901_modern> s/CI// :)
codemessiah has left #zig [#zig]
klltkr has joined #zig
haliucinas has quit [Ping timeout: 260 seconds]
haliucinas has joined #zig
_whitelogger has joined #zig
jjsullivan has quit [Remote host closed the connection]
jjsullivan has joined #zig
klltkr has quit [Ping timeout: 260 seconds]
ur5us has quit [Ping timeout: 240 seconds]
ur5us has joined #zig
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
ur5us has quit [Ping timeout: 240 seconds]
_whitelogger has joined #zig
tomku has quit [Ping timeout: 240 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
tomku has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
tomku has quit [Ping timeout: 265 seconds]
osa1 has joined #zig
tomku has joined #zig
_whitelogger has joined #zig
jjido has joined #zig
jjido has quit [Client Quit]
decentpenguin has quit [Read error: Connection reset by peer]
decentpenguin has joined #zig
earnestly has joined #zig
FireFox317_ has joined #zig
FireFox317_ has quit [Client Quit]
haliucinas has quit [Remote host closed the connection]
ur5us has joined #zig
haliucinas has joined #zig
dermetfan has joined #zig
cole-h has quit [Ping timeout: 260 seconds]
dermetfan has quit [Remote host closed the connection]
dermetfan has joined #zig
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
Norbertle52 has joined #zig
casaca has quit [Ping timeout: 240 seconds]
casaca has joined #zig
Bastian[m] has quit [Quit: Idle for 30+ days]
cow-orker has joined #zig
jjsullivan1 has quit [Remote host closed the connection]
jjsullivan1 has joined #zig
ur5us has quit [Ping timeout: 240 seconds]
kristoff_it has joined #zig
_whitelogger has joined #zig
marnix has quit [Ping timeout: 265 seconds]
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
xackus has joined #zig
<s-ol> hey, how should I build a string iteratively at comptime?
<s-ol> I'm trying to define it using var and then append using ++
<s-ol> but its type changes: error: expected type '*const [0:0]u8', found '*const [11:0]u8'
Norbertle52 has quit [Remote host closed the connection]
<s-ol> ok, seems like declaring it as a slice (var str: []const u8 = "") worked
<s-ol> now I'm getting a strange error in the assembly block where I am using the (partially) comptime-generated string:
<s-ol> error: expected a '%' or '[' ; pointing towards the start of a line that contains only "asm volatile ("
<fgenesis> zig cc? or just zig?
<fgenesis> because asm volatile via zig cc segfaults for me using the 0.6 release
<scientes> fgenesis, you should post a test case
<scientes> andrewrk found a exit(1) in ldd recently, but that is probably unrelated.
<fgenesis> i'm not 100% sure and ikskuh said the compiler changed a lot since then so whatev?
<scientes> oh 0.6 yes
<scientes> all development is on master
<scientes> but zig cc does not change as much
<fgenesis> i wish i could use the master but nope sorry
<ikskuh> why not?
<fgenesis> 4gb ram
<ikskuh> you don't need to compile on-platform ;)
<ikskuh> s-ol, can you post a example of what you pass into the asm block?
* scientes has not actually used zig since 0.6.0
<fgenesis> but i WANT to compile on-platform. it's like developing on PC when targeting the C64. who DOES that.
<scientes> except zig is built for that
<scientes> (and so is llvm)
<fgenesis> obviously needing almost 6gb of ram is not an issue for llvm
<ikskuh> fgenesis: i'M talking about "compile your zig compiler cross, then compile zig on-platform"
<fgenesis> aaaactually that would work yes
<scientes> zig can do both better than any other compiler
<Michcioperz> i'm on 0.6 still too
<fgenesis> quite literally because it doesn't build on arm32 due to usize != u64 mismatches
<scientes> fgenesis, patches on that would be welcome
<fgenesis> i did hackfix the places where this was a problem but i'm sure i botched it
<ikskuh> luckily, we have a test suite :D
<scientes> ^^^
<ikskuh> that takes up 5gb of RAM as well :D
<fgenesis> yes but it's also ugly
<fgenesis> it's like a perfect face and then it has this really ugly pimple on the forehead
<scientes> usually usize stuff is not ugly
<fgenesis> that's those patches
<fgenesis> as i said, hackfixed
<scientes> unless you actually have a need for more than 4GB of VM
<Michcioperz> s-ol: i just checked and it seems if you have a weird thing in your asm string the error points to asm volatile ( line
<Michcioperz> so maybe your asm string is bad?
<scientes> oh you mean the zig "asm volatile" and no C-lang?
<Michcioperz> looks like it from the rest of problem definition
dermetfan has quit [Ping timeout: 240 seconds]
<Michcioperz> s-ol: i'd try printing that asm string with @compileLog or something so we can see if it's correct
<Michcioperz> scientes: in my reproduction an analogous error in zig cc is "invalid register name" rather than "expected a % or ["
<scientes> Michcioperz, that syntax is not easy even in GCC, and llvm doesn't use the identical syntax and is basically undocumented
<Michcioperz> yeah it's defo not easy
<scientes> Michcioperz, but in zig it is not showing you all the errors
<scientes> that clang would show you for example
<scientes> it only shows the first error
<scientes> needs love
<ikskuh> the inline assembler doesn't need love
<ikskuh> it needs replacement
<Michcioperz> and the error points to start of asm statement and not to string
<scientes> ikskuh, an assembler is not one piece of softwre
<scientes> and requires too much maintinance that is beyond the scope of the zig project
<scientes> look at how horrible the go assembler is for an example of what not to do
<fgenesis> wait what, go supports inline asm?!
<Michcioperz> go has its own "asm" doesn't it?
<ikskuh> scientes: i know how much work an assembler is
<ikskuh> i've written one
<Michcioperz> isn't go asm more like llvm ir?
<fgenesis> i've TRIED writing one and never finished :P
<scientes> ikskuh, oh ok, never mind me then
<ikskuh> scientes: do you know https://github.com/andrewrk/zasm ?
<Michcioperz> anyway zig's docs for its asm stmt seem much more practical than gcc's
<fgenesis> "Architectures - All of them."
<s-ol> sorry, was gone for lunch
<s-ol> i actually found it, porting from C I forgot to change one occurence of %2 to %[name]
<Michcioperz> i spent some time fighting gcc's asm before learning from a teacher that you can `register int x __asm__("r11");` or something
<pixelherodev> Michcioperz: the latter is what Zig uses for the CBE now
<Michcioperz> i'll just uh
<scientes> no, but I kinda got disgruntled with zig because I thought it was trying to fix things that are not excessively broken, instead of polishing up what are some really cool features: 1. trapping undefined, 2. comp-time, 3. awareness of multiple ways to allocate memory
<pixelherodev> Being able to bind values to registers like that is much more convenient
<Michcioperz> never look inside CBE code
<pixelherodev> Michcioperz: CBE is actually really straightforward
<Michcioperz> i don't doubt it
<scientes> so I started feeling that it would be better to try to improve C, and bringing these features to C
<Michcioperz> i just feel like i've seen enough C last year
<scientes> because zig and C, and C's SSA dialect LLVM-ir are all very similar languages
<pixelherodev> Michcioperz: CBE is written in Zig ;)
<pixelherodev> It generates C code :P
<Michcioperz> yes and i'm talking about not looking at that C code
<pixelherodev> Ahh gotcha
<scientes> like to cbe?
<pixelherodev> scientes: ?
<pixelherodev> ?
<pixelherodev> ...
<scientes> <pixelherodev> Michcioperz: CBE is written in Zig ;)
<pixelherodev> whoever drew the art on that post... it's so cute
<scientes> what is CBE?
<pixelherodev> scientes: C backend
<pixelherodev> I know I could just stop using the initialism and then I'll never need to explain it again... but CBE is much easier to type :P
<scientes> ahh yes I see this hot code swapping, which andrew had as one of his initial ideas
<scientes> Ian Airs who wrote the Gold linker was working on that once
<scientes> Ian Lance Taylor
<scientes> cool
<scientes> I have been thinking about some highly theoretical non-turing complete C-like language (it means you can't have function pointers), and I realized I would need something like this, but the line number would be calculated by a regular expression
<pixelherodev> andrewrk: lemme know when you're on to discuss the CBE issue
FireFox317 has joined #zig
<s-ol> how can I cast a []struct{r,g,b, = u8} to a []u8 (with four times the length)?
<FireFox317> fgenesis, what platform do you want to run zig on? Arm32?
<FireFox317> fgenesis, there were some bugfixes regarding segfaults after the 0.6 release and unfortunately they didnt end up in the tar file that is on the website
<pixelherodev> s-ol: with what intent?
<FireFox317> I will start building it for arm32 and make sure we dont have these issues for the next release cycle (which is not far away)
<s-ol> to send data out bytewise
<s-ol> its a bitbanging protocol for driving LEDs from an AVR
<s-ol> sorry, to []const u8 actually
<pixelherodev> s-ol: struct needs to be packed for that
<pixelherodev> otherwise, there's no guarantee that the order will be what you want
<pixelherodev> if it's packed... `std.mem.toBytes(&struct)` ?
<pixelherodev> I haven't done that in a while, so I'm not 100% sure
<s-ol> thanks, i'll take a look
<s-ol> std.mem.sliceAsBytes sounds like it
<s-ol> if I'm hitting LLVM ERROR: Cannot select... is that a Zig bug? Or am I doing things the architecture doesn't support?
<pixelherodev> Probably an LLVM bug :P
<pixelherodev> It could be that what you're doing is untested with LLVM on the given architecture
<s-ol> hm, i really can't amke much of the error output
<pixelherodev> You could try just `@intToPtr(T, @ptrToInt(`
<pixelherodev> That removes safety, but it might potentially use different primitives which are better tested on LLVM-avr?
<ifreund> what safety does it remove?
<s-ol> i'm not even sure what statement this is about bh
<s-ol> tbh*
<s-ol> ws2812:68 is the for loop
<pixelherodev> ifreund: e.g. alignment, I believ?
<pixelherodev> believe*
<ifreund> nah it still checks that
<pixelherodev> Ah right
<pixelherodev> if e.g. `packed` is removed, it'd keep compiling
<ifreund> the @alignCast is implicit though
<pixelherodev> I think the lack of notice of `packed` is the biggest issue there, and it's not that bad
heitzmann has joined #zig
delaney has quit [Quit: Leaving]
squeek502 has quit [Remote host closed the connection]
squeek502 has joined #zig
xackus has quit [Ping timeout: 260 seconds]
<Michcioperz> thanks to this conversation i dug around and found out how to compile zig code for avr, thanks y'all
<s-ol> hm, found another example of something that doesn't work:
<s-ol> 0x562582d26000: i16,ch = CopyFromReg 0x5625825f3108, Register:i16 %4, ws2812.zig:68:5 @[ main.zig:54:16 ]
<s-ol> whoops
<s-ol> const CLKPR = @intToPtr(*volatile u8, 0x61); CLKPR.* = 1 << 7;
dermetfan has joined #zig
omglasers2 has joined #zig
<s-ol> it seems to only work for addresses between 0x20 and 0x5f?
<Michcioperz> i pasted that blindly into my working example code and it compiled
<s-ol> Michcioperz: huh... how are you compiling?
<Michcioperz> zig build-obj --release-small -mcpu atmega8 -target avr-freestanding-none --strip blink.zig
<Michcioperz> (on 0.6.0)
<s-ol> oh, i probably should add -mcpu
<s-ol> wow, that seems to have done the trick :)
<Michcioperz> nice
<Michcioperz> i just learnt how to do that today so double nice
<ikskuh> Michcioperz: nice!
<ikskuh> after the LLVM 11 merge (which should happen soonish), we should also be able to link for AVR
waleee-cl has joined #zig
Hairok has joined #zig
<ifreund> you have leeward to thank then :)
<Michcioperz> it's pretty cool that if you @intToPtr the peripheral registers to packed structs with u1 for each bit, it compiles to instructions that just set and clear bits, no reading
Hairok has quit [Remote host closed the connection]
Hairok has joined #zig
<Michcioperz> ifreund: is that their repo? i tried to find the repo author on the internet to not much effect haha
<ifreund> yup, he's got a website too: https://www.nmichaels.org/
<ikskuh> Michcioperz: what would be super-awesome: if we could have a "atmega" package which would provide a basic HAL which exposes all registers
<Michcioperz> well i could write that for atmega8 because it's the only atmega i have
<Michcioperz> but it sounds futile
<ikskuh> and on top of that, build a "arduino" package which either depends on the correct "atmega" or "atsam""
<ikskuh> well, i wouldn't write it by hand
<Michcioperz> i tried to use avr-rust a few months ago but everyone there seems to be using atmega328p
<ikskuh> yeah, the atmega328p is from the Ardunios
<ikskuh> but they only differ in minor stuff
<ikskuh> most code is literally the same
<Michcioperz> autogenerating it would be nice but
<Michcioperz> are there other sources of knowledge than datasheet pdfs?
<ikskuh> not sure
<ikskuh> we could check out avr-libc
<Michcioperz> avr-libc looks beautiful with all the ifdefs
<ikskuh> :D
<ikskuh> looks like they have a codegen
<Michcioperz> oh, a .dtd
g_w1 has quit [Ping timeout: 256 seconds]
<ikskuh> "device tree data" :D
<Michcioperz> https://github.com/avrxml/AS6-Devices-XML (not sure if this repo is legit though)
<Michcioperz> lol no
<ikskuh> yeah i know DTD :D
<ikskuh> but it would fit ^^
g_w1 has joined #zig
<Michcioperz> i had to parse a 2.5gb xml in class last year
<ikskuh> heh
donniewest has joined #zig
<Michcioperz> ah, i think those xmls might be from atmel studio
<s-ol> I'm using an atmega32u2, still figuring stuff out with zig though
<s-ol> now it seems like the zig code ends up in the wrong segment (.progmem.data, not .text)?
<Michcioperz> oh, i never flashed an elf back in my high school days, only ihex
<Michcioperz> so not sure if i can help you
<s-ol> Michcioperz: but the elf is the inbetween step
<s-ol> i'll take a look at the testbed code you linked
<Michcioperz> yeah but i believe ihex doesn't carry the information about segments so i never had to worry about that
<s-ol> right now I'm going off zig issue #3637
<ikskuh> Michcioperz: ELF is the "good" format with debug info and symbols
<Michcioperz> ikskuh: i know
<ikskuh> ihex only is raw data and a entry point
<ikskuh> :)
<Michcioperz> kinda had to write a parser another time last year
<ikskuh> heh
<ikskuh> it's easy to parse
<ikskuh> i have a zig package for that as well :)
<Michcioperz> it is, the rest of the task was more "fun"
<Michcioperz> unfortunately i don't have an english task description
<Michcioperz> but tldr: link given object file into given already linked executable elf
<ikskuh> oh
<ikskuh> fancy
<ikskuh> i'm not sure if it is possible
<Michcioperz> under further constraints it is
<ikskuh> but i want to write a undynamic linker
<Michcioperz> oh
<ikskuh> so
<ikskuh> you give it a dynamically linked program
<ikskuh> and you receive a statically linked program :D
<Michcioperz> oh
<Michcioperz> actually that doesn't sound that bad?
<ikskuh> yeah, it should be possible
<ikskuh> and would make some deployment easier
<Michcioperz> just barely possible, yes
msingle has joined #zig
<fgenesis> FireFox317: rpi4, 32bit raspbian
<fgenesis> 4gb model
<FireFox317> fgenesis, :thumbsup:
<fgenesis> i'm intentionally not choosing the worst machine i have
<Michcioperz> the kernel on raspbian isn't 64bit?
<fgenesis> but i WILL eventually coax people into supporing win98+KernelEx :P
<Michcioperz> lol that's a fun idea actually
<fgenesis> and the pentium90+DOS machine i thiiiink is too far off so i'll pass on that
<ikskuh> fgenesis: i think you can actually make that already possible
<ikskuh> but "zig std" won't support it
<Michcioperz> idk i know a few friends who in 2020 would like to make a game for dos
<ikskuh> there's already a dos program written in zig :)
<fgenesis> same! except i have too many projects and too little time D:
<fgenesis> ohoh
<ikskuh> someone shhould to an 8086 and 8088 backend
<ikskuh> maybe i'll wait 2000 issues for that… :D
<ikskuh> to make a new issue
<fgenesis> and there is also the HX dos extender / DPMI64 that supports 64bit extended DOS but don'T even ask me how that works
<fgenesis> i do draw the line somewhere and this is clearly way past that point :P
* ikskuh draws lines by calling setPixel
<fgenesis> for(x) for(y) a[y][x] = new pixel(r,g,b)
* bfredl makes notes
layneson has joined #zig
<fgenesis> (yes i have once seen a java person do that. scientific image manipulation code. 2d array of pixel objects...
larme has joined #zig
<s-ol> Michcioperz: could you share what `avr-objdump -t main.o` does with the main.o from `zig build-object...` in your setup?
<Michcioperz> sorry, i turned my computer off literally a minute before you asked
<s-ol> actually i mightve just found two problem sources
larme has quit [Quit: WeeChat 2.3]
sawzall has quit [Read error: Connection reset by peer]
sawzall has joined #zig
larme has joined #zig
hnOsmium0001 has joined #zig
<s-ol> yes, got a blinking led now :)
<ifreund> \o/
<ikskuh> whooo!
<ikskuh> let it blink!
<leeward> This is on an avr of some sort?
bastian[m] has joined #zig
bastian[m] is now known as Bastian[m]
<s-ol> yeah, custom keyboard / PCB with an atmega32u2
<leeward> nifty
<s-ol> it normally runs the QMK firmware but I'll need custom sooner or later for what I have planned :)
<s-ol> also... finding a reason to do some Zig :P
<leeward> Did I read right that Zig managed to link for you without extra hackery?
<s-ol> ...now I just have to get it to work as well ;)
<s-ol> leeward: no, I'm linking myself with avr-gcc
<leeward> ah, ok, no changes from the last time I looked at zig on avr then
<s-ol> someone mentioned that might be possible *soon* though
<leeward> That would be nice.
Hairok has quit [Quit: Leaving]
<ifreund> if llvm11 has better avr support I guess
<leeward> It could hardly be worse.
<leeward> Last I checked, llvm shelled out to avr-gcc to link.
<cr1901_modern> Same w/ msp430. At least for Rust, it shells out to msp430-elf-gcc
<cr1901_modern> So I imagine msp430 zig would do the same
<leeward> Yeah, I've got an msp430 running Zig code but it's basically the same as the avr testbed.
<leeward> I think there were extra problems there. I don't remember exactly what the problem was though.
<fgenesis> one thing i remember is that it still had problems with PROGMEM data
<fgenesis> because harvard architectures are freaky
<leeward> and everywhere
<s-ol> yeah i was struggling with this, my code ended up in .progmem.data
<s-ol> avr-gcc fixed it in linking, but originally i had -gc-sections on and so it stripped out my code oO
<cr1901_modern> progmem is an AVR thing, right?
<ikskuh> yeah
<ikskuh> zig could address this with addrspace
<fgenesis> last big thing i coded was on a 24bit extended AVR with the funny RAMPZ pointer... had to hack data into the .fini0 section to make use of the upper memory (pointers are still 16bit)
<ikskuh> but i have absolutely no idea how that would work in practise
<cr1901_modern> Meaning zig needs to organically grow __near and __far pointers :P
<fgenesis> and while we're at it, fuck linker scripts *shudder*
<ikskuh> fgenesis: i think zig should support proper progmem pointers
* cr1901_modern unironically wants this
<ikskuh> and not fuckhack that stuff GCC does
<ikskuh> cr1901_modern: we don't need those, we can do that with addrspace
<cr1901_modern> No, _I_ want them so I can write DOS code w/ Zig :)
<cr1901_modern> Though addrspace is prob fine too
<cr1901_modern> The AVR backend of LLVM already uses addrspace for Rust automagically
<FireFox317> does one of you have a small avr program that i can test?
<cr1901_modern> err, rearrange some of those words*
<ikskuh> addrspace would be __near and __far ;)
<ikskuh> *addrspace(FAR) i32
<cr1901_modern> yay :D
<FireFox317> I have llvm 11 build and would like to see if we can get a simple program to compile and link
<leeward> FireFox317: https://hg.sr.ht/~nmichaels/zig-avr-testbed has blink.zig and intblink.zig
<fgenesis> only thing i have is this, but definitely not "small" <.< https://github.com/fgenesis/hwmf
a_chou has joined #zig
<fgenesis> also c++
<FireFox317> leeward, fgenesis, thanks!
<FireFox317> hmm a zig only would be easier to begin with hahah
<ikskuh> fgenesis: stop posing
<FireFox317> but it looks like leeward example should be fine
<ikskuh> even if it's awesome
<fgenesis> the plan is to get there eventually
<ikskuh> oh, addrspace isn't even there yet :(
<fgenesis> i can't wait until the day arrives where i can ditch c++ for good, but that won't arrive anytime soon for me
<ikskuh> hehe
<ikskuh> Zig 1.0
<ifreund> the daemon part of this is pure zig https://github.com/ifreund/rundird
<ikskuh> oh wow, that's old
<fgenesis> 3-digit issue!
<ikskuh> yeah
<ikskuh> not like #6502 *grin* :D
<fgenesis> it's like 5-digit ICQ numbers back in the day
* leeward just had a flashback.
<fgenesis> hrhr
radgeRayden has joined #zig
<FireFox317> leeward, were you able to build object files from zig files before?
<leeward> I was.
<Michcioperz> scary dot
<leeward> The Makefile in that repo worked with some version between 0.6.0 and now.
<Michcioperz> the line for building .o works on 0.6.0 too
<leeward> Yeah, it looks like it worked with 932d096029433b75bed3a6c21eae190ee91d5c20
<s-ol> fgenesis: bit late, but that's a pretty sick demo
<fgenesis> s-ol: thx!
<fgenesis> it was fun making it tho. working on a system where you can't just malloc(1GB) certainly has its charms
<ikskuh> <s-ol> fgenesis: bit late, but that's a pretty sick demo
<ikskuh> fgenesis: told you already, but this is just true. sick!
<ikskuh> i need better art direction on my next demo…
<fgenesis> well there WAS an "esp32-sick" demo right next after this one
<fgenesis> but it was kinda crushed and i feel sorry
<ikskuh> fgenesis: spoiler: i can probably do proper rasterization on my stupid heater control
<ikskuh> HCNICC incoming :D
<fgenesis> of course you can, you have all the mhz
<fgenesis> (and all the ROM)
<ikskuh> ROM is the problem actually *rofl*
<ikskuh> fuckin' flash
<pixelherodev> ikskuh: you saw my comment on z80 speed? ;P
<ikskuh> yes. this is cheating
<pixelherodev> Pft
<pixelherodev> Not the point.
<ikskuh> but: you discovered that modern CPUs are more or less a magic piece of stone
<pixelherodev> It hits PHz levels! Who cares if I have to cheat a little [and not even load a program] in order to do that!
<ikskuh> that does things
<pixelherodev> ikskuh: Actually, I could probably get a 4MHz physical z80 running the emulator at the lower THz level too :P
<pixelherodev> Well, no
<pixelherodev> GHz at least though
<pixelherodev> It's turned at runtime into an infinite loop of "PC += 0x10000; cycles += 0x40000"
<ikskuh> ^^
<ikskuh> that's a quite useless microoptimization :D
<pixelherodev> Not quite
<pixelherodev> It uncovered a few nice improvements while profiling ;)
<ikskuh> ^^
<pixelherodev> Reading the opcode is now much much faster than it was before, for instance
<fgenesis> the best code is code that doesn't exist
<pixelherodev> fgenesis: effectively, yeah :P
<pixelherodev> ikskuh: what it does mean is that nops are truly zero-cost now
<pixelherodev> So if I have a program that's 1000 nops followed by real code, it'll basically jump right to the real code without bothering with the normal processing for the nops
<pixelherodev> Still relatively useless, but it comes at no cost to other code
<ikskuh> this might be problematic for system emulation though
<fgenesis> good luck doing that with self-modifying code
omglasers2 has quit [Read error: Connection reset by peer]
codemessiah has joined #zig
dermetfan has quit [Ping timeout: 244 seconds]
<pixelherodev> fgenesis: no luck is needed
<pixelherodev> cache invalidation is trivial
<pixelherodev> Doing it in the most efficient way possible is not
<pixelherodev> But the simple method of "invalidate pointer on write" is
<fgenesis> set memory to trap on write and handle things in a page fault?
<pixelherodev> That's one way
<ikskuh> hehe, probably the most efficient one
<pixelherodev> Hmm, I think I can do better.
<pixelherodev> Static tracing, maybe?
<pixelherodev> Basically, statically pre-compile most of it; run it through with randomized inputs [fuzzing, basically]; cache all possible code blocks with the corresponding in-memory values
<pixelherodev> that's just cheating, though...
waleee-cl has quit [Quit: Connection closed for inactivity]
xackus has joined #zig
<pixelherodev> fgenesis: I'll take a look later probs
<fgenesis> "all possible values" is attempting to solve the halting problem when it comes to self-modifying code
<ikskuh> yep
radgeRayden has quit [Remote host closed the connection]
donniewest1 has joined #zig
donniewest has quit [Ping timeout: 260 seconds]
<pixelherodev> fgenesis: hence using the equivalent of the Zig max backwards block evaluations
dermetfan has joined #zig
<pixelherodev> Executing up to N cycles, tracing all the while (and potentially profiling for optimizations?), and bundle the recompiler for anything that wasn't caught
xackus has quit [Read error: Connection reset by peer]
xackus has joined #zig
Norbertle has joined #zig
cole-h has joined #zig
<s-ol> huh, something very curious with the zig asm statement on AVR: "rjmp .+0" assembles to "rjmp .-2" (infinite loop)
<s-ol> in GCC asm macro, "rjmp .+0" comes out as the seame "rjmp .+0" in objdump diassembly
<leeward> That is very strange. Are you sure it's true?
<pixelherodev> probably using a different base if that's true
<s-ol> i'm going to try to make a small repro thing I guess
<pixelherodev> One might be based on current instruction while the other is based on next?
<s-ol> certainly seems to be happening :D
<s-ol> pixelherodev: yeah thats what I'm thinking, but its kind of a massive bug if true?
<leeward> definitely sounds like a huge bug
<leeward> Does it reproduce under llvm?
<pixelherodev> s-ol: not particularly
waleee-cl has joined #zig
<pixelherodev> "Behavior differs from GCC" isn't really a bug
<ikskuh> pixelherodev: it is, if the assembly language is well-defined ;)
<ikskuh> which it usually is ;)
<leeward> AVR's certainly is.
<ikskuh> yeah
<pixelherodev> Zig's inline assembler is explicitly meant to be target independent, isn't it?
<ikskuh> nah
<pixelherodev> Source?
<ikskuh> can you please read your sentence again ;)
<ikskuh> how the heck should an inline assembler ever be target independent
<ikskuh> that doesn't work
<ikskuh> and: if the assembly language is well defined (like ARM, AVR, MIPS, …) zig should exactly use that syntax
<Michcioperz> are you saying there's no FJCVTZS instruction on x86? :P
<ikskuh> WHAT
<s-ol> ok this is making no sense; first repro came out without bug, now in the real project both "rjmp .+2" and "rjmp .+0" assemble to "rjmp .+0"?
<s-ol> does zig build-obj use any kind of global cache that I can point a finger at or am I going crazy?
<leeward> It does use a cache.
<leeward> in zig-cache
<s-ol> leeward: there is no zig-cache in my dir
<leeward> It's not global though.
<s-ol> i know that, but only from zig build
<s-ol> but im doing zig build-obj
<leeward> oh, huh, build-obj doesn't cache?
<leeward> I guess that makes sense. I never thought about it.
<ikskuh> there's ~/.cache/zig
<ikskuh> as a global cache
<ikskuh> that's where stuff like the libcs are stored
<larme> Hi all, zig noob here. I have a question about method invocation on struct. I wondered why codes like https://github.com/ziglang/zig/blob/master/lib/std/mem/Allocator.zig#L110 still need to provide the self pointer to the method.
<larme> Google search leads to https://github.com/ziglang/zig/issues/746#issuecomment-368948211. If my understanding is correct, `pub fn someMethod` defined inside struct can be called without providing self pointer while a fn field assigned later should be called with self pointer passed explicitly.
<larme> but why are they treated differently?
<pixelherodev> larme: function pointer != struct member
<pixelherodev> `pub fn blah` within a struct T, *if* the first parameter is of type T, can be invoked as `t.blah` on an object `t` of type `T`
<pixelherodev> With `blah: fn()void`, you have a function *pointer*
<pixelherodev> Function pointers don't support implicit self passing
<larme> thanks for the clarification. I assumed the underlying implementation of struct member function is also done in function pointer. seems that my assumption is wrong
xackus has quit [Ping timeout: 265 seconds]
<pixelherodev> I think the distinction is that the member function is part of T whereas the function pointer is part of t
<s-ol> smallest I could get it, can someone verify?
<s-ol> its not happening exactly like it originally did to me, but rather right now i'm *always* getting an rjmp .+0 no matter what offset (positive, negative, zero) I put in the asm macro
<larme> pixelherodev: thanks!
<s-ol> actually a little smaller: https://pastebin.com/wD61sbVK
codemessiah has quit [Quit: Leaving.]
<leeward> s-ol: rjmp .+0
<s-ol> only becoming more lost now, similar C program now also outputs .+0 for other cases, and I cannot reproduce my original problem anymore?
klltkr has joined #zig
<leeward> I just built it with gcc, and I see an "rjmp .-2"
<s-ol> strange, i'm not even getting it to do that rn
<leeward> asm("nop\n nop\n nop\n nop\nhello:\n rjmp .-2\ngoodbye:\nnop\nnop\nnop\nnop\n");
<s-ol> nope, thats a rjmp .+0 for me - hex 00 c0
<s-ol> avr-gcc 10.2.0 ; objdump 2.35
<leeward> avr-gcc 5.4.0 ; avr-obj-dump 2.26.20160125
<leeward> Interesting.
<leeward> Too bad I don't really have time to dig.
<s-ol> no worries, i also gtg. thanks for checking tho
xackus has joined #zig
frett27 has joined #zig
FireFox317_ has joined #zig
FireFox317 has quit [Ping timeout: 240 seconds]
<FireFox317_> andrewrk, i'm working on zig-bootstrap and i have a question. Is it correct that i can use the zig compiler from the host as a replacement to zig0? So for cross-compiling we can do `zig build-obj` and then the arguments that normally go to the zig0 compiler.
klltkr has quit [Ping timeout: 240 seconds]
marnix has quit [Ping timeout: 272 seconds]
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
<FireFox317_> andrewrk, can i push to the llvm11 branch somehow?
<ifreund> FireFox317_: you can push to your fork and open a PR against it
<FireFox317_> ifreund, ah thanks. I didnt know that also works for other branches than master xd
<ifreund> no problem
Xip has joined #zig
Xip has quit [Read error: Connection reset by peer]
a_chou has quit [Ping timeout: 272 seconds]
frett27 has quit [Ping timeout: 246 seconds]
a_chou has joined #zig
a_chou has quit [Ping timeout: 240 seconds]
xackus has quit [Ping timeout: 265 seconds]
osa1 has quit [Ping timeout: 256 seconds]
marnix has quit [Ping timeout: 256 seconds]
ur5us has joined #zig
guan_ has joined #zig
lanodan_ has joined #zig
dch has quit [Ping timeout: 244 seconds]
JimRM has quit [Ping timeout: 244 seconds]
guan has quit [Ping timeout: 244 seconds]
lanodan has quit [Ping timeout: 244 seconds]
Sahnvour has quit [Ping timeout: 244 seconds]
yawniek has quit [Ping timeout: 244 seconds]
guan_ is now known as guan
jmiven has quit [Quit: reboot]
jmiven has joined #zig
layneson has quit [Ping timeout: 244 seconds]
a_chou has joined #zig
xackus has joined #zig
Norbertle has quit [Quit: Leaving]
OpenSpace has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
OpenSpace has quit [Quit: Leaving]
radgeRayden has joined #zig
lanodan_ is now known as lanodan
nvmd has joined #zig
u0jQx9gPyrYg has joined #zig
<u0jQx9gPyrYg> woohoo, you did it andrewrk \o/ thx!
<andrewrk> FireFox317_, yes it's in theory possible but probably some enhancements to the build script / cmakelists are needed before it works
<FireFox317_> andrewrk, yes i was able to get zig-bootstrap to compile a working zig compiler again :)
<andrewrk> nice!
<andrewrk> with llvm11 branch?
<andrewrk> welcome u0jQx9gPyrYg
<FireFox317_> yup, with the llvm11 branch and llvm11.0.0-rc5
<andrewrk> brilliant
<u0jQx9gPyrYg> i found a thing that is not quite right in std.os.waitdpid: https://github.com/ziglang/zig/blob/master/lib/std/os.zig#L3124 - according to the man: https://man.cx/waitpid(2)#heading4 waitpid should return the pid of the process returning. and i kinda depend on that instead this implementation returns the status, which i don't care about shall i open an issue? i can also send a PR if we agree on how
<u0jQx9gPyrYg> this should be fixed
<u0jQx9gPyrYg> you can all call me stef or stf i have hilites on both. my nick changes from time to time randomly, never mind that. my whois is static.
<ifreund> I agree that os.waitpid() isn't a good abstraction as it loses functionality
<ifreund> I suppose an out parameter for the status wouldn't be the worst thing
<u0jQx9gPyrYg> i have written my own waitpid, which creates a different problem, but worksforme(tm) https://tpaste.us/Lwv4
<u0jQx9gPyrYg> i guess a combination of the original and mine would make sense
<andrewrk> if you open a bug report it will be addressed eventually
<andrewrk> I'll be streaming a demo of the recent big changes to Zig in 1.5 hours. Tour of the new organization of self-hosted compiler code, how bootstrapping works, how the caching system works, and how the optional LLVM extensions work. https://www.twitch.tv/andrewrok/
<FireFox317_> does someone know how i can see a patch that has been done by a debian packager? It is this link: https://tracker.debian.org/media/packages/l/llvm-toolchain-11/changelog-111.0.0rc2-5 and its about the "Fix a FTBFS on armel with libcxx-armhf-ftbfs.diff"
xackus has quit [Ping timeout: 240 seconds]
guan has quit [Ping timeout: 272 seconds]
a_chou has quit [Ping timeout: 260 seconds]
guan has joined #zig
<FireFox317_> nevermind, found it
zie has quit [Quit: ZNC - https://znc.in]
<u0jQx9gPyrYg> i opened an issue for this: https://github.com/ziglang/zig/issues/6581 - if you people agree that there should be a pointer to the status in the fn signature, i can prepare a PR and submit that for review
<andrewrk> u0jQx9gPyrYg, I think the confusion here was that whoever implemented std.os.waitpid (probably me) thought that the return value was the same as the pid parameter
<ifreund> it is usually, but you can pass e.g. 0 to wait the next child to exit or -1 to wait the current process
<u0jQx9gPyrYg> exactly what i do
<u0jQx9gPyrYg> i have a bunch of childs and wait until one returns, and i wanna know which it was
<andrewrk> yes then clearly we should not be destroying this information
<u0jQx9gPyrYg> this is what i do: https://tpaste.us/ZEVd
<u0jQx9gPyrYg> if you see anything stupid in that code, my excuse is that this is my very first zig project. i've been learning zig for 3 days now...
<andrewrk> thanks for the report u0jQx9gPyrYg, we'll get this fixed. feel free to submit a patch if that is something you would like to do
<FireFox317_> andrewrk, so there is a bug in the new libcxx used by llvm11 and i searched a bit, and found a patch from the debian package. Am I allowed to use that or something? I fixed the issue tho
<FireFox317_> s/I/it
<andrewrk> FireFox317_, yes we can carry patches in zig-bootstrap. the idea is to put the patch in a separate commit for auditing purposes
<andrewrk> FireFox317_, we can also carry patches in zig upstream for libcxx. is it something fixed in llvm trunk?
<u0jQx9gPyrYg> huh, i looked through std/os.zig and std/os/linux.zig but did not find an example of returning a struct.
<FireFox317_> andrewrk, yeah it has to go in zig upstream, because it fails building anything when doing `zig c++ -target arm-linux`
<FireFox317_> lets see if they fixed it in trunk
<andrewrk> u0jQx9gPyrYg, I believe getrlimit is an example
<andrewrk> ideally we would only carry patches when they are fixed upstream already
<FireFox317_> andrewrk, looks like it hasn't been fixed upstream
<FireFox317_> or downstream idunno.
<andrewrk> downstream is us since we copy from them :)
<pixelherodev> andrewrk: what's the issue with the CBE patch? I clearly misunderstood how resolvePeerTypes works, mind explaining what I'm missing?
<andrewrk> yeah, try it with the left peer being comptime_int and the right peer being u32
<andrewrk> or vice versa. one of those is going to be broken
* pixelherodev nods
<pixelherodev> Will do
<pixelherodev> I should get in the habit of adding tests anyways
<pixelherodev> For fixes*
<pixelherodev> I usually add tests when adding features, but I haven't been doing it when doing fixup commits
donniewest1 has quit [Quit: WeeChat 2.9]
dermetfan has quit [Ping timeout: 244 seconds]
<pixelherodev> Thanks for the pointer :) (sending this ten minutes late because I forgot to hit enter lol)
FireFox317_ has quit [Ping timeout: 244 seconds]
jjsullivan1 has quit [Remote host closed the connection]
a_chou has joined #zig
_whitelogger has joined #zig
jjsullivan1 has joined #zig
msingle has joined #zig