* pixelherodev
has no idea why CI is failing on #5833
* pixelherodev
will look into it tomorrow
<pixelherodev>
Looks almost like it's actually hitting OOM
stripedpajamas has quit [Quit: sleeping...]
<leeward>
I do not get why TI felt the need to call their programmer a FET. It's not a field effect transistor. Grumble grumble.
cole-h has quit [Quit: Goodbye]
stripedpajamas has joined #zig
stripedpajamas has quit [Quit: sleeping...]
_whitelogger has joined #zig
daex has joined #zig
oats has joined #zig
swills has joined #zig
so has joined #zig
jwmerrill has joined #zig
drp has joined #zig
diginet has joined #zig
pangey has joined #zig
wilsonk has joined #zig
lunamn has joined #zig
JoshAshby has joined #zig
ncon has joined #zig
tines9 has joined #zig
edr has joined #zig
fengb has quit [Ping timeout: 241 seconds]
return0e[m] has quit [Ping timeout: 246 seconds]
matti has joined #zig
nmeum has joined #zig
r0bby has joined #zig
kushalp has quit [Ping timeout: 246 seconds]
betawaffle has joined #zig
Snektron has quit [Remote host closed the connection]
pmwhite has quit [Remote host closed the connection]
ovf has joined #zig
kushalp has joined #zig
so has quit [Ping timeout: 246 seconds]
ovf has quit [Excess Flood]
ovf has joined #zig
ifreund[m] has joined #zig
so has joined #zig
alva has joined #zig
return0e[m] has joined #zig
hamoko[m] has joined #zig
pmwhite has joined #zig
Snektron has joined #zig
BaroqueLarouche has joined #zig
fengb has joined #zig
fraktor has joined #zig
<fraktor>
Does anything like a channel exist in Zig? I'm looking at maybe doing some multithreading/async stuff and work queues would be super helpful.
<daurnimator>
there's a std.atomic.Queue. not sure if that's the best choice
ur5us has quit [Ping timeout: 244 seconds]
<daurnimator>
its just a mutex around a tailqueue I think?
<fraktor>
Cool. Are there also condition variables and muticies in the standard library?
<fraktor>
...well I'm dumb, I just found mutex.zig.
<daurnimator>
mutex yes; "condition variable" has several different meanings depending if you're coming from compsci vs POSIX vs c++ vs ... etc.
<fraktor>
I would like something that allows me to block until something else notifies it.
<daurnimator>
fraktor: std.ResetEvent ?
craigo has quit [Ping timeout: 244 seconds]
_whitelogger has joined #zig
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
frett27 has quit [Ping timeout: 240 seconds]
ur5us has joined #zig
_Vi has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
_Vi has quit [Ping timeout: 272 seconds]
dermetfan has joined #zig
opDispatch has quit [Quit: Konversation terminated!]
dermetfan has quit [Ping timeout: 260 seconds]
riba has joined #zig
nikita` has joined #zig
riba has quit [Ping timeout: 246 seconds]
dermetfan has joined #zig
riba has joined #zig
riba has quit [Ping timeout: 246 seconds]
frett27 has joined #zig
st4ll1 has quit [Quit: WeeChat 2.8]
frett27 has quit [Ping timeout: 272 seconds]
dch has quit [*.net *.split]
heitzmann has quit [*.net *.split]
ifreund has quit [*.net *.split]
terinjokes has quit [*.net *.split]
blueberrypie has quit [*.net *.split]
dch has joined #zig
ifreund has joined #zig
heitzmann has joined #zig
blueberrypie has joined #zig
terinjokes has joined #zig
craigo has joined #zig
Mulugruntz has quit [Ping timeout: 244 seconds]
Mulugruntz has joined #zig
drp has quit [Ping timeout: 264 seconds]
xackus has joined #zig
_Vi has joined #zig
frett27 has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
goodthingshappen has joined #zig
<goodthingshappen>
I have a little trouble packaging a project written in Zig for linux; I have error like "no access to builtin.zig". The source of problem is that a package build system of my linux distro doesn't provide a $HOME environment variable and doesn't create $HOME/.cache, $HOME/.cache/zig directories, so i have to
<goodthingshappen>
create a pre-configure phase where i set HOME env variable and create ~/.cache/zig directory. Can Zig change it's behaviour to only use zig-cache from project specific directory?
<goodthingshappen>
It would make packaging of projects written in Zig for various linux distros much easier.
<goodthingshappen>
By the way good job with bootstrap process! I have great pleasure building Zig, especially after I discovered that to build Rust without depending on binaries from Mozilla you have to build like 30+ compilers, each new compiler depend on previous one
<ifreund>
goodthingshappen: I think the best thing to do would be to open an issue to discuss things. I think being easy to package is certainly a goal for zig
Mulugruntz has quit [Ping timeout: 260 seconds]
<goodthingshappen>
I have some troubles with registering github this month, but if someone will create an issue about this, i'll appreciate it
Mulugruntz has joined #zig
cole-h has joined #zig
layneson has joined #zig
goodthingshappen has quit [Remote host closed the connection]
<fraktor>
daurnimator: Not quite. I guess I meant something more like a posix-compatible one, since this one needs to be set and then reset. I suppose I could just call set and then reset immediately, but does that defeat the purpsoe of this?
<pixelherodev>
Anyone have any idea how much RAM the non-FreeBSD CIs have?
<pixelherodev>
This looks very much like an actual OOM issue
<pixelherodev>
Except that it's the same issue on both CIs, regardless of platform
<pixelherodev>
I'd expect at least a marginal difference if that was it..
<pixelherodev>
... huh.
<pixelherodev>
`Assertion failed at D:\a\1\s\src\ir.cpp:14180 in ir_analyze_widen_or_shorten. This is a bug in the Zig compiler.`
<pixelherodev>
The Windows one gave more info than the other ones. Shocking.
cbarrett has quit [Ping timeout: 256 seconds]
<pixelherodev>
Ohhhhh, I see; it's not my fault lol
<pixelherodev>
It was based on the wrong commit
<pixelherodev>
This failure was in the master branch, not me; just going to do a force-push and retrigger CI
wjlroe has quit [Ping timeout: 256 seconds]
wjlroe_ has joined #zig
cbarrett has joined #zig
casaca has quit [Ping timeout: 256 seconds]
eddyb[legacy] has quit [Ping timeout: 256 seconds]
eddyb[legacy] has joined #zig
drewr has quit [Ping timeout: 244 seconds]
layneson has quit [Ping timeout: 256 seconds]
layneson has joined #zig
<fraktor>
I see that the builder in build.zig seems to have a pretty robust command-line parser. Does that exist in the standard library?
<pixelherodev>
I don't believe so
<pixelherodev>
IMO We should extract it from build.zig into std.arg and use that
<pixelherodev>
or std.cli.args or something like that
frett27_ has joined #zig
<pixelherodev>
Alternately, the build system should be separated from stdlib
<pixelherodev>
e.g. lib/build instead of lib/std/build
frett27 has quit [Ping timeout: 246 seconds]
shcv has quit [Remote host closed the connection]
stripedpajamas has joined #zig
<pixelherodev>
Ha!
<pixelherodev>
I knew it wasn't my fault!
<pixelherodev>
andrewrk: planning on handling @import anytime soon?
<pixelherodev>
If not, I think that'll be my next big undertaking
jmiven_ is now known as jmiven
<pixelherodev>
Or maybe I'll refactor the test harness to allow defining multi-file tests, while maintaining the convenience wrappers for single-file stuff
<pixelherodev>
That would allow for testing @import, shared libraries, static linking, etc
<ifreund>
is it planned for zig to have shared libs?
<scientes>
ifreund, you mean a standard library?
<ifreund>
well c abi ones for sure, but I don't know about zig abi shilbs
<scientes>
ifreund, zig supports shared libraries, but shared libraries are a PITA to maintain
<ifreund>
scientes: I mean dynamic linking
<scientes>
ifreund, yeah you can do that
<scientes>
ifreund, it is compatible with the C ABI if you do
<scientes>
but zig is not limited to such an interface
<scientes>
I would really like to see a C-like language that targets FPGAs for example
<ifreund>
yes I know that we have C abi dynamic linking, was wondering if zig abi dynamic linking was in the cards
<scientes>
C-machine-language
<ifreund>
not sure if it's a good idea tbh
<scientes>
even if FPGAs are not C machines
<scientes>
ifreund, zig does not have an external abi, it's external abi is the C ABI
<scientes>
and the entirety of it's external ABI
shcv has joined #zig
<fengb>
Zig ABI is not planned atm
<scientes>
oh, zig also calls into the LLVM assembler
<scientes>
so two external ABIs
<fengb>
But it is brought up semi-regularly and not ruled out either
<scientes>
fengb, I think you are missing the forrest for the trees
<fengb>
I'm just stating facts
<shcv>
zig seems like it would have multiple ABI options, that you select at compile time...
<fengb>
It's not planned but it's also not completely ruled out
<scientes>
shcv, what I am talking against is a over-ambitious scope of the zig project
xackus has joined #zig
<scientes>
that I feel is losing track of one of the initial goals: replace C
<scientes>
I just this that X86 is a really ugly language and that writing an assembler is not part of the goal of the zig project
<scientes>
*feel that
waleee-cl has joined #zig
layneson has quit [Ping timeout: 246 seconds]
<pixelherodev>
ifreund: we already have shared libraries
<pixelherodev>
and dynamic linking
<scientes>
I hate how long C++ takes to compile
<leeward>
scientes: verilog is a C-like language (syntactically, at least)
<leeward>
So is SystemC
<scientes>
leeward, I am talking about global memory addresses then
<scientes>
with DRAM
<leeward>
I'm not sure how that relates to FPGAs.
<scientes>
i think a x86 assembler in zig is a waste of everyone's time
<leeward>
Personally, I like VHDL better, but I think I'm rare there.
<leeward>
scientes: I think that's true now, but hope it won't be true forever.
<scientes>
then why are we doing it?
<leeward>
We are?
<scientes>
as Knuth says, the most important thing is the data structures
<scientes>
leeward, check the git
<scientes>
in the src-self-hosted
<ifreund>
pixelherodev: not with zig abi, only C abi
<scientes>
ifreund, what would this hypothetical "zig abi" do?
<leeward>
huh
<leeward>
Well, at least it's not a hard problem.
<shcv>
what's wrong with assembler in zig? It seems pretty reasonable to me, and is done pretty regularly in C programs too...
<leeward>
shcv: scientes is talking about an assembler, not inline assembler language.
<shcv>
oh
<ifreund>
uh, have zig types like error sets and tagged unions
<leeward>
I think, anyway.
<scientes>
ifreund, error sets are dynamic
<scientes>
there is no ABI
<ifreund>
right
<leeward>
I think once ZIR is stable we can use it to ship "object code"
<shcv>
I think the ABI should be somewhat configurable, so it can match other languages and runtimes more easily, or support the development of new ABIs
<leeward>
It could serve the purpose of an ABI.
<shcv>
plus, that removes the burden of "getting it right"
<scientes>
leeward, but WHY is X86 a useful language to implement?
<ifreund>
i dont think ZIR is planned to be stable
<scientes>
there are many much better languages that can target X86
<ifreund>
it's an implementation detail that makes debugging easier not an interface last I heard
<leeward>
scientes: It's super common, but...not my call. I'd focus elsewhere and shell out to one of the many working assemblers out there.
<scientes>
LLVM and MLIR and GCC/GIMPLE being the big ones
<scientes>
I don't see the usefulness of attaching our boat to the intel boat
<ifreund>
forgive me if I'm wrong, but don't you need a lot of control over codegen for incremental compilation?
<scientes>
ifreund, I think we can use the LLVM JIT
<leeward>
ifreund: It makes a lot of things easier. I don't know that it's planned, but I think it would be cool.
<leeward>
I remember someone saying recently that llvm and incremental code gen are incompatible.
<leeward>
I don't know enough about the subject to have an opinion though.
<scientes>
well LLVM does have a global use list
<scientes>
so it doesn't multi-thread well
<scientes>
but that is a completely differen't problem
<scientes>
ahh I see, as you have to compile the whole LLVMModule()
<ifreund>
I agree that stable ZIR would be cool, you gotta convince andrew that it'd be worth the maintainence cost though
<scientes>
I guess in that case MLIR would be better
<scientes>
-global-isel means that the llvm compiler is getting faster
<scientes>
It is not Javascript-class, but it would be fine for comptime
<leeward>
I think a stable ZIR is the kind of feature that is worth adding post-1.0. I'll make the case to Andrew when the language itself has less churn.
<ifreund>
I also think there's a lot of value in llvm not being a hard dependecy, it's not exactly one of those lightweight deps you can forget about
<ifreund>
I mean, look at the recent packaging mess
<scientes>
ZIR is exactly the thing that MLIR is designed so that you DONT need
<scientes>
I also don't like branding everything Zig
<scientes>
given that I think the project lost sight of its initial goal: replace C
<scientes>
ZIR is a differn't language from Zig, and one that I don't see as useful
<leeward>
Can't replace C (for me) without better architecture support than LLVM has. Granted, the effort could be put towards improving LLVM.
<scientes>
leeward, that is the whole point of LLVM to solve the NM problem
<leeward>
by architecture, I mean variety of CPU architectures
<scientes>
that for N languages and M arches, you need N x M compilers
<leeward>
Right, it's just that the actual LLVM implementation (today) fails to do that for several architectures. ARM support is great, but Apple doesn't care about weird chips they don't use.
<scientes>
leeward, LLVM is not a Apple project
<scientes>
not even slightly
<scientes>
sure, they have a non-free AppleGPU target
<scientes>
leeward, LLVM actually does, it is just a matter of lack of interest in maintaining them
<leeward>
I know it wasn't started by Apple, but Apple has put a lot of money into it.
<scientes>
leeward, the real problem is that super small chips don't really need an optimizing compiler, so in that case a non-optimizing C compiler is easier to write
<leeward>
All the chips I'm thinking of are supported by GCC.
<scientes>
leeward, Google has put as much, and IBM hired people to do the Power backend, et cetera
<scientes>
now Xilinx is working circt
<scientes>
et cetera
<scientes>
leeward, GCC also is a reasonable target
<scientes>
I wouldn't think Zig had strayed it was targeting gcc JIT
<scientes>
or just doing a simple interpreter
<shakesoda>
my gpu compute style task system is almost working, if i can brain a little bit harder to get the last bits behaving
copy has joined #zig
<scientes>
shakesoda, what programs are you running on your GPU?
<shakesoda>
it isn't really that much different from a regular thread pool/task thing, work submission is just in big groups
<leeward>
So no pipelining?
<scientes>
and what language/toolchain?
<shakesoda>
scientes: this is for the cpu, but i wanted a scheduler that behaves more like the ones i use for graphics
<scientes>
what are you scheduling?
<shakesoda>
but to be sure i work on games, so this is things like weather, lighting, particle systems, general entity updates...
<shakesoda>
leeward: some ability to do pipelining is in the design, but that's not a primary need up front
<leeward>
shakesoda: Yeah, I didn't realize it was aimed at CPUs when I asked. It's not as important when you don't have more cores than tasks.
<shakesoda>
yeah, i've got a plan for that but for my initial needs i have more tasks than cores
<fengb>
downloadmorecores.com
<fengb>
lol that's an actual website
<scientes>
fengb, and it really lets you download more cores
<pixelherodev>
scientes: we don't have an x86 assembler...
<pixelherodev>
We have codegen, yes
<pixelherodev>
But it's not x86 -> machine code
<pixelherodev>
It produces raw machine code from IR
<shakesoda>
leeward: a lot of my motivation here is just being used to thinking about group execution for threading in gl/vulkan, so this is a good step toward refactoring out a lot of single threaded code
<scientes>
<pixelherodev> But it's not x86 -> x86
<scientes>
FTFY
<shakesoda>
i thought a bit about it and realized i kept having things that fit that model just fine, but were tremendously difficult to think about when thinking about tasks as individual things
<fraktor>
I'm still a little hazy on why ZIR is the plan instead of using LLVM. I understand it's a big dependency, but is it so complex that it would be easier to write a new set of "assemblers" from scratch?
<fraktor>
s/easier/easier or better in some way/
<shakesoda>
fraktor: faster compiles
marijnfs has joined #zig
<fengb>
ZIR already exists in some degree. It's currently undocumented and kinda janky
<marijnfs>
whats up with the HashMap?
<marijnfs>
put changes i see
<scientes>
fengb, this is the problem MLIR was generated to solve
<pixelherodev>
scientes: not that, either
<pixelherodev>
it's IR -> machine code
<pixelherodev>
fraktor: yes.
<pixelherodev>
LLVM is really that bad.
<pixelherodev>
LLVM is six million lines of code.
<scientes>
pixelherodev, I don't think you can do any better
<pixelherodev>
We can get everything we need from it in a percent of that
<pixelherodev>
scientes: it doesn't have to produce better code.
<shakesoda>
scientes: building faster than llvm is not a high bar
<pixelherodev>
This is about lightning fast *compilation*
<scientes>
pixelherodev, no, it is the data structures
<pixelherodev>
? What is?
<shakesoda>
building a faster executable *is* a high bar, but that's not the point
<scientes>
pixelherodev, getting the data structures right is the most important thing
nikita` has quit [Quit: leaving]
<shakesoda>
well that's a general truth
<pixelherodev>
Yeah
<pixelherodev>
It's also important to remember the goals here
<scientes>
and what is wrong with the data struvtures in MLIR/LLVM?
<pixelherodev>
* Don't depend on a C++ compiler
<pixelherodev>
* Targets that aren't supported by LLVM. Lots of them.
<shakesoda>
i don't know about llvm's guts but it is hellishly slow
<pixelherodev>
* As-fast-as-possible compilation in debug mode
<pixelherodev>
LLVM misses all three of those, plus more besides
<fengb>
Back in mah day, LLVM was fast!
<shakesoda>
fengb: back in my day, llvm was... still slow! but faster than the other things!
<scientes>
if you could make LLVM fast you would be rich, and you are not rich
<scientes>
as LLVM is not GPL you could just fork it and then sell a "fast" version of LLVM
<scientes>
and get rich
<scientes>
the problem is that it is too much work
<shakesoda>
that's making an awful lot of assumptions about the reader
reductum has joined #zig
<scientes>
so the real problem: what is wrong with the LLVM/MLIR data structures
<pixelherodev>
scientes: this isn't about making it *fast*
<pixelherodev>
Rather
<pixelherodev>
This isn't about making *it* fast
<pixelherodev>
This is a from-scratch design with *one purpose*
<scientes>
pixelherodev, what are the various instruction selectors for LLVM?
<pixelherodev>
LLVM supports many *frontends*, our goal is to support many *backends* and *only ever one frontend*
<scientes>
(this is a quiz)
<pixelherodev>
lol
<shakesoda>
pixelherodev: whens zigjit
<scientes>
<pixelherodev> LLVM supports many *frontends*, our goal is to support many *backends* and *only ever one frontend*
<shakesoda>
:D
<scientes>
hello superman
<scientes>
yeah, if you think that is a good idea, I clearly am talking to a brick wall
<pixelherodev>
shakesoda: technically, I could hook up ZIR to my JIT interface pretty easily, but I won't
<pixelherodev>
It's not a good idea lol
<shakesoda>
if you aren't trying to do everything in the world, and just want to get valid output as fast as possible, llvm will never be a path to victory
<pixelherodev>
I want to accelerate *comptime* with a JIT
<pixelherodev>
I don't want to make a JIT for actual Zig
<pixelherodev>
One of them is already for all intents and purposes an emulator.
<fengb>
I mean... isn't a comptime JIT basically a full Zig JIT already?
<scientes>
pixelherodev, what are you accelerating?
<shakesoda>
i dunno about making said jit for actual zig, but i would like to _have_ one
<shakesoda>
isn't comptime all interpreted, like, extremely slowly right now?
<pixelherodev>
Yes
<scientes>
anyways, I clearly am talking to a brick wall
<pixelherodev>
lol
<scientes>
comptime is also COMPLETELY UNIMPLEMENTED
<scientes>
as in that it cannot alias at all
<pixelherodev>
It's *partly* implemented for stage1, but that's true
<scientes>
so why are you trying to run before you can walk?
<shakesoda>
quizzing about llvm here just isn't a productive argument to be having, so yes, you're talking to a wall
<pixelherodev>
I'm not.
<pixelherodev>
scientes: I'm *not* working on this in any fashion.
<pixelherodev>
I've so far floated it for *after we have an interpreter*
<pixelherodev>
It's an idea for *after we have stage2 working*
<scientes>
shakesoda, its just familiarity with the general structure
<pixelherodev>
I've worked with LLVM IR, but libLLVM is just ugh.
<pixelherodev>
scientes: one key reason to use our own backend is that a 20 minute build for the compiler won't be considered impressively fast.
<pixelherodev>
The goal is to deliberately trade optimizations for as-fast-as-possible *compilations*
<pixelherodev>
And no, turning off optimizations with LLVM doesn't help.
<scientes>
that is what the -fast-isel backend is about in llvm
<pixelherodev>
Startup time for LLVM is nearly 10 milliseconds
<scientes>
but now it is moving to -global-isel
<pixelherodev>
Even if LLVM's compile speed w/o optimizations was able to match ours (it won't), it still doesn't change the numerous other reasons
<scientes>
the only reason should be that you have better data structures than LLVM
<pixelherodev>
I'm fairly certain we do, but I'm not willing to dig into LLVM to verify.
<scientes>
you could also write bitcode
<scientes>
and pipe it
<pixelherodev>
Smaller compiler binaries, simpler to add new (even custom) backends, the *entire impl* is self-hosted (zero external dependencies)
<scientes>
all completely unprooven
<pixelherodev>
LLVM isn't a good fit for stage2's goals, and there's really nothing that will change that
<scientes>
and your confidence is scary
<pixelherodev>
The entire impl is self-hosted / no external deps is *completely* proven
<shakesoda>
the proving is building it ;)
<scientes>
I don't like C++, but I ceetainly know that you don't have the man-power to write something like GCC or LLVM
<pixelherodev>
Okay, so?
<pixelherodev>
That's not our goal.
<shakesoda>
uh, the explicit point is not making something like them
<shakesoda>
that was the whole discussion
<pixelherodev>
We're explicitly not *wanting* that.
<scientes>
even something like v8 or spidermonkey
<scientes>
is way beyond our man-power
<pixelherodev>
Again, not *remotely* what we want.
<pixelherodev>
Everything you've listed has one shared quality: complexity.
<shakesoda>
generating machine code quickly from an ir isn't an intractable problem
<scientes>
shakesoda, no, the problem is WHAT is the IR
<shakesoda>
generating optimal code is what makes those kinds of things hard
Mulugruntz has quit [Quit: ZZZzzz…]
<pixelherodev>
We're designing said IR specifically for Zig.
<scientes>
and having more than one back-end for the same platform is not good for debuggability
<pixelherodev>
It won't be possible to target it with anything else (we're explicitly not supporting other people using it)
<pixelherodev>
scientes: what other backend are you talking about?
<shakesoda>
the only relevant backends here are different cpu architectures?
<pixelherodev>
yes
<scientes>
RIP Zig
<pixelherodev>
(CBE doesn't really count here)
<pixelherodev>
scientes: lol, why do you say that?
<scientes>
it will end up x86-only
<pixelherodev>
no, it won't.
<shakesoda>
um, no lol
<shakesoda>
first off lots of us use arm, second off, nobody said llvm is going away
<scientes>
or you will have both custom and llvm back-end for x86
<pixelherodev>
heh, just to prove the point, I'll add a SPU Mark II backend rn
<scientes>
which is the two backends problem
<pixelherodev>
neither of those is happening.
<fengb>
We also have a C backend
<pixelherodev>
LLVM support would probably be CBE | Clang, and not dedicated support
<companion_cube>
scientes: is it unrealistic to still have llvm and self hosted as backends?
<companion_cube>
I don't see why it wouldn't work
<companion_cube>
it's what D does
<scientes>
companion_cube, its possible, it is just that you have to handle all the custom stuff
<pixelherodev>
Yeah, that's kinda the *point* lol
casaca has joined #zig
<pixelherodev>
Actually, just to confirm
<pixelherodev>
ikskuh: you have no problem with me working on the SPU II backend, right?
<pixelherodev>
You don't want to do it yourself or anything?
<pixelherodev>
Silence will be taken as permission ;D
<fengb>
That's not exactly how contract laws work
<ikskuh>
pixelherodev: feel free
<pixelherodev>
fengb: clearly, it is :D
<pixelherodev>
ikskuh: Gladly :D
<pixelherodev>
I suppose that means adding it to CrossTarget
<leeward>
engb: What do you mean? Are you telling me that the tiny print on this thing that says "PRIOR TO USING <THING>, THE USER MUST REVIEW ... STANDARD TERMSAND[sic.] CONDITIONS FOR <THING>" isn't legally binding?
<leeward>
er, fengb ^
<companion_cube>
scientes: special stuff like simd, you mean?
<companion_cube>
having a custom backends for a bunch of architectures isn't that hard
<companion_cube>
what's hard is to reach the level of optimization of LLVM
<ikskuh>
<pixelherodev> I suppose that means adding it to CrossTarget
<ikskuh>
lol this is gonna be fun!
<pixelherodev>
yep
<pixelherodev>
First non-LLVM target in there, right? :D
<ikskuh>
i think so
dermetfan has quit [Ping timeout: 260 seconds]
<ikskuh>
i think i'll spec out the CPU today
<ikskuh>
there's only two things on the todo list: cpuid instruction and some "cpuctrl" instruction
<scientes>
why not just write to SSE2?
<scientes>
uggh
<scientes>
thinking about what a clusterfuck x86 is gives me a headache
<ikskuh>
scientes: enjoy the spu2 :)
<leeward>
Gotta love duplicated documentation, where in one place it tells you that the argument is ignored, and in the other place it doesn't tell you how to use it.
<pixelherodev>
scientes: what about SSE2?
<leeward>
And, special added bonus: it's not ignored.
<pixelherodev>
lool
<pixelherodev>
leeward: what's that from?
<leeward>
msp430-gcc
<pixelherodev>
lols.
layneson has joined #zig
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
_Vi has quit [Ping timeout: 272 seconds]
xackus has quit [Ping timeout: 258 seconds]
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
dermetfan has joined #zig
joey152 has joined #zig
joey152_ has joined #zig
joey152 has quit [Client Quit]
joey152_ has left #zig [#zig]
joey152_ has joined #zig
<Cadey>
andrewrk: congrats on the nonprofit
<andrewrk>
thanks! gonna be able to make showtime?
<andrewrk>
wait, are we both sponsoring each other?
decentpenguin has joined #zig
riba has joined #zig
joey152_ has quit [Remote host closed the connection]
joey152_ has joined #zig
layneson has quit [Ping timeout: 264 seconds]
dermetfan has quit [Remote host closed the connection]
dermetfan has joined #zig
<pixelherodev>
XD
cole-h has quit [Quit: Goodbye]
cole-h has joined #zig
_whitelogger has joined #zig
<marijnfs>
what's up in zigworld
<ikskuh>
andrewrk: i thought about that. when two people sponsor each other and github doubles the sponsoring…
<marijnfs>
did you remove llvm yet
<pixelherodev>
ikskuh: lol
<pixelherodev>
marijnfs: no :P
<marijnfs>
i saw some cool work there, zig could be the new llvm
<pixelherodev>
That's not happening, sorry
<leeward>
That seems...unlikely.
<pixelherodev>
Zig is focused on ZIg.
<leeward>
Also, not the goal.
<pixelherodev>
Zig*
<pixelherodev>
Yeah
<marijnfs>
not with that spirit
<shakesoda>
the zig level virtual machine
<marijnfs>
that would be fine too
<pixelherodev>
Our IR is for Zig only, for instance
<shakesoda>
how constraining actually is that, though
<marijnfs>
that's how llvm started
<marijnfs>
that's the vm
<pixelherodev>
ikskuh, andrewrk: any preference on how spu-ii should be named in std.Target.Arch?
<ifreund>
being llvm is not a sane goal or a good one
<shakesoda>
+1
<pixelherodev>
Is there a specific naming convention / typical way you refer to SPU II?
<pixelherodev>
Agreed
<shakesoda>
llvm is fine at being llvm
<pixelherodev>
LLVM is not what we want, at all.
<andrewrk>
marijnfs, yep, the self-hosted compiler so far has no llvm dependency
<andrewrk>
it's planned to be an optional dependency
<pixelherodev>
I'm still hoping I can convince Andrew that we don't even need it for that lol
<shakesoda>
the idea is that it will be for opt builds, right
<pixelherodev>
Or at least to make sure that we don't need it for anything other than optimizations even when it's optional
<andrewrk>
yeah, it would unlock llvm's optimization, and features such as translate-c and `zig cc`
<shakesoda>
those are all very valuable things
<pixelherodev>
I'm still wanting to work on a C frontend / semantic analysis :P
<ifreund>
pixelherodev: imo that shouldn't be a priority, not a great cost/benefit ratio when there is still so much else to do
<pixelherodev>
I'm well aware.
<pixelherodev>
*I* want it
<pixelherodev>
But I also recognize it's not worth it to the Zig community at large
<pixelherodev>
And you all come first ;)
<ifreund>
<3
<pixelherodev>
That's why I'm working on SPU II backend, for instance
<pixelherodev>
Helps test our current design and find shortcomings
<ifreund>
I kinda want to try my hand at implementing a backend at some point in the far future, never done any codegen before
<companion_cube>
maybe someone should do a bytecode interpreter, too
<companion_cube>
for comptime :p
<ikskuh>
<pixelherodev> Is there a specific naming convention / typical way you refer to SPU II?
<ikskuh>
i'd prefer spu-2
decentpenguin has quit [Quit: decentpenguin]
CommunistWolf is now known as Purity
Purity is now known as CommunistWolf
<pixelherodev>
ikskuh: is - valid in Zig identifiers?
<pixelherodev>
nope
<pixelherodev>
spu_2? spu_ii
<pixelherodev>
?
<ikskuh>
spu_2
<pixelherodev>
Okay
riba has quit [Ping timeout: 272 seconds]
dingenskirchen has quit [Read error: Connection reset by peer]
dingenskirchen has joined #zig
ur5us has joined #zig
layneson has joined #zig
<ikskuh>
pixelherodev: i could do the stupid…
<ikskuh>
latest document revision of spu mark ii spec is 1.9
<ikskuh>
updating it would be 1.10 or 2.0 :D
marijnfs_ has joined #zig
dermetfan has quit [Ping timeout: 260 seconds]
<pixelherodev>
2.0 pls :P
marijnfs has quit [Ping timeout: 264 seconds]
<ikskuh>
nah
<leeward>
1.9 plus minor rev is 1.10
<ikskuh>
lemmi: you can't tell me how to version my CPU! :D
<ikskuh>
*leeward
<ikskuh>
there will definitly be a .11 and .12 though
<leeward>
ikskuh: I can't, but I can tell you what is a sensible versioning scheme that won't cause major confusion.
<ikskuh>
using only pow2s:
<ikskuh>
1 2 4 8 16 32
<fengb>
Yes but only list the exponent value
<leeward>
Don't you mean, 1 10 100 1000 10000?
<ifreund>
1.a
<shakesoda>
scientific notation for sure
<shakesoda>
maybe really mix it up and do it in a strange base
<ifreund>
once you get to 1.z you can rethink things
<ikskuh>
Version 1e4
<ikskuh>
next minor release is 2e4, next major release is 1e5
<ifreund>
and don't skip 1.ö
<fengb>
Followed by 1f4
<ikskuh>
1.ß
<shakesoda>
now this is a spicy versioning scheme
<shakesoda>
i am in full support
<ikskuh>
version = unicode codepoint
<shakesoda>
i like how this would mean you have nonprintable version numbers
<leeward>
Every point release is an extra diacritic.
dermetfan has joined #zig
<shakesoda>
ah yes, version ̶̛̳͓̳̌̑͂̈́͆̐̅͝
<shakesoda>
not to be confused with version ̶̛̛̫̼̭̞̫̳͚̹̼͉̥̦͉̱̹̞̮̳̥̽̊̇̋̈́͂̌̈́̌͐̍́̑̚͝, which came much later