<pixelherodev>
I can do the implementation if you finished the design ;)
<andrewrk>
are you trying to work on exactly the same thing as me again? :P
<pixelherodev>
except now you said you're not working on it ;)
<andrewrk>
I am now actually
<pixelherodev>
oh huh
<pixelherodev>
good
<pixelherodev>
CBE it is
<pixelherodev>
stupid net split
<pixelherodev>
messing with my logs
<pixelherodev>
ah okay
<pixelherodev>
andrewrk: so I should probably add a CFile next to ELFFile and use that instead?
<pixelherodev>
should there be an Allocator-like interface that goes to both?
<andrewrk>
use your best judgement and let's see what you come up with
<OmegaDoug40>
Hi, does using a c-library require installing a c compiler? Does cross-compiling still work if using c-libraries?
<andrewrk>
OmegaDoug40, the beauty of how it works with zig is that it can cross compile c libraries too. but you have to mess with the build system of the C library to make that work. it will be part of the role of a package manager to help make this easier
<OmegaDoug40>
andrewrk Messing with the c libraries build system sounds like it isn't a "hello world" kind of change for someone who doesn't program in c
<andrewrk>
that's correct
<andrewrk>
in the future the idea is that it will be as easy as adding a package dependency to your build file
<andrewrk>
but we're not quite there yet
<OmegaDoug40>
That's a good goal. Once you achieve that you'll have a fantastically unique feature.
<pixelherodev>
I mean, we could probably add basic e.g. Makefile support straight to the ZBS
<OmegaDoug40>
Are there any docs for how to use c libs?
<pixelherodev>
That might be a nice break from stage2 after CBE
<pixelherodev>
OmegaDoug40: mostly just reading the source, unfortunately
<pixelherodev>
Well
<pixelherodev>
That's true for most docs with the build system
forgot-p1ssword has quit [Ping timeout: 246 seconds]
<stripedpajamas>
will watch! thanks
<stripedpajamas>
god the video still shot has my exact trace :o
<andrewrk>
haha
<andrewrk>
ugh, redis labs still kept those videos unlisted. I'm going to mirror them now
<lemmi>
andrewrk: will do
<andrewrk>
lemmi, note that if your ensureCapacity is correct, you should be able to use putAssumeCapacity() rather than `try put()`
dimenus has quit [Quit: WeeChat 2.8]
dimenus has joined #zig
<dimenus>
don't look now but JAI is taking 5 seconds to compile a program
<daurnimator>
dimenus: is that good or bad? is it a big program?
<dimenus>
daurnimator: it's more of a joke than anything. He wants everything to compile on the order of 100s of ms
<dimenus>
iirc it's about 100k loc
<dimenus>
Jon is a great programmer but JAI has a lot of complexity compared to zig for example
<dimenus>
life is full of tradeoffs...
<andrewrk>
dimenus, this is with his x64 backend, not llvm?
<dimenus>
i didn't happen to notice what backend it was, the 5s was just the frontend time
<dimenus>
probably debug build
<dimenus>
of the compiler
<andrewrk>
ah ok, so just a joke, not a real data point
<dimenus>
indeed, i'd like to see JAI succeed as well tbh
<andrewrk>
I'm... not sure I can say the same, given that it is proprietary software, with no clear intention of making it open source
<andrewrk>
tbh I'm a little bit put off by blow's attitude toward the open source community in general
<shakesoda>
all i really want is for compiles to be either fast or not needed
<andrewrk>
now that is something I can get behind
<shakesoda>
i have made a lot of engineering choices to this end
<shakesoda>
if jai happens to give us some good ideas to this ends and others in the name of things going faster, great
<dimenus>
andrewrk: does it need to be opensource?
<daurnimator>
shakesoda: what if they have great ideas but the implementation is hidden?
<shakesoda>
daurnimator: usually the implementation itself isn't what i'm interested in
<shakesoda>
daurnimator: more like thoughts i would not have otherwise had - automatic aos-soa transforms are something i don't think i'd have ever thought about if jai didn't bring it up
<andrewrk>
dimenus, I certainly believe so, but I'm not prepared to make a well thought out case at the moment. maybe I can put some effort into that another time
<shakesoda>
just as an example of the kind of idea i mean, just paths i don't think i'd have arrived at any time soon independently
a_chou has joined #zig
a_chou has quit [Client Quit]
dddddd has quit [Remote host closed the connection]
<shakesoda>
something i'd be interested in existing eventually: some alternate zig compiler (perhaps a zig jit or so, that would be very cool)
<dimenus>
andrewrk: fair enough. i don't have strong opinions on this. i'm just curious
<shakesoda>
in the sense that when a language exists in a form that can happen, i'm pretty confident in it being around to stay
<andrewrk>
shakesoda, I agree with you
<yeti>
I wasnt impressed by go, rust, v, and lots of other newcomers. maybe I'm "rusted to C", but zig got me curious!
stripedpajamas has quit [Ping timeout: 260 seconds]
dimenus has quit [Quit: WeeChat 2.8]
waleee-cl has quit [Quit: Connection closed for inactivity]
cole-h has quit [Quit: Goodbye]
ur5us has quit [Ping timeout: 244 seconds]
frett27 has quit [Ping timeout: 256 seconds]
KoljaKube has quit [Ping timeout: 272 seconds]
josias has joined #zig
ur5us has joined #zig
<andrewrk>
https://www.felixcloutier.com/x86/cmp I don't get it. `CMP AX, imm16` and `CMP EAX, imm32` have the same opcode (0x3D). how is the cpu supposed to know which instruction it is?
<scientes>
yeti, go also has the "no implicit control flow" rule
<scientes>
andrewrk, by the encoding of the register name
forgot-password has joined #zig
<andrewrk>
hmm I see, so in this web page, "AL" is just an example, it could be a different register
<scientes>
oh those are immediates
<scientes>
no, but the length of the immediate
<scientes>
yeah that is confusing
<scientes>
x86 multiple-length instructions are really confusing
<scientes>
you have to look at the instruction's bits for the answer to your question
<scientes>
compiler explorer knows this stuff for x86
forgot-password has quit [Ping timeout: 260 seconds]
<daurnimator>
andrewrk: IIRC, each code segment has a default register/operand size.
josias has quit [Remote host closed the connection]
<daurnimator>
andrewrk: if you're in a 32bit segment, then its EAX; if you're in a 16bit segment, then its AX
<daurnimator>
you can use the operand-size override prefix to change.
<andrewrk>
what does it mean to be "in a segment"?
<daurnimator>
so e.g. if you're in a 32bit segment, use 0x66 to swap to 16bit
<daurnimator>
uh; I guess back in early days it actually meant the segment registers? but now I just know it as writing e.g. `.code 16` in assembly....
<lemmi>
scientes: i have a very hard time figuring out what's what from the disassembly, maybe you can spot something, if you are interested
<scientes>
lemmi, well you said % is the problem
<scientes>
and that should be optimized
<lemmi>
scientes: i don't think the code is written in a way that the compiler could infer that this is always a power of two
<lemmi>
so that's kind of expected
<scientes>
oh ok
<scientes>
lemmi, sounds like an excessive amount of meta-programming if you ask me
<lemmi>
scientes: it kind of is. but otherwise it's hard to toy around with the parameters and the whole point was to see if you could actually write simd in zig without limiting yourself by the current hardware
dermetfan has quit [Ping timeout: 244 seconds]
swills has joined #zig
<daurnimator>
There's a little thing in LinearFifo that does a mod vs bitwise-and change
<ikskuh>
loris is now doing zig.show as a fulltime job *.*
<ikskuh>
:D
THFKA4 has joined #zig
<daurnimator>
wow
kristoff_it has joined #zig
<ifreund>
very cool news
<daurnimator>
I haven't even had time to watch the last episode yet :(
<dch>
ditto how are we supposed to keep up now :)
<ifreund>
kristoff_it: congrats!
<kristoff_it>
thank you very much!
<kristoff_it>
ikskuh: just to be clear, showtime is still my "sidegig" and I'll work on it when I'm not working for the ZSF. I'll talk more about the precise relationship between the two things (and more) on saturday.
<ikskuh>
hey, spoilers!
<ikskuh>
haven't read the full article yet, but sounds good already
<BaroqueLarouche>
congrats kristoff_it
<BaroqueLarouche>
!
<BaroqueLarouche>
Living the dream!
<kristoff_it>
thanks, we'll see, we need to make the right moves, otherwise it's going to be a short-lived dream, at least when it comes to my ability to work full-time for the ZSF :)
<BaroqueLarouche>
my dream: either doing games in Zig full-time and/or work on Zig full-time
<ikskuh>
kristoff_it: > I will reveal my (until now) secret recipe for a nice summer pasta.
<ikskuh>
that's a daaaamn good incentive :D
<kristoff_it>
yeah I still have to negotiate with andrew the goal we want to put behind it
<kristoff_it>
but I'm going to push for a pretty high one
<kristoff_it>
hah]
<ikskuh>
over 9000!
cole-h has joined #zig
<ikskuh>
kristoff_it: but nice read, i can relate to that :)
<kristoff_it>
thanks!
<ikskuh>
also, looking forward to sunday :D
<kristoff_it>
Sunday because you're in Australia (or whereabouts), right?
<ikskuh>
nah, german, CET :D
<ikskuh>
i can't let 23:59 be saturday anymore :D
<kristoff_it>
haha ok then that makes sense too :D
<fengb>
Off by 1 minute error
<kristoff_it>
urgh it seems the mods have tanked the lobsters post
<kristoff_it>
went from #2 to the bottom of the page in a blink
<fengb>
You got -2 off topic
<daurnimator>
kristoff_it: care to explain the dig at jepsen?
<fengb>
Not sure why
* daurnimator
always liked aphyr's write ups...
<kristoff_it>
daurnimator: jepsen and Redis have a long history. the guy is tecnically very correct in all he does, but I think it's no secret his dislike for Redis
<kristoff_it>
and in the end his was just yet another voice that screamed in one specific direction simply because he makes a living out of calling out database companies
<daurnimator>
I can't say I even knew he had an opinion about redis
<kristoff_it>
the problem is the nature of the audits he does: he can only prove stuff it's broken and never that it's correct
<kristoff_it>
and when you mix that with his history with Redis, I think he should very well get one good plate of boogers and cum
<dch>
such is the nature of science. proof by invalidation only requires 1 example.
antaoiseach has joined #zig
<kristoff_it>
anyway, it's just part of my explicitly over-the-top analogy
<kristoff_it>
don't take it too seriously
decentpenguin has joined #zig
<Sahnvour>
lemmi: cool! what max ratio did you use?
nikita` has joined #zig
<Sahnvour>
just checked actually, 9/8 it seems
dermetfan has quit [Ping timeout: 272 seconds]
<Sahnvour>
kristoff_it: congrats, taht's a huge milestone for Zig
<kristoff_it>
thanks!
<kristoff_it>
next step: take over the world
<Sahnvour>
I'd be ok with just not having to write c++ anymore, but heh :)
<lemmi>
Sahnvour: this ratio was giving best performance. you can go higher, like 257/256 and ist still works ok, but there is very little point in doing that
<Sahnvour>
yeah, ideally that's something the (advanced) user can control because this is one of many compromises that can be made in a hashmap, depending on your usecase
<Sahnvour>
anyways I have been convinced than most of the recent discourse on hashmaps is about making up for bad hash functions, which is kind of the wrong approach
<lemmi>
possible. but this was a fun project for a zig newbie like me. also this was my first hashmap implementation ever :>
<Sahnvour>
(by recent I mean various blogposts etc. not zig specifically)
<Sahnvour>
sure, i find it gratifying and you didn't go for the easiest one :)
<lemmi>
my guess is another speedup is to be had by using aes instructions for fast hashing like the go implementation does and i need to have a closer look at the new std map
<scientes>
Sahnvour, kyotocabinet is a great database with no press whatsoever
<Sahnvour>
hmm aes-based hash functions are good for large data, but for small keys (main hashmap usage) not so much i think
<scientes>
just use BLAKE3
<scientes>
chacha20-based
<Sahnvour>
these are cryptographic-level, we don't need that for a hashmap (plus they're slower :p)
<lemmi>
no the idea is to just use a single round or two of aes-ni to get something fast and not broken.
<scientes>
Sahnvour, i was saying that aes-based is dumb
<lemmi>
and if not available, there are tons of other suitable noncrypto hashfunctions
<Sahnvour>
that's useful in this case because you can hack the hardware support recent x64 CPUs have to make non-cryptographic hash function that go very fast, this is what lemmi is referring to
<Sahnvour>
this is what meowhash (and others) do lately
<scientes>
kristoff_it, lol, I got zig.party at one point
<scientes>
i think it is about to expire
<kristoff_it>
nice, I don't know how expensive party domains are, but if you have some spare cash, renew it, you can make something with it in the future
<kristoff_it>
zig partytime?
<kristoff_it>
actually Zig Party sounds so much better than ZigConf to me lmao
<jaredmm>
When cIncluding a library that imports OS headers causes redefinition errors because of translate-c errors, how would I prevent translate-c from creating that duplicate definition and instead use my own implementation of it?
<jaredmm>
Other than fixing the cause in Zig/translate-c (because I have successfully failed at accomplishing that).
<ifreund>
jaredmm: one way would be to generate the translation manually, then edit the outputted zig and include the zig file in your project
<ifreund>
you can do this with zig translate-c path/to/head.h
<jaredmm>
Hm. I have been manually running translate-c to try to solve the problem but did not consider that. Thanks.
<scientes>
the only reason to use them is that you need AVX-512BW
<scientes>
to test
waleee-cl has quit [Quit: Connection closed for inactivity]
marler8997 has joined #zig
nmeum has joined #zig
Mulugruntz has quit [Quit: ZZZzzz…]
<leeward>
So, I don't want to be that guy (I don't use AWS personally) but there are other reasons to use them. They just aren't technical.
<kristoff_it>
it should also be noted that if you're big enough they offer fat discounts
<kristoff_it>
especially if you decide to move with them from a competitor
<kristoff_it>
redis labs knows that well too
<leeward>
I used to work at a company that had all its software written in Ada. The CTO was a big fan. By the time they hired me they had rewritten the vast majority in C because they couldn't hire Ada programmers.
<leeward>
AWS certifications are a big deal, and encourage people to use AWS at several levels.
<fengb>
I remember they were one of the blessed services for credit reports
<fengb>
Had to stick with AWS or go through a lengthy audit process
<marler8997>
saw there was a discussion last night about open/closed source. My two cents, the more experienced I've gotten, then more I've realzied how important it is to have full control of your system, to be able to build/reproduce/debug and make changes anywhere in the system. If I have a closed source component, it becomes a rigid black box that I can't fix myself, and now I have to rely on others to support it for me.
<ifreund>
100% agree
<ifreund>
I will never use closed source software out of choice
<leeward>
If only software people got to decide what tools to use...
<leeward>
"This chip costs 6 cents less. We're using it."
<marler8997>
There's some open source hardware that's been coming out recently, that's exciting
<leeward>
marler8997: Do you mean like raspberry pi open source hardware or Risc-V?
<marler8997>
been seeing articles about them recently
<ifreund>
i've been longing for a trackball ever since I saw it
<marler8997>
oh yeah that looks cool too
<ifreund>
it also has a legit mechanical keyboard
<marler8997>
ifreund, I just read that !!!!
<leeward>
Wait, their phone isn't an android fork?
<marler8997>
I've spent so much time looking for a laptop with mech keyboard, I've given up
<marler8997>
leeward, if I remember right that's correct, not android
<leeward>
I miss laptops with track balls.
<marler8997>
goodness Android is quite a project, we put it on our products and it was my job to get that working...
xackus has quit [Quit: Leaving]
xackus has joined #zig
<Sahnvour>
too bad the librem doesn't have a ryzen cpu
cole-h has quit [Quit: Goodbye]
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
<marler8997>
I'm half tempted to get one of those MNT laptops, but I think I'm going to have to hold out until there's an open source laptop/PC with a RISC-v CPU
<marler8997>
liveness analysis...is there any github issue that discusses what this is?
* leeward
blames git.
* pixelherodev
doesn't
<pixelherodev>
- vs _ is a reasonable distinction
<pixelherodev>
marler8997: no
<pixelherodev>
tl;dr:
<pixelherodev>
it determines when a value is alive
<pixelherodev>
and when it's dead
<pixelherodev>
let's say we have e.g. `var a: u8 = blah;`
<pixelherodev>
liveness analysis detects when a is needed, and when it isn't
<pixelherodev>
So if we put a in some hardware register A, we know when we can use A for something else
<marler8997>
is this going to affect semantics from the programmer level at all, or is it just for the optimizer?
<pixelherodev>
Neither
<pixelherodev>
It's for raw codegen
<pixelherodev>
If you don't plan on working on stage2, and aren't interested in internals, you don't need to know this exists
<pixelherodev>
Anyways, working on adding a C test harness to stage2 :D
<pixelherodev>
andrewrk: should the CBE work with ZIR using the same path as Zig?
<marler8997>
oh I see, just an implementation detail for the codegen
st4ll1 has quit [Quit: WeeChat 2.8]
<pixelherodev>
marler8997: yeah, basically
<pixelherodev>
Hmm, I think CBE should work at the same level ELFFile does, so yeah
<leeward>
pixelherodev: I'm not saying git shouldn't make the distinction, but it should tab complete branch names and it should also be friendly about typos: "branch X doesn't exist, but x does. Is that what you meant?"
st4ll1 has joined #zig
<pixelherodev>
leeward: sure, that's fair
<pixelherodev>
I mean
<pixelherodev>
leeward: it does tab complete branch names for me
<pixelherodev>
But the latter would definitely be useful
<leeward>
Well that's something.
<marler8997>
the term "liveness analysis" reminded me of Walters "liveness" feature for D, where it implements some Rust-like lifetime features
<pixelherodev>
Hmm
<pixelherodev>
Should `pub` fns be non-static?
<pixelherodev>
Main is typically defined as `pub fn main`
<pixelherodev>
So `static void main(void)` would probably not be what we want for instance
<pixelherodev>
Okay, so for the CBE, `main` shouldn't be main
<pixelherodev>
We need to translate `start` as main, effectively
<pixelherodev>
Which makes this a bit more complex than just 1:1 translation
<pixelherodev>
Wait no, we'd be replacing crt0, that's all
<leeward>
pub functions definitely do not map to C's static functions.
<pixelherodev>
That's not what I said
<pixelherodev>
leeward: I said the opposite
kristoff_it has quit [Ping timeout: 264 seconds]
<leeward>
I know.
<leeward>
I'm agreeing.
<pixelherodev>
Non-pub functions should be static, pub should be normal
<leeward>
Yes.
<pixelherodev>
Hmm, need to figure out how to translate noreturn
<pixelherodev>
Probably just an assert(false)-esque bit at the end of the function?
<leeward>
GCC uses __attribute__((noreturn))
<leeward>
Probably don't want to go using non-standard compiler extensions though.
<pixelherodev>
Definitely not.
<pixelherodev>
That's a no-go.
<pixelherodev>
Appreciate the input though :)
<leeward>
Ooh, C11 adds <stdnoreturn.h> with _Noreturn.
<pixelherodev>
Huh
<pixelherodev>
So now we need to keep C standard in mind? :P
<pixelherodev>
That's actually a really good idea
<leeward>
We didn't before?
<pixelherodev>
CBE didn't exist before lol
<pixelherodev>
Hmm
<pixelherodev>
According to `catinc stdnoreturn.h`, noreturn is defined as _Noreturn
<leeward>
I maintain a fairly large C code generator that's strictly ANSI C because that's the least common denominator, and it's intended for embedded systems. If we're generating C code that isn't C89, we should probably have a switch for the supported standard.
<pixelherodev>
Now it's just a matter of figuring out unreachables
<pixelherodev>
leeward: that's what I'm doing
<pixelherodev>
Standard *must* be specified
<pixelherodev>
I'm going to use C11 for now, because e.g. noreturn is waaay too convienent
<pixelherodev>
But I'll implement the rest long before this is merged
<leeward>
unreachables are easy. Only allow --release-fast and --release-small, and make them UB. :P
<pixelherodev>
lol
<pixelherodev>
That's not an option
<leeward>
So much for the easy path.
<pixelherodev>
Yeah
<pixelherodev>
`function declared 'noreturn' has a 'return' statement`
<pixelherodev>
Implicit returns
layneson has joined #zig
frett27 has quit [Ping timeout: 240 seconds]
<pixelherodev>
Or
<pixelherodev>
for non-main functions
<pixelherodev>
`'noreturn' function does return`
<pixelherodev>
Needs an explicit `unreachable` of some sort
waleee-cl has joined #zig
<leeward>
You know, a working C back end could actually be a path to using Zig in my work stuff. We have qualified C compilers, and generated C code can be audited. It might be horrible though.
<pixelherodev>
My primary goal is for it not to be
<pixelherodev>
I'm writing some test cases explicitly geared towards readable code
<pixelherodev>
e.g. comments will be copied over properly if I have my way
<pixelherodev>
Formatting should be straightforward, and potentially configurable
<leeward>
Oh, I don't mean the generated code would be horrible, just the process of using Zig and auditing every line of C it generates.
<pixelherodev>
Ah, gotcha
<pixelherodev>
I mean, it should be close enough to 1:1 that it shouldn't be necessary
<marler8997>
to catch up, is the plan to create a "C Code Generating Backend", then compile the self-hosted zig compiler to C using that backend, then just maintain that going forward?
layneson has quit [Ping timeout: 258 seconds]
<pixelherodev>
marler8997: unclear
<pixelherodev>
I'm working on the CBE because there's general use for it
<leeward>
Definitely will be necessary, unless we want to qualify the Zig compiler, which is not an option before the language stabilizes and self-hosted is working.
<pixelherodev>
leeward: one option is to just do a from-scratch stage1 in C
<pixelherodev>
I'm personally in favor of a one-time translation to C
<marler8997>
I think he first wrote a "Mirth to C" compiler in python, then wrote his "Mirth to C" compiler in Mirth, then he was done
<marler8997>
he keeps the generated C code commited to his repo, so anyone with a C compiler can bootstrap it
<pixelherodev>
leeward: do you think it's worth tracking extensions too?
<pixelherodev>
there's a GCC / Clang extension for __builtin_unreachable()
<pixelherodev>
It might be worth supporting these types of extensions via flags
<leeward>
Is that part of one of GCC's supported "standards?" Like gnu99? If so, we could just adopt that nomenclature.
<pixelherodev>
Problem is, I also want to support compilers that don't implement them
<leeward>
If you want a compiler that doesn't implement GNU extensions to C99, pick "c99" instead of "gnu99"
<pixelherodev>
I *know* that lol
<pixelherodev>
I'm using that
<pixelherodev>
I've been using `gcc a.c -o a -pedantic -std=c99 -Wall -Wextra -Wshadow -nostdlib` for my tests
<pixelherodev>
(to test ideas for generated code)
<pixelherodev>
The idea here being to *additionally* support e.g. gnu99
<pixelherodev>
Huh
<pixelherodev>
That's
<pixelherodev>
Actually exactly what we should do
<pixelherodev>
Just add GNU99 to the Standard enum, not just C99
<leeward>
Yes, that.
<pixelherodev>
Yeah, sorry
<pixelherodev>
Still on my second cup of tea ;)
<leeward>
No worries. You might be on to something though: breaking down features more granularly internally might make for cleaner code.
<pixelherodev>
Hmm
<leeward>
`if (features.noreturn) { use_noreturn() } else { append_unreachable() }` instead of checking for standards everywhere.
<pixelherodev>
Cleaner internals *and* more fine-grained control over output
<leeward>
Then there's a single place with a map from standards to featuresets.
<pixelherodev>
yeah
<pixelherodev>
Thanks for the feedback, you've been really helpful
<leeward>
Any time.
<pixelherodev>
Literally?
<pixelherodev>
how about two weeks ago?
<pixelherodev>
;)
<leeward>
Mmm, almost.
<pixelherodev>
Hmm... is noreturn separate from return type in C???
<pixelherodev>
... yep
<pixelherodev>
weiiird
<leeward>
Yeah, tacked-on features.
<leeward>
noreturn int foo(void); // Totally a thing.
<leeward>
In fact, I have the following code in a real repository: `int main(void) __attribute__((noreturn));`
<pixelherodev>
lol
<leeward>
The standard requires main to return int.
<pixelherodev>
Hmm, okay, we want to support building without libc still
<pixelherodev>
So I shouldn't use e.g. assert.h for unreachables
<pixelherodev>
Call a panic function, maybe?
<pixelherodev>
exit(1) for now
<pixelherodev>
Need to translate exit for that, too :P
<leeward>
It still has to use crt though, since it's depending on a C compiler, right?
<pixelherodev>
nope
<pixelherodev>
`-nostdlib`
<pixelherodev>
Same thing you'd do for freestanding
<leeward>
Huh, fun. My AVR thing links to libgcc, but only because it sets up the interrupt vector table.
<pixelherodev>
Does e.g. stdnoreturn.h count as part of libc?
<pixelherodev>
Or is it considered to be part of the compiler?
<leeward>
_Noreturn is built into the compiler, I think anything in a header file is part of the standard library.
<pixelherodev>
Right, which is why I'm using _Noreturn by default
<pixelherodev>
I'm constructing the expected output of the first test
<pixelherodev>
From there, I can expand the test harness, which will show where to expand the internals
<pixelherodev>
... do you have a good example of asm volatile syscalls in GCC?
<pixelherodev>
I freaking hate inline asm
<leeward>
stdnoreturn.h does just use the preprocessor to define noreturn, so it's about where you draw the line.
<pixelherodev>
Which is why I'm defining noreturn manually
<leeward>
At link time, there's no libc
<pixelherodev>
I know :P
<leeward>
There is no such thing as a good example of asm volatile <anything> in GCC. Inline asm in GCC is such a pain.
<pixelherodev>
But the idea is to make it possible to use without the headers
<pixelherodev>
Hence
<pixelherodev>
I want to copypasta
kristoff_it has joined #zig
_Vi has quit [Ping timeout: 244 seconds]
<leeward>
You want to call a syscall or expose one?
<pixelherodev>
Call
<pixelherodev>
I want syscall1, effectively
<leeward>
Why not just call it?
<pixelherodev>
If we can translate inline asm, it makes the basic tests much easier
<pixelherodev>
Because i need it in C
<leeward>
I'm confused.
dimenus has quit [Quit: WeeChat 2.8]
<leeward>
Does it make sense to make a syscall with -nostdlib?
decentpenguin has quit [Quit: decentpenguin]
layneson has joined #zig
layneson has quit [Ping timeout: 246 seconds]
gpanders has quit [Ping timeout: 246 seconds]
gpanders has joined #zig
<pixelherodev>
okay I can't figure out the syscalls lol :P
ifreund has quit [Ping timeout: 246 seconds]
<pixelherodev>
and now I've got it
<pixelherodev>
just when i complain I couldn't
ifreund has joined #zig
<leeward>
\o/
<leeward>
It's the ask for directions phenomenon. By the time you ask, you're almost there.
<pixelherodev>
Lol
<pixelherodev>
almost every time I ask for help on IRC, I either figure it out before or just after someone responds
<pixelherodev>
How do I mark a syscall as noreturn? :thinkingface:
dingenskirchen has quit [Remote host closed the connection]
<pixelherodev>
Without __builtin_unreachable...
dingenskirchen has joined #zig
Akuli has joined #zig
<pixelherodev>
Gah
<pixelherodev>
I don't got it
<pixelherodev>
It's using the wrong register???
<pixelherodev>
Yay! Got it!
<pixelherodev>
Constraints are dumb
<pixelherodev>
Huh
<pixelherodev>
musl uses ` for (;;) __syscall(SYS_exit, ec);` for `unreachable`s
<pixelherodev>
I think I'll copy that
<pixelherodev>
Except no
<pixelherodev>
Hmm
<pixelherodev>
maybe tho
<leeward>
Calling SYS_exit isn't likely to do good things on freestanding or any non-posix.
<pixelherodev>
True
<pixelherodev>
Maybe I should just call an UNREACHABLE function?
<pixelherodev>
Or panic?
<pixelherodev>
@panic("Unreachable") equivalent?
<forgot-password>
Is there any documentation on calling conventions?
<pixelherodev>
Not really, sorta, kinda
<pixelherodev>
LLVM docs currently, for most of em
<forgot-password>
Is `Stdcall` the default one?
<forgot-password>
I just want to export a function for use by another Zig program, so I don't need any c compatibility or anything.
<leeward>
Use the default then.
<leeward>
pub functionToExport() !void
<pixelherodev>
forgot-password: the default is Unspecified
<pixelherodev>
Which is explicitly, well, unspecified
<pixelherodev>
the compiler can do whatever
<pixelherodev>
If you export it, it needs to be specified explicitly IIRC
<pixelherodev>
if it's @import-ed, the compiler handles it for you
<pixelherodev>
I mean, I *can* do technical docs, and pretty well if I do say so myself
<forgot-password>
It's obviously not as in-depth the docs, but it gives a very nice overview
<pixelherodev>
Problem is, I can *also* do code
<pixelherodev>
and code tends to be more in demand :P
<pixelherodev>
leeward: now for the fun part
<pixelherodev>
I mentioned static earlier: Zig by default does the whole module as one
<pixelherodev>
So should the CBE do that too, and mark everything static? Well, yes and no
<pixelherodev>
It's useful as a default mode for simplistic output, yes, but if you want to actually look at the C afterwards, we need to auto-generate multiple files
frmdstryr has quit [Ping timeout: 272 seconds]
<leeward>
#include "module_thing.c"
<leeward>
^abomination
<pixelherodev>
lol, not what I meant
<pixelherodev>
I meant auto-generation of headers and such
<pixelherodev>
so e.g. std.os.exit(1) should result in auto-inclusion of a header std/os.h
<pixelherodev>
and exit would be put into std/os.c
<leeward>
If you wanted to make everything static, that would be a way to do it. Not a good way.
<pixelherodev>
Not everything would be static
<pixelherodev>
Everything non-public would be
<pixelherodev>
Every public would be non-static
<pixelherodev>
(and visible in the header)
<leeward>
Yeah, that's the right way to do it.
<pixelherodev>
That's... what I meant all along?
<leeward>
I know.
<pixelherodev>
"That wouldn't be a good way" -> "that's the right way"
<pixelherodev>
I didn't change what I was saying though :P
<leeward>
Oh, the way I said.
<pixelherodev>
Ahhhh
<pixelherodev>
#include ".c"?
<pixelherodev>
yeah ew
<leeward>
"that wouldn't be a good way" was at something I said, the right way was something you said.
<leeward>
Text: not the best of media.
<pixelherodev>
This'll be harder to conveniently test
<pixelherodev>
Well
<pixelherodev>
Tests could use single-file output
<leeward>
A nice thing that might fall out of this is sensible header file generation. That's one of the things blocking a project I have.
<leeward>
If --emit-h hooked into the C backend, it would be better.
<pixelherodev>
Currently, we don't have that?
<pixelherodev>
Or, not well?
<leeward>
It's...not the best.
<pixelherodev>
leeward: mind taking a look at a sample real quick?
<pixelherodev>
leeward: most of it would be in start.c
<pixelherodev>
(for multi-file output)
<leeward>
ifreund: Oof, side effects. I believe I did read something about that.
<leeward>
pixelherodev: Yeah, that looks good then. For single-file output we have to tolerate a bunch of boilerplate.
<pixelherodev>
Most of that would be in std/{start,os}.zig
<pixelherodev>
s/zig/c
<ifreund>
i know this has bit me in C++ before wrt order of evaluation for function parameters
<pixelherodev>
unreachable probably needs to be user-defined for freestanding, but on standard targets we can probably define it as std.os.exit(1) or something like that
<ifreund>
if you use an initializer list in C++ the order of evaluation is well defined
<pixelherodev>
Or, down the line, do the optimizations and remove the unreachable before hitting cgen
<pixelherodev>
The biggest problem here is e.g. never_inline
gpanders has quit [Ping timeout: 264 seconds]
<pixelherodev>
Can't translate those without compiler-specific extensions
<pixelherodev>
So, by default, they probably shouldn't be translated at all
<pixelherodev>
Going to be volleying a test harness modification patch shortly
<ifreund>
does that actually break anything? or is it just bad for perf
<pixelherodev>
ifreund: hopefully, neither
<pixelherodev>
never_inline can be used if you want to force the compiler to evaluate inline asm without doing anything else
<ifreund>
i mean, there's a reason we have never_inline right?
<pixelherodev>
e.g. on freestanding, to read registers from the firmware before the compiler overwrites them
<pixelherodev>
So yeah
<pixelherodev>
But IMO there should be a better way anyways
gpanders has joined #zig
Mulugruntz has joined #zig
Akuli has quit [Quit: Leaving]
gpanders has quit [Ping timeout: 272 seconds]
gpanders has joined #zig
cole-h has joined #zig
nikita` has quit [Remote host closed the connection]
<andrewrk>
marler8997, yeah it's just for register allocation, so that the codegen knows when it can re-use registers
<andrewrk>
when an instruction "dies" then it's not referenced anymore, so the stack memory or register it was stored in can be reused
<andrewrk>
I'm pleased with the scheme I came up with to store the results of the liveness analysis
<andrewrk>
nearly free in terms of memory usage, and only requires 1 pass over to compute, which is the theoretical minimum
<ifreund>
sounds quite optimial indeed
<pixelherodev>
Recommended compiler flags will probably end up being along the lines of `-pedantic -std=c11 -Wall -Wextra -Wshadow -nostdlib -nostdinc -fno-builtin -Wno-main` lol
<pixelherodev>
(since we effectively replace libc with zig's stdlib)
<leeward>
So...what happens if I use the C backend to generate a bunch of C code, then zig cc it? I'm not sure what I think should happen, but "smite" is probably involved.
<pixelherodev>
lol
<pixelherodev>
It should compile without issue
<pixelherodev>
Given that zig cc is currently just clang :(
<pixelherodev>
If I eventually get my way and add a CFE, it'll still probably be supported
<pixelherodev>
I can't imagine why it wouldn't
<pixelherodev>
Hmm, C tests need to use a separate harness
<pixelherodev>
They can't partake in the normal update process
blinghound has joined #zig
xackus has quit [Quit: Leaving]
<andrewrk>
pixelherodev, are you sure they can't? even if it mean redoing all the work
<andrewrk>
update() just means do the same compilation again
<pixelherodev>
Well, true
<pixelherodev>
Some of it can just be unreachable
* pixelherodev
shrugs
<andrewrk>
for a C backend that means just recompile the changed files
<pixelherodev>
I'm not obsessing over this rn
<pixelherodev>
I'm only setting this up so I can use it to work on the actual CBE
<pixelherodev>
This part can be fully redone later if desired
<andrewrk>
yeah this is sort of what I was getting at earlier regarding making "destructive" changes to the code, and then reworking them back in later
blinghound has quit [Remote host closed the connection]
<andrewrk>
you saw me do that technique when adding Zig AST->ZIR support
<ifreund>
hmm, why can't I do Foo{ .x = 3 }.methodOnFoo();
<ifreund>
i guess the syntactic sugar isn't quite sweet enough :P
<ifreund>
gotta do Foo.method(Foo{ .x = 3 }) instead
dermetfan has quit [Ping timeout: 244 seconds]
<fengb>
Foo.method(.{ .x = 3 })
<fengb>
I think adding parens makes the method syntax work: (Foo{}).method()