<riverdc>
what I really want to do is implement a compiler and skip C entirely at this point, but I'm nowhere near being able to use that in practice
<riverdc>
kingoffrance: I was watching a video that Sean Barrett (author of stb libraries) uploaded on this (using C as codegen output) recently, you might find it interesting
<klange>
2+ minutes to install gcc is _not great_, but it works and seems to be stable _and_ I can actually use the system just fine while it's pumping out writes
<klange>
Just need to fix up the little bugs on the ext2 side of things, and maybe we can bang out an installer...
<moon-child>
riverdc: for games, unless you have very many entity types, better to transpose your representation so you can hoist your dispatches
<moon-child>
better branch prediction that way
<riverdc>
I'm not sure what you mean by hoisting dispatches
<moon-child>
like, instead of saying (T|U)[] all_entities; match for each x in all_entities: |T -> render_t(x); |U -> render_u(x)
<moon-child>
say: T all_ts; U all_us; for each x in all_ts: render_t(x); for each x in all_us: render_u(x)
<riverdc>
so basically AoS instead of SoA?
<moon-child>
sure, yeah
<moon-child>
aos/soa is one way of expressing a transpose. Ditto row/column dbs
<moon-child>
if you want to express an entity pointer heterogeneously, you do need a discriminant there. But you can skip it for core 'iterate over all entities'
<riverdc>
yeah, I agree. one of the things I'm thinking about for the toy language I'm working on is being able to express transposition at compile time without having to restructure everything
<moon-child>
oh, heh, video you linked talks about that. sean says 'the way the guy was proposing to me that he was doing things was he was keeping a seperate vector for every single type he had'
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
dutch has quit [Quit: WeeChat 3.3]
dutch has joined #osdev
freakazoid12345 has quit [Read error: Connection reset by peer]
<kazinsal>
klange: Didn't know your text editor had a render-file-with-highlighting-to-console option. That's pretty neat!
<moon-child>
I think vim has that too
<moon-child>
there's a context package to use vim for syntax highlighting
<junon>
Vim has something that renders out the buffer with the configured colors to an HTML document.
<bslsk05>
github.com: bim/vi-to-bim.md at master · klange/bim · GitHub
<moon-child>
oh cute, the indentation is first-class
<moon-child>
(I hate it personally, but it's a cool feature)
<klange>
The choice of display characters is configurable.
<moon-child>
I mean in the html. The indentation bits aren't selectable
<klange>
They are but you aren't seeing it.
<klange>
It's CSS wizardry so the actual text of the document is correct.
<moon-child>
ah, even cuter! :)
* klange
tries to update that dump
<klange>
okay there we go now it's the latest version and doesn't randomly stop syntax highlighting a hundred lines before the end
* moon-child
doesn't understand how people can work on such large files
<moon-child>
s7 is even worse, 100k lines I think
<klange>
Heh, it's an intentional stress test for itself at this stage :)
<moon-child>
:)
<klange>
Started as just a quirk of the build system I have set up for ToaruOS, which was "one source file per binary" - fine for the little utilities.
<klange>
Compositor stretched the viability a bit, but it's only 3k lines. The editor ballooned as it went from a toy to the thing I actually use on a daily basis...
<klange>
And at one point I did step back and look at breaking out, but I gave up :) at least the syntax highlighters and themes are separate now (they're Kuroko scripts)
srjek has joined #osdev
<klange>
Shell, file browser, terminal, and compositor are all under 3k lines... and then there's Bim at 12k.
<klange>
Kuroko totals around 17k in its C sources, but it has its own project structure checked out as a submodule.
heat has joined #osdev
<heat>
geist, don't you need libgcc/compiler-rt for constructor stuff? or does .init_array bypass that nicely as well?
<heat>
i know _init is all libgcc
<geist>
The latter
X-Scale has quit [Ping timeout: 256 seconds]
X-Scale` has joined #osdev
X-Scale` is now known as X-Scale
<heat>
i see some archs in linux include libgcc
<heat>
i guess I could do that in 32-bit archs
<heat>
the biggest issue is really 64-bit divide, I really don't want to replace every divide with div_u64 or something
<heat>
and I'd like for some possible portability to 32-bit architectures in the future, if I so desire
<moon-child>
heat: you want to avoid linking in libgcc?
<heat>
for x86_64 at least, yeah
<moon-child>
why?
<heat>
multilib for the kernel is hacky
<heat>
and it's not really called I guess
<moon-child>
you want ... multilib
<heat>
?
<moon-child>
'not really called' --gc-sections or some such?
<moon-child>
anywaay re 64-bit divide you could implement it yourself and call it by whatever name gcc emits. I think I did that for one of the int128 things once
<heat>
gc-sections is all linker
<moon-child>
yeah. So you link in libgcc and then it gets rid of all the bits of it you don't use
<heat>
that's not the issue
<heat>
my issue is purely a logistical/sanity one, I'm maintaining a multilib in gcc for my kernel (and *every* gcc library needs to be built 3 times because of it, even stdc++), something that no-one does
<heat>
also, I'm not sure it's even possible in clang
freakazoid343 has joined #osdev
<geist>
think is most arches that aren't x86-64 dont really have a problem using a 'regular' libgcc for the kernel (in my experience)
<geist>
so for LK I always link in libgcc for all arches, and only on x86-64 do you need the no-red-zone version
<geist>
but in practice it's mostly 32bit arches, and especialyl 32bit risc arches that need lots of assist from libgcc
<klange>
I don't seem to actually be getting anything out of libgcc on my x86-64 kernel build.
<geist>
yeah, LK has more regular code in the kernel
<moon-child>
not so 'little', neh? :)
<heat>
geist, do you require a no-red-zone libgcc for lk?
<geist>
well, it's embedded, so you can also write your regular code in it
<geist>
heat: yes. for x86-64
<geist>
but then i have my own toolchain with my own patch for it
<bslsk05>
github.com: toolchains/gcc-patch.txt at master · travisg/toolchains · GitHub
<heat>
yeah I have one like it too
<klange>
I was so happy to get libgcc_s.so working...
<heat>
but I need an mcmodel variant too, else it doesn't link
<geist>
hmm, i wonder how i get away with that in LK, I dont explicitly call out a mcmodel variant for the kernel
<geist>
I mean i use -mcmodel=kernel but I dont explicitly build a multilib variant of libgcc for it
<heat>
might happen to work if you don't bring in crtbegin/end
<heat>
so you never really use libgcc lol
<geist>
yah
<geist>
but i thought there was codegen differences though, with how it extends pointers, etc
<geist>
possible it is just playing with fire. honestly I dont do much work on x86. the x86 port is mostly there to run tests on a x86 host in a VM quickly
diamondbond has joined #osdev
<clever>
one case where ive run into trouble by not having a multi-lib libgcc, was the rpi pico
<clever>
multi-lib enables things like a thumb and arm32 build of libgcc.a
<geist>
yah
<clever>
and without multilib, the linker will just throw an arm32 libgcc.a into your binary, and when your cpu is thumb only, that wont end well
<geist>
bein an 'murcan i dont know nothing that aint 7 bit ascii
<kazinsal>
means that someone on the forums is one day going to have to debug someone's error messages in catalan
<geist>
but isn't that desirable?
<geist>
not for the debugginb, but for the user
<klange>
it's a mixed bag
<kazinsal>
yeah, it's good UX
<klange>
it's terrible for being able to search the interwebs for relevant info
<kazinsal>
true
<heat>
or ask for help
<geist>
word.
<geist>
well, i solved that problem by not having my own forum and never checking The Forum
<geist>
but yeah, that's a good question: can add a switch to the toolchain builder maybe
<geist>
most likely something like --disable-nls on the ./configure i guess
mahmutov has quit [Ping timeout: 268 seconds]
<heat>
i'm thinking about having a scripted 2-stage toolchain build without a sysroot
<heat>
i would stop needing a prebuilt tarball
<heat>
otoh, very slow
<klange>
I'm still trying to get my "toolchain" down to just gcc and binutils... still have an awkward Python dependency for my ramdisks.
<heat>
isn't kuroko similar enough'
<heat>
?
<klange>
The awkward bit is that I use Python's tarfile module to produce controlled, compressed tarballs.
<heat>
ah
<klange>
I don't have a gzip compressor of my own yet... and I also don't have a tar far _producer_ yet, just an extractor...
<klange>
tar file*
[itchyjunk] has joined #osdev
<klange>
Hm, I should probably just remove -lgcc from this Makefile for the kernel so if I _do_ accidentally introduce a libgcc dependency I will know quickly instead of discover it after an agonizing debug session of why a stack has been corrupted by an interrupt...
<klange>
I know my userspace needs it for similar things to what heat was saying earlier about constructors or whatever, even without C++. Just shared lib stuff in general. Good thing my modules are relocatable objects!
<klange>
I am counting blocks wrong (I think I'm forgetting to include the indirect blocks?) and something's very wrong with directories
<heat>
no worse feeling than that
<zid>
flawless
<klange>
I think all the unattached inodes are the files in /usr/lib/gcc/x86_64-pc-toaru/10.3.0/plugin/include/ that got dropped
<geist>
maybe forgot to mark them unallocated in the inode bitmap?
<geist>
there is an inode bitmap right?
<heat>
a few weeks ago I found out I wasn't filtering out device files and symlinks when freeing inode space
<heat>
it just freed random blocks
<klange>
I think it's that I made inodes for the files but failed to add them to the directory, as I recall having a problem with directories with "too many" entries
<heat>
whatever garbage was in i_data
<zid>
sounds like this should be relatively easy to find issues with at least
<zid>
start with a known good fs, do a couple of ops, make sure it's still good, repeat
<zid>
given how much garbage it's spewing it can't be hard!
<heat>
what if it only corrupts the fs under load?
<zid>
Then I feel sorry for klange
<heat>
filesystems are hard :(
<heat>
is there a way to get access to an interactive macOS shell without, erm, having a mac?
<heat>
i'd like to have my OS buildable in macOS but debugging through github actions logs isn't easy lol
cr1901 has joined #osdev
<klange>
You could probably do a reverse shell off the CI to your local machine, but github might not like that.
cr1901 has left #osdev [Leaving]
srjek has quit [Ping timeout: 250 seconds]
<wleslie>
pretty sure aws can rent you a macOS instance
<wleslie>
on how I learned to get over it and just use the cloud for development: I used to always buy overspecced machines, mostly because I was doing really out there static analysis work (think 100 GB+ datalog databases)
<wleslie>
I eventually realised that rather than spend several thousand on an overspecced machine that would mostly be going to waste, instead spend $2 to borrow a machine with +150GB of ram on the cloud for an hour or two
<zid>
we're back to mainframe timeshares ;)
zaquest has quit [Quit: Leaving]
zaquest has joined #osdev
smeso has quit [Quit: smeso]
smeso has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
ElectronApps has joined #osdev
nyah has quit [Ping timeout: 264 seconds]
<kingoffrance>
not just that quote: I bet some kids in 10 years are going to start designing things with bloody mailboxes ;) because of the rpi
<kingoffrance>
https://en.wikipedia.org/wiki/Convergent_Technologies_Operating_System Each client consumes the services via its own mailbox called "exchange" and well-published message formats. The communication works on "request codes" that are owned by the service. The operating system maintains the exchanges, message queues, scheduling, control, message passing, etc., while the service manages the messages at its own exchange using "wait", "check", and "re
<kingoffrance>
spond" macros.
<bslsk05>
en.wikipedia.org: Convergent Technologies Operating System - Wikipedia
<kingoffrance>
in 1980 again :p
<kingoffrance>
*it is
<heat>
why are macOS binutils+gcc builds so much smaller than linux ones?
<heat>
zstd says 268MB vs 900MB
<heat>
exact same target, of course
<zid>
using their libc or yours?
<heat>
they're both dynamically linked builds of the same toolchain for the same target, using the same sysroot (so you can't blame my OS's sysroot)
<zid>
is the linux one including half of glibc inlined 80000 times, and the other one maybe linked to mac's crt dynamically, for example
<heat>
fairly sure you can't inline through dynamic libraries
<heat>
also, no lto
<zid>
well I'm out of obvious guesses then, it's statistics time
<zid>
which binaries are bigger and by how much
doppler has quit [Ping timeout: 256 seconds]
elderK has quit [Quit: Connection closed for inactivity]
xenos1984 has quit [Quit: Leaving.]
<kingoffrance>
how about debugging info
<heat>
cc1, cc1plus, etc are way way bigger in linux
<kingoffrance>
copy them and strip :D
<heat>
it's still a shared library though?
<kingoffrance>
im just guessing, but do it
<heat>
wait what
<heat>
why are they not fucking stripped
<zid>
splitdebug for life
<heat>
WHY IS THE RELEASE BUILD NOT STRIPPED
<heat>
????
<zid>
because it never gets loaded into memory?
<Affliction>
heat | fairly sure you can't inline through dynamic libraries
<Affliction>
hmm... store compiler IR in the file, link at load time?
<zid>
inlined strlen absolutely destroyed valgrind for a while until all the distros and valgrind and gcc all worked on it :P
<heat>
oh fuck off, I need to do make install-strip
<heat>
this is
<heat>
bullshit
<Affliction>
absolutely wouldn't want to use that for small utilities, but it might be usable for long running programs?
<zid>
those are builtins not true inlines though
<Affliction>
oh right, it exists, we call it "JIT"
<Affliction>
woohoo, reinventing the wheel
<heat>
aot for lyfe
<zid>
I should remake my VM probably on a bigger disk now I have some extra storage
<zid>
my debug symbols are up to like 20GB
<zid>
gentoo has a system wide splitdebug compressdebug -nostrip setting that's super nice, everything ends up in /usr/lib64/debug/usr/bin/blah.debug
<zid>
and gdb will pick them up as the original symbols, even though /usr/bin/blah is 'stripped'
heat has quit [Ping timeout: 265 seconds]
doppler has joined #osdev
sm2n_ has joined #osdev
brynet has quit [Ping timeout: 268 seconds]
sm2n has quit [Read error: Connection reset by peer]
brynet has joined #osdev
ravan_ has joined #osdev
ravan__ has quit [Ping timeout: 257 seconds]
xenos1984 has joined #osdev
xenos1984 has quit [Client Quit]
xenos1984 has joined #osdev
GeDaMo has joined #osdev
<geist>
heat: re stripping my toolchain script strips afterwards for exactly this reason
<zid>
-fwhole-program ;)
<geist>
inded, though i'd tend to think that proper LTO is in every way better than -fwhole-program
<geist>
i'd think at least
<geist>
maybe it ends up with some more visibility though. i'll ask toolchain folks at work tomorrow
bauen1 has quit [Ping timeout: 250 seconds]
<zid>
-fwhole-program is just a lot simpler than manually marking things hidden
<zid>
if you're building a final executable you can basically just toss every symbol and every implementation of said symbol
<zid>
fairly easy to show on godbolt or such that if you do int f(void ) { .. } int main(void) { f(); }; then it will both inline f into main, and leave a copy of the definition of f() in case someone externally calls it
<zid>
In GCC, the whole program option (-fwhole-program) asserts that every function and variable defined in the current compilation unit is static, except for function main (note: at link time, the current unit is the union of all objects compiled with LTO).
<zid>
So it basically just automates marking every symbol other tham main as __attribute__((visibility=hidden)) or whatever that syntax is
ravan_ is now known as ravan
dormito has quit [Quit: WeeChat 3.3]
bauen1 has joined #osdev
scoobydoo has joined #osdev
<klange>
Stopped mounting a tmpfs to /var and the package system is surviving reboots correctly. There's some stuff I put in there that probably needs to stay as a tmpfs, like /var/run, but I'll look at that later...
elastic_dog has quit [Ping timeout: 250 seconds]
elastic_dog has joined #osdev
nyah has joined #osdev
<gog>
nyaaaa
* kazinsal
headpats
* gog
purrs
<graphitemaster>
Is there a way to trick configure into passing an ac test when you invoke it without modifying the configure script
<klange>
graphitemaster: set the cache variable for the test
dormito has joined #osdev
<graphitemaster>
How do you do that
<klange>
Same as you would set any other configure variable, `./configure ac_cv_whatever=yes`
<klange>
If you don't know what the cv name is, perusal of either the log of a previous run, the script itself, or the ac source script should help.
<graphitemaster>
Thanks
dormito has quit [Ping timeout: 260 seconds]
eschaton has quit [Remote host closed the connection]
dormito has joined #osdev
diamondbond has joined #osdev
X-Scale has quit [Ping timeout: 250 seconds]
X-Scale` has joined #osdev
X-Scale` is now known as X-Scale
ahalaney has joined #osdev
diamondbond has quit [Ping timeout: 260 seconds]
diamondbond has joined #osdev
[itchyjunk] has joined #osdev
diamondbond has quit [Ping timeout: 256 seconds]
dennis95 has joined #osdev
dude12312414 has joined #osdev
dude12312414 has quit [Client Quit]
myon98 has quit [Quit: Bouncer maintainance...]
dra has joined #osdev
nyah has quit [Quit: leaving]
kingoffrance has quit [Ping timeout: 240 seconds]
_eryjus has joined #osdev
eryjus has quit [Ping timeout: 265 seconds]
myon98 has joined #osdev
nvmd has joined #osdev
bauen1 has quit [Ping timeout: 265 seconds]
srjek has joined #osdev
dra has quit [Ping timeout: 265 seconds]
richbridger has quit [Remote host closed the connection]
richbridger has joined #osdev
lg has quit [Ping timeout: 265 seconds]
gog has quit []
gog has joined #osdev
gog has quit [Ping timeout: 250 seconds]
gog has joined #osdev
gareppa has joined #osdev
lg has joined #osdev
gareppa has quit [Quit: Leaving]
bauen1 has joined #osdev
ElectronApps has quit [Remote host closed the connection]
m3a has quit [Ping timeout: 264 seconds]
pretty_dumm_guy has joined #osdev
ravan_ has joined #osdev
ravan has quit [Ping timeout: 265 seconds]
dormito has quit [Ping timeout: 265 seconds]
nshp has joined #osdev
[itchyjunk] has quit [Quit: Leaving]
isaacwoods has joined #osdev
dormito has joined #osdev
srjek has quit [Ping timeout: 250 seconds]
srjek has joined #osdev
srjek has quit [Ping timeout: 264 seconds]
dennis95 has quit [Quit: Leaving]
srjek has joined #osdev
xenos1984 has quit [Quit: Leaving.]
m3a has joined #osdev
sprock has quit [Ping timeout: 250 seconds]
kingoffrance has joined #osdev
vdamewood has joined #osdev
thaumavorio_ has quit [Ping timeout: 260 seconds]
dragestil_ has joined #osdev
dragestil has quit [Ping timeout: 246 seconds]
dragestil_ is now known as dragestil
thaumavorio has joined #osdev
xenos1984 has joined #osdev
Vercas has quit [Remote host closed the connection]
Vercas2 has joined #osdev
srjek has quit [Ping timeout: 268 seconds]
nyah has joined #osdev
Oli has joined #osdev
kpel has quit [Quit: leaving]
kpel has joined #osdev
GeDaMo has quit [Remote host closed the connection]