<daurnimator>
andrewrk: want me to make an application?
<daurnimator>
and if so, do you want to be the primary contact? or should I put myself?
bjorob has quit [Ping timeout: 265 seconds]
kllr_sbstn has quit [Quit: leaving]
lunamn_ has quit [Quit: leaving]
ntgg has joined #zig
<pixelherodev>
daurnimator, I *know*
<pixelherodev>
If you've got one, let me know :P
<pixelherodev>
andrewrk, there *is* an interrupt for illegal instruction (that's how the OS implements it), but you're almost certainly correct that it's platform dependent
<saskwach>
Just use HCF.
<saskwach>
That exists on most platforms, right?
Ichorio has quit [Ping timeout: 264 seconds]
<saskwach>
andrewrk, I looked at sieve2, and it's pretty different from mine. Aside from the fact that I used tricks like only filling up to the square root of the sieve's size, mine's more OO-ish, and I made an iterator.
<saskwach>
Oh, and I special cased 2 and packed my array with only odd numbers.
<saskwach>
I feel like those 4 lines of setup for getting a buffered stdout stream ought to be wrapped in a single standard library call.
<saskwach>
Oh wow, I misread sieve2. That's very very different. That's not even the sieve of eratosthenes.
clktmr has quit [Ping timeout: 245 seconds]
<saskwach>
For an example of something that will actually demonstrate concurrency well, a simple socket server might do. Each connection needs its own context, but individual threads spend most of their time waiting. If you're looking for a parallel compute load, something like a bitcoin miner (though obviously not a real one) that breaks a search space up into N chunks and has each parallel process just chug through might be a good way to go.
<saskwach>
See also: password crackers.
<daurnimator>
pixelherodev: even just "My experience with programming languages and why I've started writing a hobby kernel in zig"
<daurnimator>
pixelherodev: something that at least gives a clue when e.g. submitted to hackernews
<saskwach>
error: expected type '*Sieve', found '*Sieve'
<pixelherodev>
How about "Why Zig is the greatest of all time, awed are all in the presence of its majesty?"
<pixelherodev>
:P
<saskwach>
Definitely a credible title. Not clickbaity or likely to lead to flames at all.
<pixelherodev>
... that's not convincing me *not* to use it :D
return0e_ has quit [Remote host closed the connection]
mahmudov has quit [Remote host closed the connection]
<andrewrk>
daurnimator, too soon, in my opinion. bugs found with fuzzing would all be lowest priority bugs
<andrewrk>
once we're shipping self-hosted I'll be interested in fuzzing
doublex has quit [Ping timeout: 264 seconds]
doublex has joined #zig
<saskwach>
Fuzzing C++ code is basically guaranteed to find bugs, and lots of them.
<saskwach>
daurnimator, I figured out what I was doing that was preventing me from writing to the struct's array member.
<saskwach>
It's generic-ish, so the type is returned by a function.
<daurnimator>
saskwach: you need `self: *Self` instead.
<saskwach>
ahh
<saskwach>
thanks
<daurnimator>
saskwach: return struct by value should be optimized well; that's result location (which needs more docs)
<muffindrake>
@embedFile says "This function returns a compile time constant fixed-size array with length equal to the byte count of the file given by path.", but its return type is [X]u8, i.e. no const here. Clarification?
<muffindrake>
Just the array size is fixed, _not_ the actual contents of the array itself, no?
<muffindrake>
At least that's how I'm going to read 'compile time constant'
<pixelherodev>
`constant` and `fixed-size` are both specified there muffindrake
<pixelherodev>
Implication is that `constant` has nothing to do with size
<pixelherodev>
Still, that's interesting
<pixelherodev>
`compile-time constant` implies to me that it returns `comptime []const u8`,but that's not what's specified...
<telemach>
pixelherodev: you mentioned disabling SSE for freestanding mode
<telemach>
why so? (sorry for naive question, i know nothing about writing kernels)
<telemach>
i mean, what's wrong with using SSE in freestanding mode? if SSE means SSE instruction
<telemach>
*instructions
<pixelherodev>
SSE instructions aren't valid until SSE is enabled *within the kernel*
<pixelherodev>
Similarly, if you look at my kernel, you'll note that one of the first things it does is enable the FPU (Floating Point Unit) - until that's done, using floats crashes the system
<pixelherodev>
Basically, CPUs didn't originally have SSE
<pixelherodev>
So the kernel has to detect SSE and enable it manually if the CPU it's running on supports it
<pixelherodev>
If SSE instructions run before that's done, it effectively crashes the CPU
chemist69 has quit [Ping timeout: 276 seconds]
chemist69 has joined #zig
<muffindrake>
Wasn't usage of floating point in bare met- damnit
<pixelherodev>
?
<muffindrake>
Chat scrolling woes. I didn't ee the newer ones until too late.
<telemach>
oh wow, thanks for explanation, i naively thought that such old things like FPU and SSE are on by default on modern CPUs
<muffindrake>
Some answers on stackoverflow attempt to outline the reasons why floating point is rarely done freestanding, with the example of the linux kernel
<pixelherodev>
... yeahhhhh I could definitely easily avoid the FPU ops I'm doing
<pixelherodev>
Literally only two FPU calls, both are in the timer interrupt
<pixelherodev>
Rather, both are in the *timer*; the as_ms function takes a number of timer ticks and converts to ms based on frequency (which is calculated as f64 at comptime)
<telemach>
how do you calculate frequency at comptime?
<telemach>
or is it just your timer freq, not CPU clock?
<pixelherodev>
Yeah
<pixelherodev>
Basically, the timer frequency is set by a *divisor*
<pixelherodev>
So I have three constants: target frequency, divisor, real frequency
<pixelherodev>
Divisor is calculated from target frequency, real frequency is calculated from divisor
ltriant has quit [Ping timeout: 268 seconds]
<saskwach>
I've used whole systems that didn't support floating point at all. It's not a huge loss in most embedded contexts.
saskwach has quit [Quit: Leaving]
ltriant has joined #zig
ltriant has quit [Ping timeout: 276 seconds]
hspak has quit [Ping timeout: 276 seconds]
hspak has joined #zig
<daurnimator>
Something zig probably does need though is knowledge of fpu state
<daurnimator>
1. so I can change e.g. rounding modes and have comptime code do the right thing
<daurnimator>
2. I should be able to annotate functions with their expected fpu modes
hspak has quit [Ping timeout: 245 seconds]
hspak has joined #zig
bjorob has joined #zig
ltriant has joined #zig
ltriant has quit [Ping timeout: 265 seconds]
Ichorio has joined #zig
Ichorio has quit [Ping timeout: 264 seconds]
riba has joined #zig
ltriant has joined #zig
ltriant has quit [Ping timeout: 246 seconds]
soveran has joined #zig
soveran has quit [Remote host closed the connection]
soveran has joined #zig
jjido has joined #zig
telemach has quit [Ping timeout: 240 seconds]
soveran has quit [Remote host closed the connection]
chemist69 has quit [Quit: WeeChat 2.6]
ltriant has joined #zig
dimenus has quit [Read error: Connection reset by peer]
dimenus has joined #zig
ltriant has quit [Ping timeout: 276 seconds]
chemist69 has joined #zig
<Snektron>
Wasnt there a @setRoundingMode
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dimenus has quit [Read error: Connection reset by peer]
dimenus has joined #zig
<daurnimator>
andrewrk: stream this week?
soveran has joined #zig
dimenus88 has joined #zig
ManDeJan has joined #zig
ManDeJan has quit [Ping timeout: 268 seconds]
jjido has joined #zig
dantix_ has joined #zig
dantix_ has quit [Client Quit]
dantix_ has joined #zig
dantix_ has quit [Client Quit]
soveran has quit [Remote host closed the connection]
ltriant has joined #zig
ltriant has quit [Ping timeout: 268 seconds]
soveran has joined #zig
<dimenus88>
andrewrk: i'm working on the vector array indexing commit and it looks clean, but I created an additional test that replicates the failure I get in his full PR as well
<nrdmn>
are `type`, `comptime_int` and `comptime_float` zero bit types?
<andrewrk>
nrdmn, yes
<andrewrk>
"0 bit types" should be "0 runtime-bits types"
<dimenus88>
andrewrk: I only merged that particular commit into master and started working on this test
<andrewrk>
ah, yeah that's as far as I got too
<andrewrk>
then it sort of felt like just doing the implementation myself would be easier than trying to merge it
<dimenus88>
I don't know the compiler well enough to free hand that
<dimenus88>
any chance you could take a look at my broken test?
<nrdmn>
can I have packed arrays of bits?
oats is now known as otz
dingenskirchen has joined #zig
doublex has joined #zig
doublex has quit [Read error: Connection reset by peer]
doublex has joined #zig
doublex has quit [Read error: Connection reset by peer]
doublex has joined #zig
doublex has quit [Ping timeout: 264 seconds]
FireFox317 has joined #zig
doublex has joined #zig
ntgg has joined #zig
dingenskirchen has quit [Quit: dingenskirchen]
ltriant has joined #zig
soveran has quit [Remote host closed the connection]
ltriant has quit [Ping timeout: 250 seconds]
wootehfoot has joined #zig
ntgg has quit [Ping timeout: 252 seconds]
dimenus88 is now known as dimenus|work
<nrdmn>
andrewrk: If i remember correctly it is possible to compile some functions as ReleaseSafe and others as ReleaseFast within the same application
<leeward>
Does anyone know if there's an LLVM bitcode frontend for GCC?
<andrewrk>
that's an interesting idea
ntgg has quit [Ping timeout: 268 seconds]
doublex has quit [Ping timeout: 268 seconds]
<leeward>
It would help with the number of supported targets. Zig looks like a great language for embedded software, but LLVM really doesn't target many architectures.
<pixelherodev>
What's easier to retarget: LLVM or GCC?
jjido has joined #zig
<leeward>
What do you mean by retarget?
<leeward>
There's a project called dragonegg that uses LLVM to compile GCC IR.
<pixelherodev>
Add a new backend for
return0e_ has joined #zig
<leeward>
I've never done it, but I get the sense that LLVM is designed to be easier to add backends.
<leeward>
Of course, many more GCC backends already exist.
jjido has quit [Client Quit]
<pixelherodev>
I tried to read through the LLVM docs regarding adding a backend a few weeks ago. There's *so much there*.
<pixelherodev>
I get the feeling that if you've done it once it's easy to do, but learning enough about the system to actually do it is a pain
<leeward>
Thus the question. If I want to write code for, say, xap or mips or avr, there's a GCC compiler for that.
<pixelherodev>
Actually, LLVM supports AVR now (experimentally though)
<leeward>
Yeah, supports experimentally is not the same as supports.
<pixelherodev>
That's true
<leeward>
I'm all for supporting the effort, but there's just so much that already exists.
<waleee-cl>
isn't there a mips backend in LLVM?
<leeward>
Tilera, for example.
<leeward>
Maybe?
<pixelherodev>
Yeah, there is
<pixelherodev>
(According to a quick look at the LLVM_TARGETS USE_EXPAND flag on Gentoo)
<leeward>
It would be cool to make, for example, arduino in Zig. Not gonna happen while avr support is experimental.
<leeward>
Though I've also seen it on an actual Linux box.
<andrewrk>
WSL! I was going to say, the logic looks fine, this seems like the kernel doing something wrong
<leeward>
I'm almost certain I reproduced this on my Linux box at home. Maybe I'm misremembering.
<andrewrk>
leeward, do those values discovered with gdb agree with `readelf -e` on the elf file?
<andrewrk>
oh, it looks like the logic is trying to figure out the base address based on LOAD program headers. but there can be more than one. maybe we can check whether the value is sane before using it to compute `base`
<andrewrk>
it looks like musl has this same logic as the zig code that is triggering an integer overflow
ltriant has joined #zig
<leeward>
andrewrk: What am I looking for in readelf?
<andrewrk>
the Program Headers table
<andrewrk>
the vdso logic has this information and needs to figure out the base address
<leeward>
Not really. I don't see any numbers under Program Headers that look at all like the addresses from gdb.
<leeward>
Just the arrow though. Get rid of the <- and it's good
sossy has joined #zig
lunamn has joined #zig
doublex has joined #zig
ManDeJan has joined #zig
doublex has quit [Read error: Connection reset by peer]
ntgg has quit [Ping timeout: 240 seconds]
ky0ko has quit [Ping timeout: 264 seconds]
return0e has quit [Remote host closed the connection]
ltriant has joined #zig
doublex has joined #zig
<pixelherodev>
If you have a local array (not allocated via an std.mem.Allocator) and you return a slice of it, is that valid?
<leeward>
Wouldn't that be a pointer to stack?
<pixelherodev>
I'd think so, but it seems to *work*
<pixelherodev>
I mean
<pixelherodev>
I'm not returning a pointer
<pixelherodev>
Returning a *slice*
<pixelherodev>
Hence the question
<pixelherodev>
My guess is it gets returned via the stack?
<pixelherodev>
Mostly concerned now because I plan on having a function that can theoretically return a slice of millions of u8s
doublex has quit [Ping timeout: 240 seconds]
doublex has joined #zig
doublex has quit [Ping timeout: 250 seconds]
ManDeJan has quit [Ping timeout: 276 seconds]
<fengb>
No, the slice is just a fat pointer into the stack memory space that’ll get overwritten
<leeward>
Yeah, I've been poking at a toy that supports that.
<leeward>
No errors though, which is unfortunate.
kenaryn has joined #zig
<fengb>
There's a task to detect dangling pointers to stack space, but it's not there yet
doublex has joined #zig
<kenaryn>
Hello, please how can I write into a file instead of standard output? I did not see an example in the official documentation
<pixelherodev>
fengb, thanks!
<fengb>
pixelherodev: it seems to work because the program hasn't unmapped or reused the space yet. But it's almost guaranteed to corrupt on a function call
<fengb>
Slices are really just pointers underneath the covers. It only points at data, but it never is the real data