<pixelherodev>
(for arithmetic + assignments, at least)
<pixelherodev>
Still pretty impressive though :)
<pixelherodev>
That means a loooot more CBE + SPU II work is going to be incoming soonish, because I'm going to want to get as much as possible working now :D
<andrewrk>
then https://clbin.com/757G9 to test register/stack allocations across conditional branches
<pixelherodev>
Awesome :)
<pixelherodev>
andrewrk: when you get these intermediate tests working, mind pinging me so I know there's more frontend stuff to integrate into my backends?
<andrewrk>
there's already pending test cases for the C backend
<pixelherodev>
I'll work on those tomorrow probably
<pixelherodev>
Doing a bit more emulation work tonight, though I'll probably find time to do the interpreter too
<andrewrk>
does your CBE test harness support compare output? e.g. it would run zig cc on the output code and then run the binary?
<pixelherodev>
... no, but I'll definitely fix that
<pixelherodev>
That's a good call
<pixelherodev>
Making a TODO list for tomorrow
<andrewrk>
it's pretty sweet that we have that available to us :) pretty slick IMO
<pixelherodev>
Yeah
<pixelherodev>
To be honest, it hadn't even occurred to me to do that
<andrewrk>
I think it should by default be activated for all the compare output test cases, but you could explicitly disable testing the C backend for a particular case
<pixelherodev>
That's simple enough
<leeward>
ronsor: It's a good candidate, and not much else really tries.
<andrewrk>
also we should add object format to std.zig.CrossTarget
<andrewrk>
pixelherodev, there's the C backend use case, and also the use-elf-on-windows use case
<pixelherodev>
I also want to add raw ihex / binary output soonish
<pixelherodev>
Is it not supposed to print a backtrace on those?
<andrewrk>
it's a standard safety check
<andrewrk>
should be handled the same way as any other, by calling the panic function
<andrewrk>
default panic function implementation prints a backtrace
<pixelherodev>
Right, it's probably a separate bug :(
<pixelherodev>
Yep
<pixelherodev>
Segfault within detectTTYConfig lol
<pixelherodev>
Because I'm running this over SSH XD
dputtick has quit [Ping timeout: 240 seconds]
dputtick has joined #zig
<leeward>
In the default init-exe main.zig, should it be `std.debug.print("All your codebase are belong to us.\n", .{});`, `std.log.alert(.howAreYouGentlemen, "All your codebase are belong to us.", .{});`, or something else?
<leeward>
Vote now, for great justice.
<leeward>
(see also: PR 5941)
<andrewrk>
std.log.info(.app
<leeward>
So boring.
sqwishy has quit [Ping timeout: 260 seconds]
sqwishy has joined #zig
<leeward>
For what it's worth, several of my co-workers have made clever zero wing references whenever I mention Zig.
<andrewrk>
people know what the "hello world" text is for, but they've never seen std.log or the "scope" parameter before
<leeward>
Yeah, I agree it's a good idea. Much more useful as a template for starting a real program.
<pixelherodev>
Almost done with SPU II interpreter lol
<pixelherodev>
Whoops, half-edited post :(
<pixelherodev>
Meant to say that I'm almost done, and most of the work was tweaking my old one to not have JIT support :P
<pixelherodev>
~250 lines and shrinking
<leeward>
Hooray for shrinking!
nvmd has quit [Quit: Later nerds.]
<pixelherodev>
Yep :)
<pixelherodev>
Some of the changes I'll probably backport later
<pixelherodev>
Alrighty, ~230 lines, time to actually test it out
<daurnimator>
I don't think using std.log for hello world is a good idea...
<daurnimator>
std.log should be used for debugging and informational purposes; not as the primary output of a program
<pixelherodev>
Yeah, I think I second that
<daurnimator>
i.e. it should really be `try std.io.getStdOut().writer().print("All your codebase are belong to us.\n", .{})`
<pixelherodev>
Normal output goes to stdout, logging goes to sterr
<pixelherodev>
stderR*
<pixelherodev>
stderr*
<leeward>
As opposed to std.debug.print?
<daurnimator>
leeward: yep
<pixelherodev>
Hmm, I'm actually really unsure
<pixelherodev>
There's good arguments both ways
<leeward>
std.debug.print goes to stderr too, no?
<pixelherodev>
Yep
<daurnimator>
IMO std.debug.print is for the sort of debugging cycle where you wonder "is this being reached and in what order" -> insert print -> rerun -> add more prints -> rerun -> remove prints
<andrewrk>
I don't think init-exe should initialize an application for writing to stdout. logging is much more common than actually writing to stdout
<andrewrk>
the debug cycle is exactly what one is participating in with init-exe
<pixelherodev>
CompareOutput tests are for native-native only, right?
<andrewrk>
pixelherodev, correct
<pixelherodev>
Probably want something else for cross compilation
<andrewrk>
interesting, the x86_64 ABI document recommends to use %rax and %rdx (2 registers) for return values. Might be interesting to take advantage of this for error union types
<pixelherodev>
`ctx.cross(target, etc)`
<pixelherodev>
Yeah, %rax and %rdx are the first two, after which everything is supposed to be in memory IIRC
<pixelherodev>
Been a while since I implemented it :P
<andrewrk>
pixelherodev, a CrossTarget can specify the concept of "native" and it can also specify the concept of choosing a part of the target. the compare output test cases should always compile them, but then only run (and compare output) if the test system is capable of running the output. zig build has integration with wine, qemu, and 2 wasm interpreters, which can be enabled to run additional tests
<andrewrk>
and then of course if the native target is capable of running the selected target
<pixelherodev>
Ah, so I should just add a CrossTarget to CompareOutput
<pixelherodev>
Currently it's *implicitly* native-native
<andrewrk>
there already is
<pixelherodev>
It doesn't check a t - hmm
<pixelherodev>
Ohhh right
<pixelherodev>
It's part of the Case, not the particular Updare
<pixelherodev>
Update*
<andrewrk>
CrossTarget already has the getExternalExecutor function
<pixelherodev>
The interpreter is *internal* though :P
<pixelherodev>
But that's separate
<pixelherodev>
The shortcut APIs should expose the Target, and the runner should actually pay attention to it for CompareOutput
<pixelherodev>
Going to be busy tonight, it's on my todo list for the morning though :)
ur5us has joined #zig
<andrewrk>
test.zig:9:9: error: TODO implement analyzeInstAlloc
<fengb>
But it’d be different depending on optimization right?
<andrewrk>
for debug builds, every function can have its machine code generated independently, and we know the stack frame size immediately upon doing it. for builds with optimization passes such as function inlining, the value is known after the optimization passes, which will be done for the whole program
<andrewrk>
so it's a comptime value, but any attempt to read the value and do comptime logic with it is likely to cause a circular dependency if the target function is a child of the call graph
<andrewrk>
the circular dependency could be broken with a no-inline call
<pixelherodev>
Nice
<andrewrk>
gonna extract some of Module.zig into zirgen.zig
<pixelherodev>
What parts?
<andrewrk>
analyzeInst and the corresponding callees
<pixelherodev>
Ahh, gotcha
<pixelherodev>
Thanks for the heads up :)
<andrewrk>
or maybe ziranal.zig
<gruebite>
What's going on when I store an "anytype"? @sizeOf on the type says 0, but it appears like I can do reflection on instantiated structs
<pixelherodev>
`error: InvalidExe` <- woot
<andrewrk>
or maybe just anal.zig
<pixelherodev>
I mean, boo, but also yay - I got it building correctly within a test case, just need to hook up CompareOutput with the interpreter
<pixelherodev>
Rather, it should switch on the target - native => current_code, spu_2 => interpreter, else => panic
<pixelherodev>
andrewrk: are we going to want to differentiate between stdout / stderr in execution cases?
<andrewrk>
no. compare stdout. print stderr on test failure as debugging output
<pixelherodev>
Gotcha
<pixelherodev>
andrewrk: what's the indicator for "native" from a std.Target?
<pixelherodev>
I don't see anything at a quick grep
<pixelherodev>
Ah, it's a CrossTarget thing, not std.Target
<pixelherodev>
Whoops, thought I had a different type
* pixelherodev
facepalms
<andrewrk>
a CrossTarget is resolved into a Target, which may involve detection of native things
<pixelherodev>
Right, I figured it out
<pixelherodev>
It's coming together :)
<gruebite>
:)
<pixelherodev>
Why is toTarget deprecated?
_whitelogger has joined #zig
gert_ has joined #zig
gert_ has quit [Quit: WeeChat 2.8]
craigo has quit [Ping timeout: 256 seconds]
<pixelherodev>
Interpreter integrated! :)
B4s1l3 has joined #zig
B4s1l3 is now known as opDispatch
opDispatch has left #zig [#zig]
<andrewrk>
pixelherodev, use std.zig.system.NativeTargetInfo.detect
<pixelherodev>
That works non-native?
<pixelherodev>
Ah, I see
<pixelherodev>
That's really overkill here though
<pixelherodev>
We explicitly *don't care* about *any* native info
<andrewrk>
why don't we care?
<pixelherodev>
Generally, I'd think we want tests to be uniform regardless of hardware - if it's not specified, we probably don't want a CPU feature influencing the test, and should use the baseline
<pixelherodev>
Or I could be completely off-base, and we do want it :P
<andrewrk>
we do want it
<pixelherodev>
Gotcha
<andrewrk>
first of all we want to test detecting native things
pmwhite has quit [Ping timeout: 260 seconds]
_whitelogger has joined #zig
stripedpajamas has quit [Quit: sleeping...]
<pixelherodev>
andrewrk: does it make more sense to parse the File.ELF into binary, or to add the raw binary backend first?
<andrewrk>
no sense in doing extra work and then tossing it out
<pixelherodev>
Or, the really lazy short-term route, could invoke objcopy as a ChildProcess :P
<pixelherodev>
That'd be like two lines :P
<pixelherodev>
Yeah, that's what I thought
<pixelherodev>
I'll probably push what I have later, then block this PR on a separate one adding IHEX and raw backends
<andrewrk>
I'm sure you already know my stance on inserting dependencies on things being installed on the system
<pixelherodev>
Yep lol, wasn't serious
<pixelherodev>
Hmm, ikskuh: is it intended that programs should be able to initialize RAM on startup without explicit copying from ROM? I remember something about supporting RAM in IHEX
ur5us has quit [Ping timeout: 260 seconds]
<pixelherodev>
Hmm, was I overzealous here? Should e.g. PT_LOAD be able to go at addresses outside the target address space?
<pixelherodev>
The headers don't actually get loaded when the binary does (either flashing to a microcontroller, loaded by OS, etc), so I don't think their addresses actually matter
<pixelherodev>
Only the *contents* addresses matter
<andrewrk>
pixelherodev, time to rebase, I pushed the big refactoring thing
<pixelherodev>
Just now?
<pixelherodev>
I'm in the middle of a different rebase lol
<andrewrk>
0965724e316
<andrewrk>
it doesn't touch link.zig or codegen.zig
<pixelherodev>
I did a bit of work in codegen (basically, ignoring unknown arch in resolveABI when there are zero params) which interferes with return values :(
<pixelherodev>
So I need to finish this one, then do another one
<pixelherodev>
:(
<pixelherodev>
Whelp
Nypsie has joined #zig
<pixelherodev>
Oh neat, clean rebase!
<pixelherodev>
Rebasing onto the refactor required no intervention from me :)
<pixelherodev>
Which makes sense, since this PR is entirely focused on a backend, and doesn't touch the frontend
<andrewrk>
sounds like our version control system agrees with my organization of files & code :)
<pixelherodev>
:)
<pixelherodev>
Night! I'll work on ihex tomorrow :)
<andrewrk>
night
<pixelherodev>
Ah right, missing an item on the PR checklist: "clean up stupid debugging tweaks"
redj_ has joined #zig
<pixelherodev>
I think that, among other things, i overrode the logging handler, added some debug.prints, and possibly worse :P
<pixelherodev>
that's tomorrow me's problem
redj has quit [Ping timeout: 256 seconds]
<ronsor>
are safety checks also applied to C code?
<daurnimator>
ronsor: yes
<ronsor>
welp that explained my issue
<ronsor>
had to disable it for some third-party C code
marnix has joined #zig
<daurnimator>
ronsor: time to report a bug with that C code :)
_whitelogger has joined #zig
<daurnimator>
ronsor: you can just try to build the c code as normal c code with -fsantize=undefined on
Snetry has quit [Ping timeout: 240 seconds]
Snetry has joined #zig
dtz has joined #zig
knebulae has quit [Ping timeout: 260 seconds]
r4pr0n has joined #zig
<r4pr0n>
ifreund: quick question about river: how are tags handled in multi monitor mode? do they have separate tagsets like in dwm or one for all?
Snetry has quit [Ping timeout: 256 seconds]
r4pr0n has quit [Ping timeout: 240 seconds]
Snetry has joined #zig
marnix has quit [Read error: Connection reset by peer]
Snetry has quit [Ping timeout: 256 seconds]
marnix has joined #zig
Snetry has joined #zig
Snetry has quit [Ping timeout: 260 seconds]
cole-h has quit [Quit: Goodbye]
Snetry has joined #zig
Snetry has quit [Ping timeout: 256 seconds]
squeek502_ has joined #zig
Snetry has joined #zig
squeek502 has quit [Ping timeout: 264 seconds]
Nypsie has quit [Quit: WeeChat 2.9]
lanodan has quit [Quit: WeeChat 2.8]
<ikskuh>
pixelherodev: why do you split RAM/ROM in your simulator?
dermetfan has joined #zig
dermetfan has quit [Ping timeout: 244 seconds]
knebulae has joined #zig
ur5us has joined #zig
lanodan has joined #zig
waleee-cl has joined #zig
marnix has quit [Read error: Connection reset by peer]
st4ll1 has quit [Ping timeout: 246 seconds]
ur5us has quit [Ping timeout: 244 seconds]
dermetfan has joined #zig
nycex has joined #zig
<protheory8-new-m>
I submitted Zig compiler to Flathub as Freedesktop SDK extension, is this fine?
<daurnimator>
protheory8-new-m: I don't see the point; but I also don't see the harm
<daurnimator>
so if someone finds it useful; and it doesn't keep them out of date... great :)
<protheory8-new-m>
Why don't you see a point?
<protheory8-new-m>
I mean I guess not that many people make GUI applications in Zig, so you might be right.
ask6155 has joined #zig
<ask6155>
hello!
<protheory8-new-m>
Hi!
<ask6155>
I think zig has a bug, I tried to compile a 1.2mil file and it bricked my pc ;)
<ifreund>
stage one is slow, this is known
<ifreund>
stage two is much faster but not yet complete
<daurnimator>
ask6155: you made a 0.0001 inch file?
<ifreund>
the latest numbers andrew gave were that self-hosted is "486x faster, using 96x less memory"
<ifreund>
which will probably decrease a bit as it grows more feature complete, but it certianly looks very promising
<ask6155>
daurnimator: ;)
<protheory8-new-m>
So how do I make Zig SDK extension more useful?
<ifreund>
generally I have a use case first and then make something to solve it rather than the other way around
dermetfan has quit [Ping timeout: 240 seconds]
<protheory8-new-m>
There is a use case?
marnix has joined #zig
<protheory8-new-m>
To compile Zig apps in Flatpak sandbox without downloading Zig compiler while building app
pmwhite has joined #zig
ask6155 has quit [Remote host closed the connection]
dongcarl has quit [Quit: Ping timeout (120 seconds)]
dongcarl has joined #zig
<pixelherodev>
ikskuh: because oops
<ikskuh>
pixelherodev: that explains a lot
<pixelherodev>
:(
<ikskuh>
i recommend just using a [1<<16]u8
<ikskuh>
:D
<pixelherodev>
That's what I'm doing, I just said that in GH :P
<ikskuh>
also, why do you allocate those with an allocator? *screams*
alehander92 has joined #zig
<pixelherodev>
... also a good point
<pixelherodev>
Any other blatantly stupid decisions?
<ikskuh>
probably? D
<pixelherodev>
Not blatant enough, clearly ;)
craigo has joined #zig
<ikskuh>
do you want me to take a closer look? :D
<pixelherodev>
If you want to, that'd be awesome
<pixelherodev>
Unrelated, is there a specific reason freebsd CI doesn't test stage2?
<ikskuh>
good thing: your tests all don't need any MMIO
<pixelherodev>
Yep
<ikskuh>
you can just check if certain memory addresses contain the right data and you're good
<pixelherodev>
I can probably do that via the UART, too
<pixelherodev>
A CompareOutput test, with a specific known pattern
<ikskuh>
what UART?
<pixelherodev>
Oh right
<ikskuh>
there's no UART :D
<pixelherodev>
I'm dumb.
<pixelherodev>
That makes things harder
<pixelherodev>
I might just define a custom UART for the purposes of the test
<ikskuh>
why?
<pixelherodev>
Write-only, single-address
<ikskuh>
as i just said:
<ikskuh>
check if certain memory addresses contain certain patterns and you're done
<pixelherodev>
For CompareOutput tests, which - well - compare the output of a test program with the expected value
<ikskuh>
return simulator.memory[0x1000…0x1008]
<pixelherodev>
So you're basically saying, use an in-memory buffer as the output?
<ikskuh>
yes
<pixelherodev>
That... actually works really really well, yeah
<ikskuh>
think simple!
<pixelherodev>
Yeah
<pixelherodev>
Thanks for the feedback, it helps :)
<pixelherodev>
That link doessn't work for some reason :(
<ikskuh>
codegen.zig, 783
<pixelherodev>
Ah, that's on purpose
<pixelherodev>
That's actually completely correct yay
<pixelherodev>
It's `jump *(addr)`
<ikskuh>
okay
<pixelherodev>
ikskuh: it's related to incremental compilation
<pixelherodev>
If the address of a function changes, the jump instruction doesn't change, only the value in the offset table
mikdusan has quit [Quit: WeeChat 2.6]
<ikskuh>
looks okay so far
<pixelherodev>
ikskuh: nothing against the undefined0 trap?
<pixelherodev>
:P
marnix has quit [Read error: Connection reset by peer]
<ikskuh>
only that it's undefined0 :D
marnix has joined #zig
<pixelherodev>
Hmm, this might be a spot to use the Model - use undefined0 as "shutdown" for an internal testing Model (the interpreter), leave it as undefined for general compilation
<pixelherodev>
Then, instead of `asm volatile("undefined0")`, it'd be `asm volatile("shutdown")`, a CPU extension to kill the emulator ;P
<pixelherodev>
That'd only be valid for internal testing though
<ikskuh>
why not just make a ".dw 0x8000" or something
<pixelherodev>
?
<pixelherodev>
As an exit command?
<ikskuh>
yep
<ikskuh>
that would make it clear that it's not an actual instruction
<pixelherodev>
Which one's that?
<pixelherodev>
ikskuh: how about nop?
<ikskuh>
what is "nop"? ;)
<pixelherodev>
always-zero-zero-copy-discard
<ikskuh>
my point is: any mnemonic would look like it's an actual instruction
<ikskuh>
for example "ud2" is a *valid* opcode on x86
<pixelherodev>
Hmm, the internal assembler receives asm as a string - we *could* just make it compatible with your assembler ;)
<ikskuh>
that would be my long term goal anyways :D
<pixelherodev>
I don't doubt it :P
<ikskuh>
writing some highly optimized inline asssembly routies
<pixelherodev>
Heck, how modular is your assembler?
<ikskuh>
yes? :D
<pixelherodev>
Mind sending a PR to *my* PR to add it to std.spu.assembler ?
<ikskuh>
haha
<pixelherodev>
:P
<pixelherodev>
I'm kidding, I got it
<ikskuh>
how to do that?
<pixelherodev>
I've already got std.spu.interpreter, I'll just merge your assembler in and tweak it
<pixelherodev>
Oh, on that note: all the issues with the interpreter can be traced back to the fact that I was trying to adept an Ashet interpreter to the test suite instead of making a pure SPU-II interpreter from scratch
<ikskuh>
well
<ikskuh>
you just didn't strip out everything ashet specific (which were the read*() and write*() functions)
<pixelherodev>
I stripped out even more that didn't make it into the PR lol
<pixelherodev>
Woot, down to ~170LoC for the interpreter ;)
<ikskuh>
the real HW has a 16 bit bus, 15 bit address width
Ashpool_ has joined #zig
<ikskuh>
and two lanes for "byte lane select"
<ikskuh>
even more correct would be a `fn write(addr: u15, value: u16, bits: u2) void` then
waleee-cl has quit [Quit: Connection closed for inactivity]
<ikskuh>
addr = 1 is adressing byte 2 & 3
<ikskuh>
if you want to access byte 3, the CPU does this:
<ikskuh>
addr = 1, value = ???, bls = 0b10
<ikskuh>
if you want to access 16 bit value, bls = 0b11
<ikskuh>
for lower byte, you use bls=0b01
<pixelherodev>
Ohhhh, I see
Ashpool has quit [Ping timeout: 256 seconds]
<pixelherodev>
ikskuh: don't you mean addr=1 addresses bytes 1 & 2? :P
<ikskuh>
no
<ikskuh>
addr=0 → byte 0,1
<ikskuh>
addr=1 → byte 2,3
<pixelherodev>
Ohhhhhh right
<pixelherodev>
15-bit addressing
* pixelherodev
facepalms
<pixelherodev>
Clearly, the tea hasn't kicked in yet.
<pixelherodev>
ikskuh: any reason not to require bits to be comptime?
<ikskuh>
nah
waleee-cl has joined #zig
Nypsie has joined #zig
<ikskuh>
andrewrk: found a regression in build.zig when overwriting output_dir: build.zig hangs in atomicSymLink failing to create a path as the original path is invalid
<ikskuh>
i wonder how to output files to arbitrary directories with build.zig
<pixelherodev>
I think it's come up before
<pixelherodev>
Maybe grep the logs?
<pixelherodev>
:P
<pixelherodev>
ikskuh: that should still by bytes not bits, right?
<pixelherodev>
It's which *bytes* you want
<ikskuh>
it's "byte lane select"
<ikskuh>
you can do 0b01, 0b10, 0b11
<pixelherodev>
Right, I know
<ikskuh>
0b00 is possible, but doesn't make sense
<pixelherodev>
Which "byte lanes" do you want
<pixelherodev>
0b00 is compileError
<ikskuh>
call it bls or byte_lane_select
<pixelherodev>
bls works, yeah
<pixelherodev>
ikskuh: if 0b10, is it u8, or u16 with the upper 8 bits set?
<ikskuh>
it's 0xVVXX
<ikskuh>
with VV the value to write and XX are don't care bits
<pixelherodev>
I mean for reads
<ikskuh>
same
<pixelherodev>
but that's what I thought
<pixelherodev>
that's less fun
<ikskuh>
the lower bits are undefined and may be anything
<pixelherodev>
yep yep
<ikskuh>
no bugreport today
* ikskuh
is too tired to do anything useful atm
<pixelherodev>
Just going to have it always be u16
<pixelherodev>
Caller can cast down when desired
<pixelherodev>
This might be unnecessarily precise though
<ikskuh>
that's why i told you to just to a {write,read}{8,16} functions
<ikskuh>
which model the real hardware precise enough
<ikskuh>
and are convenient enough
<pixelherodev>
Yeah, probably should do that
<pixelherodev>
Stupid human brain. Stupid sunk cost fallacy.
<ikskuh>
you should learn not to overengineer things ;)
<pixelherodev>
On the bright side, both ways (with or without bls) mean no more possible error on read/write
<pixelherodev>
I might *actually* start working on a ZIR JIT soon
<pixelherodev>
Hmm nah, not ZIR. Trying to figure out the best way to do this...
<pixelherodev>
I might finally rewrite the tricarbon backend using what I've learned from self-hosted, instead
stripedpajamas has joined #zig
<pixelherodev>
ikskuh: ip should wrap, right?
marnix has joined #zig
<pixelherodev>
Okay, infinite loop of `[SPU_2_Interpreter] (crit): Executing 0x0000 zero zero copy discard`, *now* it's on hold until ihex
<ikskuh>
<pixelherodev> ikskuh: ip should wrap, right?
<ikskuh>
yes, it should
<ikskuh>
ah, i see you're cheating :D
<ikskuh>
sp and bp are not initialized :D
<ikskuh>
also, if you're using "undefined0" as a instruction, you should define that instruction somewhere ;)
<pixelherodev>
sp and bp are initialized to zero, aren't they?
<ikskuh>
nope
<pixelherodev>
Ah yeah, that's true
<ikskuh>
they are defined to be initialized with undefined :D
<pixelherodev>
Gotcha
<pixelherodev>
Anything else?
<ikskuh>
not for now :D
<pixelherodev>
Good :)
<pixelherodev>
Should we move your ihex library into std.ihex?
<pixelherodev>
We've already got std.elf
<pixelherodev>
So it makes sense
<ikskuh>
yeah why not?
<pixelherodev>
Then it's just a matter of extending Link.FILE
<pixelherodev>
File*
tsujp has quit [Ping timeout: 240 seconds]
<ikskuh>
if my brain is less slow tomorrow, i'm going to prepare zig-network to be part of std
<pixelherodev>
nice :)
<pixelherodev>
andrewrk: any reason not to test stage2 in freebsd ci?
<ikskuh>
only thing i feel bad for is marler8997 to rewrite a lot of stuff of they latest network update :D
tsujp has joined #zig
<andrewrk>
pixelherodev, yes, sr.ht it doesn't have enough RAM for stage1 to build stage2
<pixelherodev>
... oh. Right. Stage1 is memory hog. Forgot about that
tsujp has quit [Remote host closed the connection]
tsujp has joined #zig
<andrewrk>
ikskuh, that symlink regression sounds related to https://github.com/ziglang/zig/pull/5879. I bet if you made a bug report kubkon would fix it right away
<ikskuh>
that would be weird, i used the master build from yesterday, it broke with the overnight build
<pixelherodev>
Oh neat, optimization to stage1 + simpler stage2!
<pixelherodev>
:)
Ashpool_ is now known as Ashpool
<ikskuh>
andrewrk: i don't think it's a problem with symLink itself
<andrewrk>
first evidence that self-hosted debug builds generate better code than llvm
Ashpool_ has joined #zig
<pixelherodev>
Nice :D
<ikskuh>
ha, nice
<pixelherodev>
And this is before constant propagation and suchlike
<ikskuh>
what's the current status of stage2? what features are implemented already?
<Nypsie>
Apologies for my ignorance but does this mean it uses less instructions to perform the same 'thing'?
Ashpool has quit [Ping timeout: 240 seconds]
<ikskuh>
yep
<Nypsie>
Cool! and thanks :)
<fengb>
Wow that's like 20% faster
<Snektron>
What about wall clock time?
<andrewrk>
stage2 is missing a lot of stuff, it still doesn't have loops, comptime, generics, register/stack allocation across conditional branches, safety, structs, ...
<ikskuh>
comptime is a pure ZIR transformation in stage2, right?
<andrewrk>
yes it's part of the untyped ZIR to typed IR transformation
<pixelherodev>
fengb: wall clock will be zero vs zero lol
<andrewrk>
too hard to measure wall clock time without more stage2 features being implemented :)
<pixelherodev>
That too
<pixelherodev>
:P
<andrewrk>
even so, the perf stats have a strong correlation to wall clock time, and are more insulated from nondeterminism
pmwhite has joined #zig
<fengb>
More time spent on the syscall to measure than it would to execute :(
<pixelherodev>
I'd help with those features, but I'm trying to avoid stepping on your toes - hence, focusing on backends, while you do the frontend work
<fengb>
Getting to the quantum level of coding
<andrewrk>
pixelherodev, there's a lot to do in zir_sema.zig and for many functions you can port from ir.cpp
<pixelherodev>
Good to know
<pixelherodev>
At the very least, I'll let you know when I start working on that
<pixelherodev>
I'm just going to do std.ihex as part of the SPU PR, I don't want to have to deal with rebasing :P
<pixelherodev>
For x86, "Functions with the probe-stack attribute set to “inline-asm” are now protected against stack clash without the need of a third-party probing function and with limited impact on performance."
<pixelherodev>
Does this help with the stack lookup at startup?
<pixelherodev>
Or am I completely misunderstanding it (probably)?
<andrewrk>
it has to do with stack overflow protection hardening feature
<pixelherodev>
Gotcha
<pixelherodev>
lol, someone's going to have to spend a looooooooot of time on those release notes
<andrewrk>
stack probing turns stack overflows into segfaults rather than security vulnerabilities
<pixelherodev>
Gotcha, that's neat
<andrewrk>
it "pokes" a byte from each page in stack frames that span more than 1 page
<scientes>
better "optimized out" value tracking in debug
<andrewrk>
wonderful
<pixelherodev>
oh lol this is hilarious
<pixelherodev>
`Clang now supports the GNU C extension asm inline; it won’t do anything yet, but it will be parsed.`
<pixelherodev>
How is that useful?? That's *worse* than a compiler error!
<ifreund>
does that mean that they're speeding up their release schedule or something?
<pixelherodev>
Wait, C++ applies language fixes *retroactively*?!
<pixelherodev>
What the *heck*?!
cole-h has joined #zig
<Sahnvour>
what do you mean ?
<pixelherodev>
`This paper was adopted by the C++ committee as a Defect Report resolution, so it is applied retroactively to all C++ standard versions.`
<fengb>
Goes back in time
<pixelherodev>
exactly what I said
<pixelherodev>
It affects *older standards*
<andrewrk>
ifreund, no, they might actually just release on time for once
<pixelherodev>
`c++11` today is not what it was yesterday, effectively.
hspak has joined #zig
<andrewrk>
zig will be taking that approach as well. we will have the concept of "the spec had a bug" which can mean technically breaking changes applied without rolling major version
<Sahnvour>
since multiple c++ standards are widely used, it kinda makes sense ?
<andrewrk>
obviously the goal is for the spec to have 0 bugs when it is finalized
<Sahnvour>
backports are also a thing
<pixelherodev>
andrewrk: what would be an example case for it in Zig?
<pixelherodev>
Sahnvour: That's missing the point
<andrewrk>
for example, a literal typo in the spec that changed the semantic meaning
<Sahnvour>
pixelherodev: care to elaborate ?
<pixelherodev>
Valid code ceases to be valid
<pixelherodev>
Imagine you're a distro maintainer and a few dozen packages (potentially unmaintained or barely maintained upstream, or in the repo) break on a compiler update
<Sahnvour>
what paper is it ? didn't find your quote in the linked release notes
<scientes>
pixelherodev, that is completely normal
<pixelherodev>
scientes: I wasn't saying it is / isn't normal
<pixelherodev>
I was saying that I personally think it *shouldn't* be :P
<scientes>
but you don't have enough experience for that belief
<scientes>
pixelherodev, an example would be if the floating point to decimal conversion changed algorithm
<scientes>
that would technically be a breaking change
<scientes>
but if the old was pretty funky, and the new is ryu...
<andrewrk>
rust has this concept too
<pixelherodev>
Rust doesn't even have a spec though :P
<pixelherodev>
So it's not like they can change the spec lol
<andrewrk>
a spec is only one kind of stability tool
<andrewrk>
rust's stability story is actually quite sophisticated, on a per-decl basis
<companion_cube>
editions ftw
<andrewrk>
one would be a fool to not take rust seriously
<pixelherodev>
I didn't say I wasn't taking it seriously, I specifically referred to the spec
<pixelherodev>
For something like C++ - which has versioned standards - what's the reasoning to change older ones?
<pixelherodev>
From my perspective, Rust is still in the incremental improvements / language refinement phase
<andrewrk>
internal inconsistency, for example. if the spec contradicts itself
<companion_cube>
incremental improvements that are backward compatible thougfh
<companion_cube>
-f
<pixelherodev>
I'm not saying they aren't, I'm saying they shouldn't necessarily
<companion_cube>
also interesting to note that C has had a spec for a long time, but, I think, a threaded memory model since only C11?
<pixelherodev>
I'd prefer if Rust had waited longer to release 1.0 and kept refining
<companion_cube>
no one would have used it then 🤷
<pixelherodev>
People use Zig ;)
<companion_cube>
and you can't find what's ergonomic without users
<companion_cube>
well, a lot more people use rust, afaik
tsujp has quit [Ping timeout: 240 seconds]
xackus has quit [Read error: Connection reset by peer]
xackus_ has joined #zig
<pixelherodev>
Anywho, your thoughts are appreciated
craigo has quit [Quit: Leaving]
<pixelherodev>
It's certainly interesting to think about
craigo has joined #zig
marnix has joined #zig
<companion_cube>
it's hard to find a balance between a frozen language, and something that breaks regularly (like ruby, I heard?)
<ifreund>
worst case is what python did
<andrewrk>
I want zig to be close to frozen, but we have to get there first
<pixelherodev>
And I'll do my part to help us get there :)
<fengb>
Ruby is actually surprisingly stable despite its semi-fast pace
<fengb>
I can't remember a single time when an upgrade didn't just work. Rails on the other hand... breaks constantly :P
Ashpool_ is now known as Ashpool
<ikskuh>
<pixelherodev> Probably the overthinking it part.
<ikskuh>
don't overthink it. ihex is god damn stupid :D
<ikskuh>
just emit the bytes into a writer and done
<pixelherodev>
I know
<pixelherodev>
I really just need to fix up text block allocation
<pixelherodev>
ikskuh: the biggest thing is the boilerplate
<pixelherodev>
The interface used for File / Scope / etc has its advantages, but boilerplate is not one of them
<shakesoda>
my zig rendering hasn't gotten so much as a hint of that shiny new raytracing stuff
<andrewrk>
Snektron, is that rendering in realtime?
<pixelherodev>
When does File.ELF *not* own its file handle?
<Snektron>
At about 1000 fps on my laptop with an 4th gen intel
<andrewrk>
wow
<andrewrk>
pixelherodev, you can make it always own the file handle
marnix has quit [Ping timeout: 240 seconds]
<pixelherodev>
And get rid of the bool?
<Snektron>
shakesoda: this is regular ray tracing, no rtx involved. The shader is quite simple, its just a single sphere intersection
<pixelherodev>
Or do you mean "there's a method to do so?"
<pixelherodev>
I'm not surprised by the performance there
<frett27>
snektron, cool !!
<Snektron>
A debug shader before i get to write the real implementation
<shakesoda>
Snektron: oh, i figured you were doing rtx stuff
<shakesoda>
bit different
<Snektron>
Dont have an nvidia card, not in my pc either. I'd love to try it out some time though
<Snektron>
Maybe when amd gets a similar feature :)
<shakesoda>
well, amd has a similar feature... just not also on pc yet!
<shakesoda>
:D
<shakesoda>
alas, i have none of THAT hardware either.
<shakesoda>
although word on the street is that i'll be getting something else fun soon
<Snektron>
Supposedly they have something in store for the next generation, though those cards are bound to be expensive
<shakesoda>
the ps5/xbx have hardware rt
<shakesoda>
and afaik the next gen cards are going to be the same architecture, and similar-ish launch timeline
<shakesoda>
looking forward to that existing cross vendor on pc
<Snektron>
The vulkan rtx-type ray tracing got lifted to either a general extension or core as well, which means a vendor-independent interface
riba has joined #zig
<shakesoda>
fear not, i'm sure it'll have some weird vendor dependent stuff you'll need to care about anyways, because it's vulkan :D
<shakesoda>
"ah yes, make sure you avoid these flags on <VENDOR NAME HERE>, it's much slower"
<shakesoda>
this is of course still better than dealing with the same thing on gl
<Snektron>
I doubt opengl is getting an rtx extension anytime soon anyway
<shakesoda>
it already does
<shakesoda>
GL_NV_ray_tracing
<shakesoda>
dunno if they'll ever update gl core for it, but it'd be a solid reason for a gl 5.0
<shakesoda>
it might have fallen out of favor for new code, but gl very much still exists and will for quite a long time (and khronos knows that)
<pixelherodev>
I woder what version Vulkan will be at when *it* gets replaced :P
<pixelherodev>
wonder*
<shakesoda>
who knows
<shakesoda>
i'll be pretty glad when i can stop shipping gl, though, the amount of nonsense bug reports i get from broken drivers and such is far too much
<shakesoda>
vulkan's kind of a shit replacement though, it's such a hassle
<shakesoda>
but i'm willing to suffer that if i get more reliability/better driver support.
<shakesoda>
i guess
<pixelherodev>
It's really just a matter of getting the three big ones to work together
<pixelherodev>
Mostly NVidia, from what I've heard
<shakesoda>
depends what platform you're on, and if you need to support hardware that isn't current
<pixelherodev>
Find a billionaire, hire hundreds of devs full time to reverse engineer old hardware and write a modern high-quality driver for all of them
<shakesoda>
an unfortunately common problem is pre-skylake intel + windows
<shakesoda>
even when the gl driver for the specific chip is okay, it's pretty common for people to not even have it installed
<shakesoda>
and only have whatever windows gave them, which happily does d3d (only)
<pixelherodev>
That seems more like a Windows problem than an Intel one
<pixelherodev>
Hmm okay
<shakesoda>
windows is indeed the single biggest opengl problem.
<pixelherodev>
So we need to get all three large GPU manufacturers plus both major OS vendors to work together...
<shakesoda>
apple has just outright given everyone the finger but at least metal is a decent api
gruebite has joined #zig
<shakesoda>
i have yet to see how good molten is (i can't: my mac is too old)
riba has quit [Quit: Lost terminal]
<pixelherodev>
Doesn't matter how good the API is if only one vendor supports it
<pixelherodev>
Better to have an average API (neither great nor awful) that has consistent behavior on all hardware
<shakesoda>
well, it matters because at some point i'll have to suffer it
<pixelherodev>
/ os
<Snektron>
> vulkan's kind of a shit replacement though, it's such a hassle
<Snektron>
Eh, once you have the basic hang of it its quite nice
<pixelherodev>
Sure, but you have to suffer it once while writing it
<shakesoda>
Snektron: everything in vulkan is an obscene amount of work.
<pixelherodev>
You don't have to suffer *afterwards*
<shakesoda>
pixelherodev: no, i have to suffer it pretty much eternally
<shakesoda>
pixelherodev: i'm a graphics programmer by day. i deal with this stuff...
<shakesoda>
i haven't had to deal with metal just because their gl still "works"
<pixelherodev>
Right, but I mean that you don't have to find out later that you need to make per-platform tweaks, or that an old tweak is causing issues on a new driver, etc
<shakesoda>
maybe you'd be amazed what kind of horrible stuff goes down :(
<Sahnvour>
from what I get that's the theory...
<Snektron>
I dont have much experience with another decent graphics api, but it seems to me that most of the stuff vulkan requires you to do has a good reason behind it
<Snektron>
I heard dx12 is similar, but i dont know what exactly the differences are
<shakesoda>
Snektron: dx12 and vulkan both have good reasons to be as they are, but in the process they're a tremendous amount of trouble that really didn't need to be punted off onto all the users.
<shakesoda>
Snektron: dx11 was about the right balance, in terms of using it, imo
<BaroqueLarouche>
D3D11 is really good
<shakesoda>
gl is an okay abstraction level but has an insane amount of problems both in the api and in practice
<shakesoda>
so i ship it, but i *hate* it
<Snektron>
Im not sure vulkan was even intended to be used by people as a generic graphics api, it was specifically meant to be low level
<shakesoda>
it shoves even more work onto you than the low level console graphics apis do...
<shakesoda>
i'm really happy about the validation layers and good tool support at least.
riba has joined #zig
Nypsie has quit [Quit: WeeChat 2.8]
<Sahnvour>
multiple packages can be chained in zig cli via consecutive --pkg-begin/end pairs, correct ? I can't get the second one to be found when compiling
Snektron has quit [Ping timeout: 244 seconds]
<andrewrk>
yes
Snektron has joined #zig
hspak has joined #zig
riba has quit [Ping timeout: 256 seconds]
<pixelherodev>
Sahnvour: With transitive dependencies, you want `--pkg-begin name path --pkg-begin dep path --pkg-end --pkg-end`
<Sahnvour>
ooh right, thanks pixelherodev
<pixelherodev>
:)
<pixelherodev>
I'm just your friendly neighbourhood Zig assistant
<pixelherodev>
'tis what I do
<fengb>
phd, play despacito
<pixelherodev>
Sorry, that would be unfriendly of me
<pixelherodev>
I cannot violate my personal ethics
<Sahnvour>
too much zig has been evicted from my memory caches :)
<pixelherodev>
Why is #141 (bound methods) still open?
ur5us has joined #zig
mikdusan has joined #zig
dch has joined #zig
xackus_ has quit [Ping timeout: 240 seconds]
FireFox317 has joined #zig
<FireFox317>
Hey guys, what would be the appropriate place on IRC to ask some help with booting linux on an embedded device?
<pixelherodev>
... #distro?
<FireFox317>
pixelherodev, its not an linux distro tho, just an embedded devices with an buildroot initramfs
<pixelherodev>
Ahh
<pixelherodev>
... #linux?
<pixelherodev>
Does that exist?
<FireFox317>
yeah it does, but i dont want to bother linux developers with questions regarding setting up a system
<FireFox317>
might ask in there what would be the appropriate place
<pixelherodev>
##linux exists, not #linux
<FireFox317>
I see, 1763 ppl lol
<pixelherodev>
`##Linux is freenode’s general Linux^® support channel. We provide help and support for any Linux^® distribution and aim to answer any questions...`
<FireFox317>
I see, lets try it (no harm in that :P)