<pixelherodev>
Yeah, absolute 64-bit jump is FF /4
<mq32>
(the whole site, it's awesome docs on x86)
<pixelherodev>
To use a register, the second byte should be 0b11100RRR
<pixelherodev>
Where RRR is the register's ID
<pixelherodev>
For an extended register (e.g. r8), it'd be 0x41 0xFF 0b11100RRR, where RRR is the lower three bits of the id
<pixelherodev>
Uh hm
<pixelherodev>
Need to implement memory and such now :P
<pixelherodev>
Holy craps
<pixelherodev>
zls just munched up my entire RAM!
<pixelherodev>
:(
_Vi has quit [Ping timeout: 240 seconds]
<ifreund>
i think there have been a couple bugs like that fixed already
<ifreund>
infinite loops in the parser if theres an errror or somethjing
<pixelherodev>
... I'mma update just in case
<mq32>
Outstream.print() is not made for long messages :D
<mq32>
i just hit eval branch quota
<blueberrypie>
what is the quota?
<pixelherodev>
1000 by default IIRC?
<pixelherodev>
You can change it
<pixelherodev>
@setEvalBranchQuota
<pixelherodev>
Hmm, does ZLS mention errors with broken ASTs?
foobles has joined #zig
<tdeo>
it should
* pixelherodev
shrugs
<pixelherodev>
Not important right now
<mq32>
afaik ZLS only refreshes analysis when the tree can be parsed
<pixelherodev>
andrewrk: should genSetReg support all sized registers?
<pixelherodev>
8-bit, 16-bit, etc; when the operand fits?
nephele_ has joined #zig
nephele has quit [Ping timeout: 260 seconds]
nephele_ is now known as nephele
<pixelherodev>
Doesn't seem to update with a partial AST after the partial AST patch :P
<pixelherodev>
Actually, I take that back
<pixelherodev>
My AST was apparently *really* obnoxiously bad :P
ifreund has quit [Ping timeout: 258 seconds]
marijnfs has joined #zig
<pixelherodev>
Alrighty, almost done...
<pixelherodev>
Just need loading from regs and loading from memory, then pass tests...
<pixelherodev>
Yeah it definitely works
<pixelherodev>
AST was just *really* awful :P
<pixelherodev>
I'm even going to implement *more* than is currently there while I'm at it :)
marijnfs_ has quit [Ping timeout: 260 seconds]
<foobles>
andrewrk sorry to bother you, but any idea off the top of your head of what could cause an assertion error at compile time, when using ir_create_basic_block_gen, and then appending it to ira->new_irb.exec.basic_block_list?
<andrewrk>
mq32, pixelherodev: if we use a trampoline, then we need a call to a hard coded address
<mq32>
yeah, that would require something like the offset table atm
<andrewrk>
if we use an offset table then we need a call to an address that is stored in compile-time known memory addr
<mq32>
but that table would consist of a whole lot of jmp-instructions where we just patch the offset in the jmp instead of some integer value
<andrewrk>
that's what I mean about a trampoline
<andrewrk>
foobles, can I see the full error message?
<andrewrk>
also no need to feel like you are bothering me, as long as you understand that I may not always respond! it's ok to try to ping me
<mq32>
what's the difference to the indirect call via a offset table? We still need to know the hardcoded address of the offset table, right?
<andrewrk>
currently, the hard coded address of the offset table is known by the compiler
<andrewrk>
and the index of each decl within the offset table is also known by the compiler
<andrewrk>
so the vaddr of the offset table entry is known as a numerical value
<andrewrk>
we can make the offset table be whatever we want it to be
<andrewrk>
the simplest thing would be if there was a call instruction like this: `call [got_addr]`
<foobles>
Ah sorry, i got caught up in something. All it says is "assertion failed" :/
<foobles>
do i need to compile LLVM again in debug and then do a debug build?
<foobles>
assertion failed. This is a bug in the Zig compiler.Unable to dump stack trace: debug info stripped
<andrewrk>
foobles, once we get past stage1 and onto self-hosted as the main compiler, this should get better, but for now - do you have access to a posix environment? linux perhaps? it's easier to set up release llvm + debug zig there
<andrewrk>
maybe even wsl? I hear some people have that working
<mq32>
andrewrk: there's an instruction "call [got_addr_rel]"
<mq32>
where the address is relative to the position after the call instruction
<foobles>
i will try wsl, unfortunately I don't have linux
<mq32>
ah wait, got means "global offset table", right? :D
<andrewrk>
ya
<mq32>
andrewrk
<mq32>
i found it
<mq32>
48 FF 25
<mq32>
jmp [addr]
<andrewrk>
ok, so then we would have a separate section ".got.plt" for functions, each entry would be `call addr`, and then function calls would be `jmp [got_plt_addr]`
<mq32>
quick question: i compiled my project with x86_64-linux-musl
<mq32>
what could be the reason that my file is not executable?
<andrewrk>
what, it's missing the +x bit?
<mq32>
nope, xbit is set, file exists, "file" stats that it's a ELF64 … file
<mq32>
but using /lib/ld-musl-x86_64.so.1 as a dynamic linker?
<andrewrk>
foobles, the alternative is to have an additional build of llvm,clang,lld built in debug mode. the wiki has instructions for setting this up
<andrewrk>
this is really slow and I don't recommend doing normal development this way
<foobles>
oh alright thanks
<andrewrk>
but if you need debuggability you can do this to get introspection into a crash
<andrewrk>
and it's worth it even though it's annoying
<foobles>
ill try that, i dont really know how to use linux even if i do get wsl >_>
<foobles>
thanks, thats a good lead
<andrewrk>
I do it occasionally on windows when debugging the compiler
<andrewrk>
mq32, currently zig assumes musl implies static linking
<andrewrk>
I'm not sure how you could have used zig to build an executable that dynamically links musl
<mq32>
yeah that was my plan anyways :D
<tdeo>
well, there are a few linux distros that use dynamically linked musl
<andrewrk>
yes but zig does not integrate with them - it builds its own musl source files from source
<foobles>
by the way, when did the "performance or safety. choose two" slogan come about? because that is very similar to Bazel's "{fast, correct} choose two"
<mq32>
my default is .arch_os_abi = "native-native-gnu.2.25..2.25"
<mq32>
but it looks like musl has this as well?
<mq32>
because i need getentropy
<tdeo>
"good/cheap/fast, choose two" is the phrase it comes from i believe
<mq32>
oh…
<mq32>
wait
<mq32>
i link a C library that was built against system libc, but: static link ,it's an archive (.a) file
<andrewrk>
foobles, idk, I just wrote that along with the rest of the home page content one day. it's intentionally slightly provocative
<daurnimator>
mq32: does musl guarantee ABI compat across versions?
<daurnimator>
(I was going to ask you that in #musl to provoke a conversation but you're not in there)
<mq32>
daurnimator: not sure, i just do the thing now i wanted to do anyways:
<mq32>
build BearSSL with zig!
<tdeo>
well musl went through a bunch of effort to keep abi for 64 bit time_t
<mq32>
i get a bug report that gurl does not compile on freebsd atm
<mq32>
<styan> xq: It did not compile on FreeBSD 13-CURRENT "InvalidAbiVersion"
<foobles>
heck yeah
<foobles>
i accidentally compiled llvm in debug a long time ago
<foobles>
and just left it there in case
<foobles>
well, the case has come B)
slice has quit [Quit: zzz]
stripedpajamas has joined #zig
stripedpajamas has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dddddd has quit [Ping timeout: 256 seconds]
_whitelogger has joined #zig
slice has joined #zig
stripedpajamas has joined #zig
foobles has quit [Remote host closed the connection]
aerona has quit [Quit: Leaving]
foobles has joined #zig
<foobles>
eigh, im trying to build zig in debug. linking is working fine -- it's just giving me erros about how /O2 and /RTC1 are incompatible options :/
<pixelherodev>
Alrighty, going to finish this tonight.
<pixelherodev>
So close to done...
<pixelherodev>
Going to fully implement genSetReg for x64 (*no* TODOs) then PR
<pixelherodev>
Mostly done, just need loads from registers and a single branch in loading from memory
<foobles>
anyone have similar issues with building on windows?
<foobles>
building release seems fine
metaleap has joined #zig
<foobles>
what i am doing for invoking cmake is just taking the recommended `cmake .. -Thost=x64 -G "Visual Studio 16 2019" -A x64 -DCMAKE_PREFIX_PATH=[...]\llvm+clang+lld-10.0.0-x86_64-windows-msvc-release-mt -DCMAKE_BUILD_TYPE=Release`
<foobles>
but replacing -DCMAKE_BUILD_TYPE=Debug, and also changing it to llvm+clang+lld-10.0.0-x86_64-windows-msvs-debug
stripedpajamas has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<pixelherodev>
andrewrk: test passes!
<pixelherodev>
Just adding in a bit more (removing some of the TODOs) then sending your way :)
_whitelogger has joined #zig
<pixelherodev>
andrewrk: should invalid operations trigger self.fail or unreachable?
<pixelherodev>
Given that codegen should never produce them, I'm leaning towards unreachable
metaleap has quit [Quit: Leaving]
cole-h has quit [Quit: Goodbye]
<pixelherodev>
Every form of genSetReg for x64 is now implemented :)
<pixelherodev>
Not confirmed to be working though, as they're untested AFAIK
<pixelherodev>
Final tally: 10 lines shorter than previous state, and implements *every single form of move* :)
<pixelherodev>
andrewrk: #5363 opened
antaoiseach has quit [Quit: leaving]
foobles has quit [Ping timeout: 245 seconds]
slice has quit [Quit: zzz]
slowtype1 has joined #zig
slowtyper has quit [Ping timeout: 272 seconds]
<pixelherodev>
Two PRs in one night :)
<pixelherodev>
daurnimator: just to confirm, what exactly was the question on the x86 (NOT x64) registers?
r4pr0n has joined #zig
<daurnimator>
pixelherodev: which question?
<daurnimator>
pixelherodev: I think you're missing BPL, SIL, DIL, SPL?
<pixelherodev>
Ahh
<pixelherodev>
daurnimator: those don't exist?
<pixelherodev>
s/?/
<pixelherodev>
there's no such thing :)
<pixelherodev>
Ah wait
<pixelherodev>
The *L* ones exist, yeah, the *H* ones don't
<pixelherodev>
There was a conversation about this earlier
<pixelherodev>
tl;dr: it's impossible to use those four registers in a manner consistent with the others
<pixelherodev>
They require an empty REX prefix in order to use
<pixelherodev>
They also don't exist in x86 mode, which is why I was confused by the question
<pixelherodev>
You asked about al, bl, cl, and dl on the x86.zig file
<daurnimator>
pixelherodev: that was just me being blind
<daurnimator>
pixelherodev: though many of your @intCast should be @as
<pixelherodev>
daurnimator: I fixed that one already :)
<pixelherodev>
It's one bit if reg is extend, a different bit if src_reg is extended
<ifreund>
this is for std.log, so the idea is that each library would pass an enum literal which the user would then add a tag for in their LogScope enum
<daurnimator>
ohh
<pixelherodev>
Since they're two different registers, the fourth bit of each goes to a different part of REX
<pixelherodev>
:)
<daurnimator>
otherwise I was considering if `@boolToInt` would be useful in a few places
<ifreund>
i prefer doing it with an enum over strings as it makes filtering easier as you can use a switch
<pixelherodev>
ifreund: so the idea is, effectively, an enum with field generated at usage spots?
<ifreund>
yeah
<pixelherodev>
Maybe take in the enum as the first param?
<ifreund>
ok, doing @TypeOf(.dummy) works, but i'd prefer an actual keyword
<daurnimator>
hehe; looks like I linked the same as haze
<pixelherodev>
Yep
<daurnimator>
brb dinner
<pixelherodev>
:)
<pixelherodev>
If I go missing for a few hours, i fell asleep :P
<pixelherodev>
Yay, checks passed again :)
<pixelherodev>
Looks like the GCC 5 fix should also have checks passing again
<pixelherodev>
Quick note regarding it: it builds but doesn't link for me, as it's linking against LLVM which is built with GCC 9
<pixelherodev>
Time to look through the list of contributor-friendly issues...
<pixelherodev>
Maybe I'll tackle #5008...
<pixelherodev>
Ah never mind
<pixelherodev>
Can someone with permissions close #5008?
<pixelherodev>
A fix was merged today in #5032 :)
slowtype1 is now known as slowtyper
traviss has quit [Quit: Leaving]
<pixelherodev>
Three PRs in one night :D
<pixelherodev>
Surprisingly productive
<ifreund>
nicely done
<pixelherodev>
Yep :)
<pixelherodev>
Might get to work on self-hosted detection of ARM CPUs next
<pixelherodev>
That's a larger one, but it'll come in handy once I end up getting a PineBook (which I plan on ordering within the next week or two if they're still in stock)
slurpie has quit [Ping timeout: 256 seconds]
<ifreund>
I'm eying one too for when my current laptop dies
<ifreund>
i barely use a laptop though at the moment
<alexnask>
Hmm Im writing a better debug allocator for zls and then I will try porting the zir stuff for PE executables
<alexnask>
Although Im pretty clueless, should be fun
dddddd has joined #zig
nycex has quit [Remote host closed the connection]
nycex has joined #zig
<pixelherodev>
#4106 and #5008 can both be closed
<pixelherodev>
They've been solved already :)
<pixelherodev>
Similarly, #4205 is no longer applicable, since std.Buffer is gone
<pixelherodev>
Rather, it should be applied to Fifo?
<pixelherodev>
No, doesn't apply there
<pixelherodev>
Ahh, array_list_sentineled
<pixelherodev>
Okay, #4205 can be closed also
greenfork has joined #zig
<ifreund>
pixelherodev: probably best to just comment on the issues so it doesn't get lost here
<pixelherodev>
good call
<ifreund>
are "module level" doc comments a thing? like one comment at the top of the file giving a general overview and maybe an example?
<alexnask>
I don't think so, pretty sure doc comments must be attached to declarations
<greenfork>
hello, I hope it's appropriate to post some questions here. I'm trying to write a simple game of tic-tac-toe in terminal and I have this strange bug that error messages appear twice, here is a pastebin link https://pastebin.com/visphcRf . Do I do something wrong?
<alexnask>
Is the Bi specifier supposed to work for floating point types? I'm getting an error using it but not sure if it is a bug or not
<alexnask>
This is gonna be super useful since I'm using files-as-structs a lot now
<ifreund>
same
<ifreund>
i love not having my funtions intented
<ifreund>
*indented
<alexnask>
Yes, 1 less indent level is bae
<alexnask>
Also const MyType = @import("my_type.zig") instead of @import("my_type.zig").MyType;
<ifreund>
i really suck at spelling, maybe i need to figure out how to get a spellchecker in weechat
<ifreund>
yeah the imports are way cleaner too
<alexnask>
greenfork, readIntNative(u8) will read one byte
<alexnask>
So in this example, it will read 'a' in the first loop, error then the stream still has the '\n' char so it will also read '\n' and error
<greenfork>
alexnask, I see, thank you!
<alexnask>
You probably want to do something like readUntilDelimiterOrEof or one of the readUntilDelimiter variants with a '\n' delimiter and then parse the line yourself
r4pr0n has quit [Ping timeout: 240 seconds]
<alexnask>
You probably want to do something like readUntilDelimiterOrEof or one of the readUntilDelimiter variants with a '\n' delimiter and then parse the line yourself
<alexnask>
woops
<alexnask>
woops
<alexnask>
omg >.>
* pixelherodev
grins
<pixelherodev>
I've accidentally sent "/buffer" messages three times in the last few days :P
<pixelherodev>
glad to see I'm not the only one :)
xackus has joined #zig
<pixelherodev>
There we go :)
<pixelherodev>
Is there a way to say "pointer to any type of function"?
<pixelherodev>
I want to store a function pointer to an arbitrary (user-provided) function type, and use type reflection to pass it arguments in a JIT
<pixelherodev>
I'm thinking I might just restrict calls though, as that seems much simpler
<alexnask>
You would have to store a type erased ptr and some runtime representation of the TypeInfo
<pixelherodev>
That's what I figured, thanks
<pixelherodev>
One alternative might be to pass the function call straight to the native JIT or something
<pixelherodev>
Maybe use it as a graph edge for register allocation
<alexnask>
ifreund, I think it would be clearer to define EnumLiteral = @Type(.EnumLiteral) in std.meta or something instead of repeating it everywhere
mmx870 has joined #zig
<alexnask>
Minor nitpcik though, I like the idea of using it this way
<ifreund>
hmm, yeah I don't think it reall justifies having it's own keyword, maybe std.meta is the right place for it
<ifreund>
or maybe std.builtin? idk
<ifreund>
honestly @Type(.EnumLiteral) is pretty clear
<alexnask>
I can live with it I guess ^_^
<pixelherodev>
Hmm
<pixelherodev>
"Have to ststore type erased ptr + TypeInfO"
<scientes>
we need a better hex dump
<scientes>
{x} is lame
<pixelherodev>
I can literally use the type info from @TypeOf, right?
<pixelherodev>
:)
<pixelherodev>
scientes: `0x{x:0<W}` where W is bytes to pad?
<pixelherodev>
e.g. `0x{x:0<2}` for 8-bit values
<pixelherodev>
s/bytes/nibbles
<scientes>
I want something like hd produces
<pixelherodev>
hd?
<scientes>
in the shell
<scientes>
echo "foo" | hd
<alexnask>
pixelherodev, TypeInfo is a comptime only type
<alexnask>
Since it stores comptime_ints and types
<scientes>
all types are comptime only
<alexnask>
And vars
<alexnask>
Yes all types are comptime-only, Im not talking about TypeInfo as a type but about TypeInfo values obviously
<alexnask>
all types are comptime-only values*
<scientes>
and how do I dump an array?
<scientes>
I seriously don't know how to use fmt
<pixelherodev>
Plain {} might be useful
<alexnask>
^
<pixelherodev>
alexnask: disappointing, but unsurprising :(
<alexnask>
You can use most types out of the box with fmt
<pixelherodev>
I mean, the info *is* comptime-known
<scientes>
pixelherodev, but i have to list ever array element
<scientes>
and i want it to just enumerate them
<pixelherodev>
`fmt("{}", .{ array })` might work
<pixelherodev>
problem is, info is comptime known but I don't want to use it until later :(
<alexnask>
It does work but prints them without separators I believe
<scientes>
but i get that that wouldn't be supported
<scientes>
in Go you can write your own print() function
<alexnask>
pixelherodev, You should be able to make some comptime hashmap that gets updated to hold the typinfo
<alexnask>
scientes, You an write your own format method but the default format does handle structs
<alexnask>
Slices do print the address though, yeah, this is annoying
<pixelherodev>
alexnask: figured out a better solution :D
<pixelherodev>
Instead of storing the function as is, it breaks it down into pieces
<pixelherodev>
various LoadArgument instructions, the Call, then some instructions to deal with the outputs
<pixelherodev>
e.g. Clobber, Alias, etc
<alexnask>
You still need to hold the type of the arguments in some data structure though right?
<pixelherodev>
Not really
<pixelherodev>
Well
<alexnask>
Ah, I guess you only need size info
<pixelherodev>
Yes, but it doesn't really matter nearly as much
<pixelherodev>
It's a matter of storing minor type info for e.g. integers
<pixelherodev>
and not *functions*
<alexnask>
Right
<pixelherodev>
it's much much simpler
<alexnask>
Just for the ABI stuff
<pixelherodev>
Nah, don't even have to worry about that lol
<pixelherodev>
That's at a lower level :)
<pixelherodev>
This is a high-level abstraction ISA
<pixelherodev>
It then gets translated to e.g. amd64 at runtime
<alexnask>
Gotcha :)
<alexnask>
If you havent recompiled zls master in the last 19 hours or so you should, local variable completions work now thanks to aurame :D
FireFox317 has joined #zig
hermier has left #zig [#zig]
<ifreund>
nice! time to recompile :D
<ifreund>
y'all are moving super fast on zls
<alexnask>
I owuld recommend recompiling a couple of times a day :P
<scientes>
switch to gentoo ;)
<scientes>
and spend endless hours watching compiles scroll
<scientes>
and think you are learning something
<nephele>
I'm sure it will be the fastest installl after it is done wasting my time :)
<greenfork>
scientes, very true about gentoo :)
<scientes>
what a stupid idea
<ifreund>
alexnask: would a PR adding xdg base directory support for loading the config be welcome?
<alexnask>
Sure thing
<alexnask>
It should prob fallback to the self exe directory for now though
<alexnask>
eventually we will look for build.zig and for the config in that folder
<ifreund>
ah yeah, that probably wouldn't be hard
<ifreund>
traverse up till you find build.zig and look there, i guess I'll try that instead
hermier has joined #zig
<alexnask>
ifreund, This will probably be a little more involved since it would have to be file specific but knock yourself out :) The home directory is fine too, whatever you prefer is good ;)
dimenus has joined #zig
<ifreund>
indeed, i just pulled up the code and realized that it wouldn't be quite as straightforward :D
<alexnask>
daurnimator, languageId: "zig", syntaxes pointing to the zig extension's tmLanguage seems to be what sublimelsp wants
<alexnask>
Let me give it a shot, I have sublime text installed
* daurnimator
is reading through zls code.... some things are named... oddly. e.g. `checkSanity` actually mutates
layneson has joined #zig
layneson has quit [Client Quit]
<pmwhite>
Is zls use using compiler libraries for autocomplete and stuff? Or is it home made?
dimenus has quit [Quit: WeeChat 2.8]
<alexnask>
daurnimator, Yes it used to do a lot different
layneson has joined #zig
<alexnask>
daurnimator, Shopuld have been renamed :P
<alexnask>
something a lot different*
* daurnimator
will send a PR with a few cleanups...
<daurnimator>
fun to see all the json types declared!
<alexnask>
I get errors just installing the zig language package >.>
* daurnimator
is coming around to the idea of an un-mutated `var` should be an error
<alexnask>
Yes it would be nice. There is quite a bit of this going on, I tried to fix it where I spotted it
layneson has quit [Quit: WeeChat 2.8]
layneson has joined #zig
layneson has quit [Quit: WeeChat 2.8]
layneson has joined #zig
layneson has quit [Client Quit]
layneson has joined #zig
knebulae has quit [Read error: Connection reset by peer]
waleee-cl has joined #zig
knebulae has joined #zig
layneson has quit [Quit: WeeChat 2.8]
layneson has joined #zig
layneson has quit [Client Quit]
layneson has joined #zig
aerona has joined #zig
dingenskirchen has quit [Ping timeout: 244 seconds]
dingenskirchen has joined #zig
<pixelherodev>
Neat, ZLS update :)
cole-h has joined #zig
<pixelherodev>
Just need to implement live range register allocation and the Thor Hello, World is done for amd64 :D
Akuli has joined #zig
<alexnask>
Nice!
wozeparrot has joined #zig
<xackus>
in stage1 some functions returning ZigType* return nullptr and some an invalid type when they fail
<xackus>
which one should i choose for a new function?
<andrewrk>
xackus, if it returns a ZigType* then the calling code already will have to check for an invalid type, so it would be simpler to not additionally introduce the possibility of nullptr
<xackus>
yeah, i just checked and type_is_invalid doesn't check for null
Akuli has quit [Quit: Leaving]
<xackus>
i am trying to prevent the creation of illegal error union types, but the functions used for creating types don't have access to an AstNode
<xackus>
needed to add an error
<xackus>
hm, get_opaque_type has an AstNode* parameter
<alexnask>
It uses it to get the line number it appears in
<dimenus>
oats: I get the same crash no on x86_64 & aarch64 as well
<dimenus>
maybe an issue with that particular invocation
Bastian[m] has joined #zig
Bastian[m] has left #zig [#zig]
Bastian[m] has joined #zig
Bastian[m] has quit [Quit: issued !quit command]
kristoff_it has joined #zig
Bastian[m] has joined #zig
Bastian[m] is now known as Bastian[m]
<dimenus>
oats: anything other than debug build with symbols crashes for me on all 3 emulators (x86_64, aarch64 and risc-v)
<mikdusan>
dimenus: for x86_64, build with `-mcpu=baseline` and seems to work
<mq32>
Merged #5307 into master. \o/
<alexnask>
🎉
oats is now known as qoats
qoats is now known as oats
<mq32>
🎉🎉🎉
puzzleddev has quit [Quit: Leaving]
<andrewrk>
if anyone is looking to contribute on this, I think it might be at a point where there are some non-conflicting areas to work on simultaneously
dermetfan has joined #zig
<andrewrk>
might be worth it to coordinate a little bit first tho
r4pr0n has quit [Quit: r4pr0n]
<andrewrk>
also I think it's time for me to go set up the performance tracking / resource usage tracking repo now
cole-h_ has joined #zig
cole-h_ has quit [Client Quit]
dermetfan has quit [Ping timeout: 240 seconds]
constptr has joined #zig
constptr is now known as egemutu
egemutu is now known as varsbhat
<dimenus>
mikdusan: with `release-small` or `release-fast` still crashes over here
mokafolio has quit [Quit: Bye Bye!]
<dimenus>
hmmmm, the hello world example with zig build generates SIGILL when run with qemu
varsbhat has quit []
<mikdusan>
yeah I probably just got lucky with --release-safe, x86_64 and -mcpu-baseline . the -fast and -small still segfault for me
<mikdusan>
qemu 5.0.0
greenfork has quit [Ping timeout: 272 seconds]
dimenus has quit [Quit: WeeChat 2.8]
<mq32>
short question: how do i resolve ~ in paths? Look up $HOME and replace it with that?
qoats has joined #zig
<andrewrk>
in what context?
<mq32>
i want to resolve a path like ~/.local/
mokafolio has joined #zig
<mq32>
want to use the defaults for .config / XDG_CONFIG_HOME
<mikdusan>
if you do that, it's usually called "expanding path" in my exp. And it should only work if the path[0] == '~'
<mq32>
oh wait. ~ is expanded by my shell :D
<mq32>
so that should not be a problem
<ifreund>
was about to say, ~ should probably be handled by the shell
qoats has quit [Remote host closed the connection]
qoats has joined #zig
cole-h_ has joined #zig
<mq32>
hm, still the question: how do i get the home directory of the user? is there already a function for thaT?
<lunamn>
os.getenv("HOME")?
<mq32>
that does not work on windows i suppose?
<ifreund>
yeah probably not
<mq32>
std.fs.getAppDataDir() is something…
<lunamn>
oh, just saw the other messages. yeah, $HOME is what I'd do, it wouldn't work on windows
<andrewrk>
mq32, there is a cross platform way to get the concept of a home directory
<mq32>
mikdusan: what if we just use arena allocators? 😱
Akuli has quit [Quit: Leaving]
<GreaseMonkey>
TLB shootdowns, not to be confused with TLB shutdowns on MIPS which are absolutely horrible
<GreaseMonkey>
if it happens, typically the only option you have is to reset
<mikdusan>
VM 1.0 GiB per job building llvm with gcc 9 or higher not enough -> "c++: fatal error: Killed signal terminated program cc1plus"; when am I going to learn my lesson. 1.5 GiB per job
<mq32>
GreaseMonkey: i have a similar thing in my arch
<andrewrk>
I thought you needed 4
<mq32>
you can un-memory-map the memory-mapping-tabe
<mq32>
*table
<mq32>
→ you can lock yourself into not being able to change anything in the paging setup
<GreaseMonkey>
ouch
<mq32>
i just noticed…
<mq32>
that's actually damn great :D
<GreaseMonkey>
does your arch not expose physical memory
<mq32>
nope
<mq32>
you can implement "sand boxing" with that
<mq32>
as RAM is persistent across soft-system-resets
<GreaseMonkey>
neat
<mq32>
just reset the CPU and you'll be back to the OS
<mq32>
GreaseMonkey: i need the MMU because system bus width is 24 bit, but cpu width is 16 bit
<GreaseMonkey>
fair enough
_Vi has quit [Ping timeout: 240 seconds]
hamoko[m] has joined #zig
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
slice has quit [Quit: zzz]
jhamren has joined #zig
<mikdusan>
yaay... zig seems to boostrap with gcc-10.1.0 just fine
<mq32>
neat!
layneson has quit [Ping timeout: 240 seconds]
stripedpajamas has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dermetfan has quit [Ping timeout: 260 seconds]
layneson has joined #zig
ur5us has joined #zig
<mq32>
andrewrk: you successfully made me planning to send a request to the BearSSL team
<mq32>
the ubsan hit!
<andrewrk>
oh wow that's actually an accomplishment right?
alexnask has quit [Quit: Leaving]
<pixelherodev>
andrewrk: did you end up getting to work on implementing function calls?
<mq32>
well, it prevents me from debugging that code path with any safe mode, but i'll send a mail to Thomas Pornin to notify him of the UBsan hit :)
<mq32>
so hopefully zig makes SSL libraries more safe
<andrewrk>
pixelherodev, that's next on my list. today I switched over to working on a new project to track various zig performance benchmarks over time
<pixelherodev>
Oh neat :)
xackus has quit [Ping timeout: 256 seconds]
<pixelherodev>
andrewrk: regarding "implement local variables," are they implemented in the ZIR format but not the incremental compiler?
<pixelherodev>
Looking for a next task :)
<andrewrk>
pixelherodev, how about math operations? local variables is actually going to require some chin scratching I think
<andrewrk>
by chin scratching I mean like, maybe needing to change the semantics of the language
<andrewrk>
we actually don't have a way to get a runtime value yet in ZIR without inline assembly, hah. so what that might look like is implementing more inline assembly parsing and using that to make a runtime known value, then do math ops on it
<andrewrk>
otherwise that would be blocking on functions, globals, or local variables
<pixelherodev>
It'll need reworking at that point anywyas though, so I might as well wait
<pixelherodev>
Hmm, maybe removing dead decls?
<pixelherodev>
Oh, i know
<pixelherodev>
Self-hosted ARM feature detection
<andrewrk>
ooh that would be excellent
<pixelherodev>
It'll be useful, and thanks to Thalheim I can actually test it on real hardware :)
<andrewrk>
I'll try to get these other components to be contributor friendly ASAP
<pixelherodev>
Plus, it familiarizes me with ARM
<pixelherodev>
Which I'm going to need to extend Thor soon (since the hello world is finally just about done for x64 :D)
<pixelherodev>
Soon, I'll have a single API for a JIT that generates both AMD64 and ARM64 code :D
<andrewrk>
neat
<pixelherodev>
I think working on the self-hosted codegen while I do this has been really useful
<pixelherodev>
Helps me find places where one does something better than the other, and then improve them both
<andrewrk>
:D
slice has joined #zig
<andrewrk>
I think this is what it feels like when you start to acquire expertise in a particular domain
<pixelherodev>
Anyways, heading AFI (away from internet) because my desk is too far away from WiFi :P
<pixelherodev>
I'll probably have something done when I get back :)
<pixelherodev>
oh my how did I never see #666 before
* pixelherodev
bursts into laughter
<Thalheim>
that's from Christmas Evil
<pixelherodev>
One quick note regarding emitting DWARF info before I head off
<pixelherodev>
I think daurnimator mentioned that std.debug largely needs to be rewritten, so it's probably best to have that done first
<andrewrk>
I don't think std.debug is relevant to self-hosted emitting dwarf
<pixelherodev>
I mean, the DWARF types are already in std.debug, should we not use those?
<pixelherodev>
I can definitely see certain, uh, other applications using DWARF emitting if it's in stdlib :)
<andrewrk>
the dwarf_bits.zig file will be relevant
<andrewrk>
emitting dwarf is going to be tricky, it also needs to participate in incremental updates
<pixelherodev>
Oof, which means the emitted info needs to be tracked as well
<pixelherodev>
So that we can update and remove references...
<andrewrk>
with potentially some weird tricks like having line numbers computed as offsets from previous decls, so that only 1 pwrite() is needed when , for example, a blank line is inserted in the middle of a file
<pixelherodev>
Sounds fun :)
<andrewrk>
I'm pretty sure no one has ever done this
<andrewrk>
then we get to solve the problem all over again with microsoft's undocumented PDB format!
slice has quit [Quit: zzz]
AlecTaylor has joined #zig
<AlecTaylor>
hi
<andrewrk>
hi AlecTaylor
<AlecTaylor>
I read that Zig can be used as a run-of-the-mill C compiler… should I expect anything interesting here, e.g., more optimisations, smaller executable size, fast compile times?
<andrewrk>
yes you should expect different defaults for a few important things
<andrewrk>
(1) without optimization flags, it defaults to debug mode, which enables undefined-behavior sanitizer
slice has joined #zig
<andrewrk>
(2) there is a cache system
<andrewrk>
(3) it will use LLD as a linker, not the system linker
<andrewrk>
(4) it will default to the native target, taking advantage of your host CPU features
slowtyper has quit [Ping timeout: 265 seconds]
slowtyper has joined #zig
layneson has quit [Ping timeout: 260 seconds]
<AlecTaylor>
Thanks andrewrk
<AlecTaylor>
I've been building a bunch of tiny C89 projects, and am about to cross-compile and cross-package their output, with as many different compile flags as I can think of