heat has quit [Read error: Connection reset by peer]
innegatives has quit [Quit: WeeChat 3.8]
heat_ has quit [Remote host closed the connection]
heat_ has joined #osdev
pog has quit [Ping timeout: 250 seconds]
DynamiteDan has quit [Excess Flood]
DynamiteDan has joined #osdev
DynamiteDan has quit [Excess Flood]
DynamiteDan has joined #osdev
Matt|home has quit [Quit: Leaving]
Arthuria has joined #osdev
<junon>
Okay so next issue is that there are still relocations in my ELF - namely R_X86_64_RELATIVE in the .data (PROGBITS) sections. This is why a lot of my static strings are pointing to null pointers. Is there a reason the linker isn't just performing those relocations itself when it links the executable? Or is it common to have to do relocations whenever you load a static ELF? Is there a way to make the linker bake these into the executable itself and essentially clear
<junon>
out the relocations?
<klange>
How are you invoking the linker? If you still have relocations in an executable, you probably built it with PIE.
hmmmmm has joined #osdev
<heat_>
_RELATIVE only pops up when you're compiling with PIE or PIC. these are supposed to get resolved at runtime, once you know your relocated base address
<heat_>
you're probably not supposed to get this in your kernel though :v (except for very advanced cases)
<heat_>
are you using a cross compiler?
<junon>
Thaaaaank you. :) I remember that I enabled PIE for a specific reason, I think for KASLR?
<junon>
Anyway disabling PIE indeed removed them.
<junon>
So do KASLR enabled kernels then always perform relocations?
hmmmm has quit [Ping timeout: 240 seconds]
<heat_>
it depends on what KASLR you're talking about
<heat_>
virtual KASLR? yes
<heat_>
physical KASLR? no, you don't need to
<junon>
virtual KASLR, yes.
<klange>
Usually you have a bit of shim code that is fully position-independent and does the relocations
<klange>
Or you have a loader that does it for you.
<heat_>
virtual KASLR always needs to relocate, but you don't need to use fPIE for this
<heat_>
and indeed AFAIK linux does not, they use regular relocations
<junon>
how do you do KASLR without fPIE? doesn't your codegen need to account for that, to use relative jumps?
<heat_>
well, you re-relocate everything with the linker relocs
<heat_>
R_X86_64_64, etc etc
<junon>
but those are only generated with fPIE, no?
<heat_>
it's a teeny tiny bit more efficient
<heat_>
no
<heat_>
see your object files
zaquest has quit [Remote host closed the connection]
<Mutabah>
You emit the kernel as still-relocatable (i.e. not fully linked)
<Mutabah>
then do the final bit of linking at load-time, once the randomised addresses are known
<heat_>
there was a patch-set a while back that added fPIE to x86_64 linux for Some Reason I Can't Remember
<junon>
oh wow, so they're not even fully linking the kernel until the kernel actually boots?
<heat_>
well, it's pretty much fully linked
<heat_>
if you don't touch the relocs again at runtime, you'll still run, but at the base address you set at link time
<vny>
In maps/smaps why isn't there a region that starts from 0 or ends at 0xffffffffffff?
<heat_>
because 0 is reserved and everything past 0xffff80000000.... is kernel-space
<vny>
I understand that the kernel half is not shown in maps
<heat_>
there you
<heat_>
go
<heat_>
in fact that [vsyscall] thing you have in your maps is a very old pre-vdso mechanism that's only kept for compatibility, and it's not really user memory (not unmappable, etc)
<vny>
but the kernel space starts from the middle 0x1000000046A40 and goes on till 0xffffffffffff but you should have a userspace region that starts from 0 right?
<heat_>
no
<heat_>
mappings at or near 0 are a security hazard for the kernel
<heat_>
0 is also not a valid C pointer
<heat_>
/proc/sys/vm/mmap_min_addr tells you the lowest address the kernel will map at
<junon>
yeah the first few pages I leave unmapped, and at minimum the first page should be unmapped.
<vny>
Interesting! Yes my page tracer picked 2138112 as the lowest address accessed during a run
<vny>
heat_: I don't see [vsyscall] in my maps
<heat_>
my x86_64 code does 2MiB min, riscv64 does 0x10000 because linux
<heat_>
vny, oh cool, your distro disables that then
<heat_>
it was an old region at 0xffffffffff600000 you could touch for magical vdso-like powerz
gorgonical has quit [Ping timeout: 240 seconds]
<vny>
I noticed something interesting, I was tracing /proc/1/smaps for half an hour at the period of 120s, and the lowest address it accessed was 0x560B170A9B00
heat_ is now known as heat
<vny>
I was wondering why it's so high! When the starting min address is 65536
<heat>
your distro is probably compiled default-PIE, including systemd
<heat>
so nothing is actually going to be mapped at addresses that low
<heat>
PIE elf executables usually get mapped at around 0x55..., the brk will be right after that, then over at 0x7f... you'll see the mmap mappings, the program interpreter in a grow-down order, then, above all, the stack
<heat>
(grow down because on linux most architectures do indeed allocate mmap regions in a top-down fashion)
<vny>
heat: is there a way to check if my distro has default-PIE on? Also, I saw a lot of comments discouraging using default PIE online, why is that?
<heat>
1) no 2) idiots
<klange>
PIE used to involve slower code... on 32-bit x86.
<heat>
ok 1) you can in theory start readelf -a distro programs and see if they have a base address != 0 in program headers or not
<klange>
Some people are just outdated, or don't know why it was reasonably discouraged in the past and keep parroting it.
<heat>
note that because LTO is funny GCC can't do fPIE :))
<heat>
GCC went the emacs route of dumping memory to disk
<klange>
You can ask gcc for its default configuration but it's hard to read (gcc -dumpspecs)
<junon>
klange: that's news, I had also read that PIE caused slower code and figured that was still the case.
<heat>
it's maybe marginally slower
<heat>
otoh, you get rather large security benefits
<klange>
rip-relative addressing in x86-64 was the major improvement there
<heat>
on intel sapphire rapids cores you get measurable speedups as your program will get packed with the rest of the libs up in mmap space and hence you won't get the big JUMP >= 2GB penalty
<heat>
ok, on that sapphire rapids assertion: i'll have to correct myself, you'll still suffer because the PIE exec and the shared libs are placed far apart, for Reasons(tm)
vai has joined #osdev
vai is now known as Jari--
<AmyMalik>
raphire sappids
epony has quit [Remote host closed the connection]
epony has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
Jari-- has quit [Ping timeout: 246 seconds]
Arthuria has quit [Ping timeout: 250 seconds]
heat_ has joined #osdev
heat has quit [Ping timeout: 248 seconds]
osmten has joined #osdev
omnit3a has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
gbowne1 has joined #osdev
Matt|home has joined #osdev
TkTech has quit [Ping timeout: 240 seconds]
TkTech has joined #osdev
bgs has joined #osdev
goliath has joined #osdev
<mrvn>
junon: PIE code is not position independent. It's just optimized to have fewer relocations and relocations are concentrated into fewer pages.
<mrvn>
junon: for example any time you have a global or static pointer initialized to "&bla" you must have a relocation.
<mrvn>
x86 32bit code *used to be* 30% slower with PIE a *long long* time ago.
bgs has quit [Remote host closed the connection]
<epony>
it is position independent
<epony>
and must be
<epony>
you can cheat and be lazy but don't call it position indpendent then
heat__ has quit [Read error: Connection reset by peer]
bauen1 has quit [Ping timeout: 240 seconds]
osmten has quit [Quit: Client closed]
osmten has joined #osdev
heat has quit [Remote host closed the connection]
heat has joined #osdev
austincheney_ has quit [Read error: Connection reset by peer]
<mrvn>
immibis: because your toolchain arbitrarily demands it
<mrvn>
immibis: don't forget that PIE still does relocations. It just does a lot fewer and those it does are more concentrated. Like using trampolines so you only have to relocate the trampoline and not every place the trampoline is called.
<mrvn>
a lot of the difference between pic/pie and non-pic/pie also has to do with shared libraries. Compilers should split the PC relative addressing from the shared libraries mechanismns.
<mrvn>
but they don't.
bauen1 has joined #osdev
osmten has quit [Quit: Client closed]
gmacd has joined #osdev
bauen1 has quit [Ping timeout: 265 seconds]
gmacd has quit [Ping timeout: 240 seconds]
bauen1 has joined #osdev
gmacd has joined #osdev
gmacd has quit [Ping timeout: 240 seconds]
dutch has quit [Quit: WeeChat 3.8]
dutch has joined #osdev
gildasio has joined #osdev
[itchyjunk] has joined #osdev
Left_Turn has joined #osdev
epony has quit [Ping timeout: 240 seconds]
epony has joined #osdev
slidercrank has quit [Quit: Why not ask me about Sevastopol's safety protocols?]
q3lont has joined #osdev
foudfou has quit [Ping timeout: 240 seconds]
foudfou has joined #osdev
heat has quit [Remote host closed the connection]
heat has joined #osdev
q3lont has quit [Quit: Leaving]
heat has quit [Remote host closed the connection]
heat has joined #osdev
heat has quit [Remote host closed the connection]
heat has joined #osdev
goliath has quit [Quit: SIGSEGV]
<zid>
good news, I got sidetracked and dove into why I have a ¦ key
<zid>
It was both logical OR, and used as a line-drawing char to mimic using ---- for horizontals, and to make it not look like l
xenos1984 has quit [Ping timeout: 248 seconds]
<zid>
also explains why I have a ¬ key, which is NOT
xenos1984 has joined #osdev
<HeTo>
zid: "What should be broken has become solid and what should be solid has become broken"
<zid>
That's presumably a reference to something that I've never heard of, sorry
danilogondolfo has quit [Remote host closed the connection]
gabi-250 has quit [Remote host closed the connection]
gabi-250 has joined #osdev
rnicholl1 has joined #osdev
xvmt has quit [Ping timeout: 250 seconds]
rnicholl1 has quit [Client Quit]
aws_ has quit [Quit: Reconnecting]
xvmt has joined #osdev
aws has joined #osdev
FreeFull has joined #osdev
gorgonical has joined #osdev
rnicholl1 has joined #osdev
awita has quit [Remote host closed the connection]
rnicholl1 has quit [Client Quit]
zxrom has joined #osdev
rnicholl1 has joined #osdev
rnicholl1 has quit [Client Quit]
rnicholl1 has joined #osdev
<gorgonical>
I relearned the very hard way yesterday that my early boot code requires my kernel and fdt to be 2mb aligned
<gorgonical>
And for some reason the facilities gdb has to read the page tables on aarch64 are abysmal
<zid>
It can read them at all? O_o
<gorgonical>
info mem in theory is supposed to read them
rnicholl1 has quit [Quit: My laptop has gone to sleep.]
goliath has joined #osdev
shikhin_ has joined #osdev
aws has quit [Quit: leaving]
shikhin has quit [Ping timeout: 256 seconds]
shikhin_ is now known as shikhin
aws has joined #osdev
aws has quit [Client Quit]
gmacd has joined #osdev
<geist>
doesn't exist for arm64
joe9 has joined #osdev
joe9 has quit [Client Quit]
gmacd has quit [Ping timeout: 246 seconds]
wootehfoot has joined #osdev
gmacd has joined #osdev
<heat>
my kernel also generally needs a 2MB alignment
bauen1 has joined #osdev
<gorgonical>
geist: I wish it did. There's gdb scripts floating around that sort of kind of work but are a little clunky
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
gmacd has quit [Ping timeout: 248 seconds]
<heat>
yeah that's a no-show in qemu because who knows
<gorgonical>
especially because it works in the risc-v gdb
<heat>
fwiw info mem does not work in x86_64 gdb attached to qemu
<heat>
it does work in the qemu monitor however
<gorgonical>
wait what, really?
<gorgonical>
oh
<heat>
yep
<gorgonical>
the arm64 qemu monitor doesn't know info mem, info pt, info pg, etc
<heat>
(gdb) info mem
<heat>
Using memory regions provided by the target.
<heat>
There are no memory regions defined.
<gorgonical>
the version of qemu I built* I should say
<heat>
yes, arm64 qemu has no sort of mmu debugging
<gorgonical>
:(
<heat>
riscv64 qemu has info mem, x86_64 has info mem and info tlb
<gorgonical>
Feels like it wouldn't be that hard to implement
<heat>
the architectures that have this all have slightly different layouts just to keep you guessing
<gorgonical>
I mean sure you can have very unusual page granularity sizes that probably complicate the matter but if a kernel has pagewalk code so can qemu
<heat>
yes, i agree
<heat>
everyone is frustrated but nobody does anything :)
<gorgonical>
maybe this should go on the list of things to do
<geist>
just someone has to type it in
<geist>
but it's complicated, but i encourage someone to do so
<geist>
there are just a lot of variables with arm64 page tables that make it somewhat more complicated is all
<geist>
writing a test case for it would be a pain
<zid>
Hrmph I can't get tortoisegit working
<zid>
tortoiseplink just says no auth methods
<zid>
if you google it it's just 80 results of people saying "switch to openssh"
<zid>
instead of an explanation or fix
<heat>
geist, this is FOSS, testing is illegal
* sham1
unit tests heat
<zid>
heat you're good at weird windows software, fix it for me
<heat>
you're making a mockery out of this situation
<heat>
ba dum tss
<heat>
zid, install steam, install csgo, start playing, come back to this problem a month later
<zid>
I mean that's what I normally do when I have problems
<zid>
except, factorio
<zid>
and it's pirated
<sham1>
Support the original release
<zid>
It's a fully legal multiplayer spawn install*
<zid>
remember those?
<gorgonical>
cracktros were cool
<zid>
You had an 'install' disc that installed the campaign, and then a 'play' disc which you could use to install to multiple computers but only the pvp maps
shikhin has quit [Ping timeout: 246 seconds]
<zid>
so that you could lan party off one copy
shikhin has joined #osdev
<epony>
and 3-4 discs for the trashbin
<epony>
a 7CD set game
<epony>
reminds me a desktoy lieunix desktribution
<geist>
aww, they dont read anymore or did they get scratched or something?
Vercas1 has quit [Remote host closed the connection]
Vercas1 has joined #osdev
epony has quit [K-Lined]
<zid>
heat: I'd show you the lovely gl skeleton I just made, but I can't cus windows
<zid>
it has fifty gajillion files that do 0 total work
gmacd has joined #osdev
gorgonical has quit [Remote host closed the connection]
gmacd has quit [Ping timeout: 240 seconds]
gorgonical has joined #osdev
wootehfoot has quit [Quit: Leaving]
<zid>
I think maybe I must have accidentally invented C++
<geist>
woot, got some of my tms9900 chips i ordered off ebay
<geist>
the full chipset arrives later this week
<geist>
need to breadboard something up
gorgonical has quit [Remote host closed the connection]
<zid>
I fixed!
plasma41 has left #osdev [#osdev]
<geist>
grats for you!
<zid>
woo!
<zid>
My scene graph is 'line'.
<zid>
Line is a graph.
<geist>
fiddling with opengl?
<zid>
yea I wrote a crappy skeleton that actually bothers to encapsulate stuff
<zid>
rather than just memcpying some arrays around and including gl.h into every file
<geist>
ah yeah
<geist>
there was some sort of wrapper i used years ago when i fiddled with this that helped. GLEW i think
<geist>
added some reasonable cross-platform 'is this function available' sort of stuff
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<mrvn>
OT: Somebody help me here. In the US if I put on black makeup that's cultural misappropiation, right? But if I put on white makeup, a BH and a dress I can go change in the womens locker room and participate in the womens 100m dash and how dare you transphobic assholes dare say anything?
<zid>
yea I already had the loader at least
<zid>
which is mainly what glew does
<mrvn>
zid: make sure your zero cost abstraction doesn't make things slower. :)
<geist>
mrvn: really not a good place for that sort of discussion
* mrvn
wishes that one could draw a single triangle on the screen with vulcan under just Debian building everything (in your project) from source.
<mrvn>
geist: when I am bored and watch some youtube shorts I feel like I'm being trolled. But the amount of that stuff and the people involved makes me think US is nuts.
<geist>
and again lets not bring that here
<geist>
i dont care how enraged you may be, take it somewhere else
morgan has joined #osdev
<mrvn>
Just wondering how real it is.
<mrvn>
zid: how do you compile the shader for your gl code?
<bslsk05>
github.com: wglskeleton/game.c at master · zid/wglskeleton · GitHub
<zid>
Like that geist, usually this file would end up full of opengl code
<zid>
game.c only sees struct model; struct geom; struct scene; struct shader;
<geist>
yeah years ago i wrote a mini game engine thing based on what i had leared while working at Sega for a bit. it's way out of date, but i found a reasonable way to abstract the engine and the renderer (ie, opengl and directx)
<geist>
ie, a general Renderer class that is specific for each backend
<zid>
gfx_ will do all the gl stuff
<geist>
word
<zid>
(and be replaceable with a dx version if I ever go insane)
<geist>
yah. or vulkan
<zid>
shader.c knows about gl though cus it has to compile the shaders
<geist>
one of these days i'll get bitten by teh vulkan bug and hack it up
<zid>
so you'd need a new one of those too
<geist>
i seem to remember that compiling shaders is pretty straightforward, the hard part is wiring up where all the inputs go to the upper system
<zid>
so that I can not have any strings in the eventual binary format, just a shader id
<geist>
yah
<zid>
main thing with actual gamey projects is just.. tool pipeline crap
<zid>
you can spend 10x as long doing that as anything else if you want
<geist>
part of why the drivers are so big really. they have full compilers for all the versions of the gpus they support, etc
<zid>
just to save a couple of hardcodes
<geist>
though i dunno how much that logic takes up of the bazillion MB of code each driver is
<zid>
the drivers are fairly small, the driver *package* is huge
<zid>
because it has shims for every single game
<zid>
nvidia releases a 'game ready driver' multiple times for each new AAA title, which contains precompiled shaders that they hand-optimised
<mrvn>
and now you have compilers that are optimized for specific benchmarks.
<geist>
yah presumably they see the call in the game to compile shader X, and if it matches the signature they just swap in their version
<zid>
yea, often times they fix bugs too
<zid>
so the driver is watching more than just 'compile shader'
<geist>
yah may even be swizzling inputs and whatnot
<mrvn>
zid: you mean the lib?
<zid>
like, fallout 4 never called endscene or whatever
<zid>
so they just.. fixed it in the driver that present() does it by itself if you're fallout4.exe
<geist>
i always wonder if nvidia ever reaches back to the game companies and gives them a list of shit they fixed
<geist>
'pls fix this so we dont have to do our hack'
<zid>
if you're a customer of nvidia you can just talk to them directly
<zid>
and have them fix your game and track your bugs etc
<mrvn>
geist: but then they have to make a new release for the new signature of the updated game.
<geist>
yeah that's kinda why i wonder if they really do it, beause it's not necessarily a win-win
<geist>
(from nvidias point of view)
<zid>
It's sort of like if you were making a playstation game or n64 game
<zid>
you had a phone number for a rep
<zid>
who you could ask technical questions to etc
<zid>
but now you're phoning nvidia instead
<mrvn>
from the games point too. Because the updated game will run slower because it doesn't have the hand optimized shader.
<geist>
well, sort of. i worked at Sega for a bit on the PS3 and xbox 360. there was a contact, but it wasn't like you just called em up
<geist>
it was more like, there was a forum you could post questions to, and maybe someone would get to it
<zid>
depends on how big of a developer you are, and how old the console is
andydude has joined #osdev
<geist>
and theyd release technical docs every once in a while
<geist>
as well as SDK updates
<zid>
older consoles were jankier and had more support from what I've seen
<andydude>
geist!
<zid>
like, I'd expect nearly 0 support on switch
<geist>
at the end of the day sony had like N people to support M companies and you got a proportional amount of support
<zid>
but the crash bandicoot devs were finding issues with the actual playstation and getting feedback from japan etc
<heat>
geist, you kinda have to or then your game doesn't work on any other driver right?
<geist>
'lo andydude
<andydude>
I used to be called adu
<heat>
re: nvidia reaching out to game devs
<geist>
ah was about to ask who is you :)
<zid>
heat: did you check my sick encapsulation?
<andydude>
but someone took that name during the freenode => libera thing
<heat>
zid, no
<geist>
well glad you found us
<zid>
[22:37] -NickServ- adu is not registered.
<pog>
hi
<pog>
it's me gog
<zid>
hi pop
<andydude>
hi pog
<geist>
wat. i was just about to point out my brain still reads pog as gog
<geist>
i always assumed it was someone else
<pog>
pog is gog
<heat>
lol
<pog>
gog is pog
<heat>
goggers
<geist>
if nothing else bcause irccloud chooses to color them the same color
<andydude>
poggers
<geist>
it seems to kinda randomly but consistently pick a color for everyone, probably some hash of the name
<heat>
yeah same here
<zid>
mine always picks the same colour, black
<zid>
because I am a boomer
<heat>
you're green, zid is yellow, gog/pog is purple, im orange
<heat>
but funnily enough trailing underscores don't change the color
<geist>
hmm, maybe it's length almost? as far as i can tell all 3 letter handles are the same color, etc
<pog>
heat and mrvn are different colors on mine
<andydude>
my colors all seem to be shades of green, cyan, lime, cerulean, teal, blue, etc.
neilalexander has quit [Remote host closed the connection]
<heat>
yes, same here
<heat>
i'm on hexchat btw
<geist>
yeah you're right, guess it's just coincidence here
<mrvn>
I'm white, unless I'm green.
<zid>
pog: I spent like 2 hours writing some code that does nothing, but it's a lot of code, I think I reinvented C++
<heat>
on arch
<andydude>
Where is the make everything orange button
<heat>
which i do use, by the way
<pog>
zid: cool me too
<mrvn>
zid: is it a constexpr?
<geist>
heat: oh i didn't know, you never mention that you use arch
<zid>
HEAT USES RUST!?
<geist>
what is arch, heat? I always wonder what that is and would love you hear you talk about it!
<pog>
RUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUST
<pog>
i basically use arch
<geist>
and i also assume you're using arch on itanium, right?
<andydude>
rust is so poggers
<sham1>
I use rust btw
<heat>
arch on ITANIUUUUUUUUUUUUUUUUUUUUUM as a CARGOOOOOOOO CRATEEEEEEEEEEEEe
<geist>
ITTTTAAAANIUM
<sham1>
On Arch btw
<geist>
hmm, does debian still have an ia64 port?
<sham1>
Itanium my beloved
<geist>
probably not for much longer
<pog>
i've been using arch since before all the cool girls started using it
<geist>
i did back in the day, that's what i had on my ia64 box when i still had it
<andydude>
omg, maybe I don't belong here anymore, I run ubuntu on like 4 of my laptops, I don't think I've ever run arch
<pog>
you must not be a cool girl
<pog>
sorry
<geist>
it's okay andydude, i use ubuntu and mint linux
<zid>
again, boomer here, so I run gentoo
<geist>
but i'm okay with that
<zid>
it's like arch but older and better, like all technology
<mrvn>
andydude: hod dare you. each laptop should have the right to it's own OS.
<geist>
but i do have slackware on my 386 and 486
<andydude>
ubuntu works for me
<geist>
so there, boomer that!
heat has quit [Read error: Connection reset by peer]
heat_ has joined #osdev
<andydude>
I did have a fedora silverblue phase, but didn't like the immutability
<mcrod>
so
<mcrod>
also, hi
<mcrod>
dunno if it's been said here, but fuck me man, the fucking smoke from quebec
<heat_>
geist, yes, debian still has ia64
<mcrod>
you european guys have it lucky
<pog>
is quebec burning
<sham1>
I use Ubuntu at work. It's nice enough although snaps do annoy me
<heat_>
pog, shuddup you're running manjaro
<geist>
yeah that's terribad. i can only say the only thing that works for me when we get smoke here on the west coast is stay indoors, seal the house/apartment/RV/tent/etc and get a in room hepa filter
<geist>
but of course it's too late to get them now i'm sure
<zid>
heat_: can you do my VAO stuff and throw it into struct model somehow?
<pog>
heat_: it's basically arch
<heat_>
i dont do graphics programming sorry zid
<mcrod>
pog: wildfires in quebec and an unfortunately timed weather system are causing smoke, very hazardous smoke to spread across the eastern seaboard of the united states
<heat_>
pog, u want 2 fight
<zid>
smh
<pog>
oof
<zid>
on the plus side
<pog>
heat_: yes
<zid>
quebec is on fire
<mcrod>
i'm about 10 hours away from quebec, and let me fucking tell you, it is almost impossible to breathe
<geist>
yah my east coast friends are all in a bad place
<heat_>
#osdev celebrity boxing
<mcrod>
heat_: oh by the way, IAR has a "tiny printf" thing you can use
<geist>
usually it's not so much the breathing as it really affects my eyes
<mcrod>
and sprintf and such
<geist>
i get to where i can't see very well and i just want to lay down and sleep
<heat_>
mcrod, but what if you pull tiny printf and printf :v
<mcrod>
you can't
<geist>
europe already cut down all their trees
<geist>
and/or drove tanks all over them, solved their problem
<zid>
All our forests are managed
<mcrod>
first thing's first: IAR is basically useless, but their documentation is prestine
<heat_>
thank you german blitzkrieg, very cool!
<pog>
oh jesus the part of new york used to live in is the worst rn
<mcrod>
yes
<zid>
north america has had weird 'no burns' legislation for a while and tried to actively stop forest fires etc
<mcrod>
the sky is literally red
<pog>
feel bad for my CNY friends
<geist>
but it's also hard to visualize how much just pure wilderness there is in canada
<zid>
and now it's all.. catchingfire
<zid>
weird that
<geist>
especially over here in the PNW. BC is like the size of the whole world, and just trees
<mcrod>
second thing is, I ran a few tests on the IAR we have vs. gcc/clang
<mcrod>
a) clang seems to come close in most cases to the code size produced by IAR
<geist>
IAR, it has been some time since i heard that name. was bad memories
<mcrod>
b) IAR seems to sometimes spill parameters to the stack
<mcrod>
when they should very obviously be passed in registers
<geist>
also reminds me of RVDS, back when ARM pushed that super hard on you
<zid>
"Decades of fire suppression and lack of indigenous fire ecology can contribute to dense forests with a lot of understory 'fuel' and many dead standing trees" wikipedia backing me up. Basically you can blame smokey the bear.
<mcrod>
c) the IDE itself an absolute trash can fire
<geist>
this is canada though, i think they simply can't supporess most of this fire
<geist>
callifornia definitely has that problem though
<heat_>
mcrod, use eclipse, eclipse is great
<heat_>
Believe Me
<mcrod>
no
heat_ is now known as heat
<geist>
nice troll heat
<mcrod>
again though, I will say they kind of have somewhat cool stuff
<zid>
yea you're not supposed to supress it, you're supposed to go out and burn the underbrush away
<mcrod>
but it's not obvious that it's there
<zid>
so that the fires happen gradually and not "all at once on the same day"
<heat>
i never troll, always super serious
<geist>
There Was A Time when eclipse was eveyrwhere
<geist>
i hated it then, i still hate it
<mcrod>
basically if you call `sin`, it calls a "balanced" sin function, balanced between code size and performance
<mrvn>
geist: stippled elipse arcs with rounded corners
<zid>
oh neat it has a catchy name, the smokey bear effect
<mcrod>
and it is not obvious at all that this is happening, and it would be nice to know that up front, because you can specify something like _iar_sin_reduced
<geist>
zid: yeah what i mean is a lot of canada is just pure wilderness, they couldn't suppress it if they wanted
<mrvn>
.oO(Ups, dropped a C)
<Bitweasil>
zid, yeah, unfortunately. Since the late 1940s, when the WWII surplus Jeeps, bombers converted to water bombers, etc, showed up, we haven't let stuff burn at the general low fire level that sort of forest needs, and now they're going off like bombs.
<mcrod>
code size is reduced, but so is accuracy, but who cares here
<pog>
i only had to use elcipse in my intro java class
<geist>
there is just so much trees to burn that when it does and you get a bad flow of the smoke, it blows into the much more populous US and then everyone shits their pants
<pog>
i never used it or java again
<Bitweasil>
It certainly looked like it worked, for a long while. :/
<zid>
I vote we cut 1km wide trenches into canada
<Bitweasil>
3M painter's masks and the white/pink lattice P100 filters do wonders on it.
<Bitweasil>
zid, won't help, firebrands are often *miles* ahead of the fire front.
<mrvn>
geist: that's what fire breaks are for
<andydude>
So I accidentally wrote a vi clone
<zid>
Bitweasil: We space them every 10 meters.
<heat>
hurr durr why not emacs
<geist>
yah honestly i dont know anything about this quebec fire, may be mismanagement
<mcrod>
how the hell do you not know
<andydude>
heat: IKR
<mcrod>
it's all over the news
<geist>
the BC fires i think are mostly yolo, beacuse they'r ein the middle of bumfuck nowhere
<Bitweasil>
mcrod, "Not watching the news" is an easy way.
<Bitweasil>
A lot more peaceful too.
<mcrod>
it's all over the internet
<pog>
i don't use the internet
<geist>
but yes, not watching the news is a good idea. i am a strong adherent to this
<Bitweasil>
See previous statement...
<geist>
i literally block news sites here at the router, actually works wonders
<mcrod>
i block fox news at router level
<geist>
indeed. also twitter and facebook. someone gives you a link? too bad
<Bitweasil>
(yes, I'm aware I'm on IRC, but what most people mean by "the internet" isn't the TCP/IP layer used for ssh, IRC, and apt repos)
<mrvn>
Bitweasil: the SSL/TCP/IP layer
andreas303 has quit [Ping timeout: 246 seconds]
<andydude>
I'm an emacs power user, I hate vi, and yet, all the neovim hype has made me interested enough to try it out again, and so I started learning vi key bindings, and was writing a stupid python curses script to take notes while learning, and it actually works!
<mcrod>
one thing i'll say though
<zid>
Bitweasil: You only need the massive firebreaks for massive fires, the point is that you just let the small ones burn, and the small trench is enough
<geist>
oooh lets talk about the 7 layer network stack!
<mcrod>
IAR seems to support almost fucking everything
<pog>
7 layer nacho stack is moremy speed
<geist>
OSI MODEL ITAAAANIUM
<mcrod>
the target support beats the *fuck* out of gcc/clang by _FAR_
<Bitweasil>
zid, ah, yeah. Except, half a century of fire material built up later, there's no such thing as a "small one" until we reset.
<mcrod>
however
<mcrod>
*however*
<Bitweasil>
Which involves the massive ones. :(
<zid>
Bitweasil: well, sounds like it just did? :p
<mcrod>
vendors are getting smart, and realizing that they can just pull clang off the shelf and add a backend
<mcrod>
there, an 'industry quality' compiler
<Bitweasil>
*shrug* How many square miles is it, vs how many square miles of forested area in North America?
<pog>
well the problem is the reset is a little too hard when there's so much tinder material around
<geist>
the Yellowstone supervolcano will reset it
<mcrod>
TI uses clang now
<heat>
they can also use gcc
<Bitweasil>
geist, long as it keeps bubbling...
<zid>
Just have a couple of weeks of raging infernoes, catch up on all the missing fire, ez
<zid>
nobody will mind the 60C air temps
<geist>
i'm sure it sucked but it would have been a trip to be up here in seattle when Mt St Helens blew
<pog>
exactly, deal with it the ssame way i deal with my emotions
<mcrod>
i'd give anything to have a pure LLVM toolchain for our shit
<mrvn>
zid: That would cost a lot of CO2 certificates. :)
<mcrod>
just unzip a goddamn toolchain and use cmake
<mcrod>
there, problem solved.
joe9 has joined #osdev
<andydude>
how configurable is cmake
<mcrod>
quite
<heat>
>use cmake
<mcrod>
the syntax is horrible, setting it up is horrible
<heat>
/kick mcrod
<mcrod>
but boy, when it works, it _works_
<zid>
Bitweasil: How about we reintroduce megafauna?
<andydude>
can it generate cweb => text => dot => svg?
<mcrod>
uh... no.
<andydude>
so cmake is not configurable
<mcrod>
this sounds like zawinski's law
<mcrod>
or at least influnced by it
<heat>
this sounds like heat's law
<heat>
"just because you said something doesn't make it <name>'s law, it's just a garbage quote"
<mcrod>
your mom
<andydude>
can I configure cmake to build nim, d, v, zig, uefi-modules?
<mcrod>
whatever d and v are, maybe probably
<andydude>
I thought you were a cmake expert
<mcrod>
i'm not a cmake expert
<mcrod>
never said i was
<mcrod>
it would 100% be useful for what we do
<andydude>
mcrod: "use cmake"
<geist>
now you got two problems
<mcrod>
yeah, you don't have to be an *expert* to say "use x"
<geist>
what about that bizarro one we were talking about the other day?
<mcrod>
ekam?
<geist>
build system that traces the compiler until it figure... yeah that
<heat>
ekam!!!!!!
<heat>
from kenton's funhouse
<mcrod>
i still want us to drop windows machines so bad
<CompanionCube>
there's also a one-file version in fabricate.py, isn't there?
<heat>
wait until you see his NIH completely slightly different STL-like library
<andydude>
Make at least is language neutral
<geist>
side note, kenton is the guy that used to have the famous lan party house in palo alto
<geist>
went there a few times. they were good times
<zid>
I wonder if you can break people's code who use sprintf instead of snprintf by setting up a locale with a funny - sign that's actually 40 bytes long
<sortie>
snprintf is the right tool for int -> string until you actually have a proven need for anything else, such as extreme performance
<mcrod>
right now, my title is associate software engineer
<sortie>
Oh lol I was reading the scroll back many days up
<mrvn>
zid: how would snprintf help there?
<mcrod>
safety
<sortie>
So any message here made it look like that discussion moved along
<mrvn>
you end up with the first 20 bytes of the 40 bytes glyph and then every UTF lib will explode because of decoding errors.
<heat>
mcrod, everyone gets senior
<geist>
nice. you've thus proven that all discussions operate in a cycle
<geist>
and we'll just come back to the same thing again and again
<heat>
you need like 4-5 yoe and you're a "senior"
<mcrod>
that's so long
<geist>
yeah that's the weird strange truism i learned over the years
<geist>
even if you dont think yo uknow shit, eventually everyone thinks you do
<geist>
and then you're senior. there is no test, there is nothing to prove
<geist>
you simply exist long enough
<mcrod>
i've been teaching someone and my boss is like "yeah, you're doing a great job"
<mcrod>
and i'm like
<geist>
also conversely, folks that are senior dont necessarily know shit
<mcrod>
"man. i should've asked for more money."
<mcrod>
no they definitely don't
<heat>
if you want to get a fancier title, faster, go to google or one of the other major tech corps, be there a couple of years, get senior, switch jobs to a smaller corp, boom you're a principal software engineer
<mcrod>
well, I should be careful here
<geist>
yep, honestly the job switch is probably the bet strategy. also dont suck and burn bridges
<mcrod>
well I plan to stay for 5 years max, because that's when my 401k will be fully vested
<mcrod>
but my salary is textbook entry ($75k)
<heat>
note that funnily enough, a fancy title doesn't pay the bills
<geist>
yah that's about what i did for a while until i eventually settled in at current gig
<mcrod>
i believe it
<geist>
switched every 2-4 years
<mcrod>
i commute to philadelphia so there are definitely other opportunities
<heat>
i want to be senior vice president of something
<mcrod>
i want to be the guy who makes the decisions about the goddamn code
<mcrod>
i know that's almost tyrannical
<heat>
i want to organize meetings, be in meetings, and participate in the beautiful corporate ladder
<geist>
meh i just want to be left alone to do stuff
<mcrod>
but, there are maybe 2 people I've ever known in a corporate setting who were actually competent
<heat>
senior vice president!!!!
<geist>
with enough encouragement to keep going, but not enough to be annoying
<mcrod>
the remainder, I have no idea how they've made it this far
<mcrod>
swear to god
<mcrod>
I'm not even making fun of them
<geist>
well, do keep in mind this is publically logged, etc etc
<mcrod>
no I know
<geist>
so i would probalby keep from trash talking *too* much
<mcrod>
suffice it to say that if I ever wanted to meet the really super competent people and have debates with and fruitful technical arguments
<mcrod>
it'd be IRC, hands down
<mcrod>
(so far)
<mrvn>
mcrod: not cppcon?
<mcrod>
i don't know.
<mcrod>
a lot cppconners make a lot of good things
<mcrod>
but some of them are *die hard*
<geist>
side note what cpu are you compiling for with IAR anyway?
<mcrod>
STM32F446VE
<geist>
kinda thought that was all a dying breed, only really DSPs maybe
<mcrod>
noooooo
<mcrod>
not at all
<geist>
odd, guess it is just the project set up that way huh
<geist>
last time i used one of the odd compilers was maybe 8 or 9 years ago with a TI Piccolo
<mcrod>
yeah, it's kinda mega corporate here, but another project uses Keli
<geist>
which is a wonky 16 bit arch
<mcrod>
but I've made it a _mission_ to make sure the next product uses an LLVM toolchain
<geist>
or at least gcc. either generates the fuck outta arm code
<mcrod>
and not fucking perforce either
<geist>
well, P4 is not *bad* all told. it's just an old model
<geist>
works nice for particular types of stuff, like craptons of binaries
<mcrod>
i know, it has its uses (e.g. game development)
<geist>
exactly. game dev
<mcrod>
but we're not even doing anything _close_ to that
<mcrod>
i'll tell you what I do
<mcrod>
in almost every vending machine in the united states and somewhere abroad, you put cash in and get a soda for $1.25
<mcrod>
where you put cash in, there is a machine there
<mcrod>
that's what I work on
<geist>
makes sense. some little microcontroller
<mcrod>
inexplicably though
<mcrod>
we do care about security, there are measures that have to be taken to safeguard certain things
<mcrod>
the security stuff on the PCs doesn't even allow you to compile something outside of WSL unless it's the main project
<mcrod>
*inexplicably* they chose to use a general purpose MCU with no security features
<mcrod>
guess what happened a few months ago?
<mcrod>
yeah.
<mcrod>
so, I pull my hair out sometimes.
<mcrod>
and I'm not saying anything that one couldn't readily find on the internet
* geist
nods
<heat>
i dont think you should roast your thingies in public like that
<geist>
agreed was just gonna say that
<mcrod>
probably not
<mcrod>
i'll shut it
<mcrod>
as far as gcc/clang goes, yes, it's turning out to be quite pleasant
<mrvn>
mcrod: you can easily progamm a vending machine in a verifiable language and do a machine proof.
<mcrod>
that's never going to happen
<geist>
depends on the size of the stm32. the really smallish ones it's still a bit hard to fit something like rust on it
<mrvn>
Blaupunkt did that decades ago for their car stereos because it's way cheaper than having to recall millions of stereos for a bugfix.
<mcrod>
512KB
<heat>
ruuuuuuuuuuuuuuuuuuuuuuuuuuuuust
<geist>
that being said the bigger ones... 512KB flash + what 64KB sram?
<mcrod>
i think so
<mrvn>
geist: on the small ones you can verify C code or even asm.
<mcrod>
we were talking about this the other day
<mcrod>
we don't enable any optimizations
<geist>
usually wht happens in that case is you end up chewing it up with soething like SSL or whatnot
<geist>
ah yeah at least do -Os or equiv
<mcrod>
accordingly, the size of the firmware is like 443
<mcrod>
IAR's -Os equivalent only kills off 100KB
<geist>
well, that's 25%
<mcrod>
yeah it's not a bad gain
<mcrod>
but I thought it'd be more
<geist>
eh, probably not. thumb2 is pretty tight
<mcrod>
my guess is they're worried about debuggability/reverification of the system
<geist>
also could be their no optimization is not really the equiv of -O0 in clang/gcc
<mcrod>
I do know for a fact whether or not you enable optimizations DCE is applied at least
<mcrod>
I honestly don't know how debuggable -Os actually is
<zid>
Might be 80% if some of that is .data
gmacd has joined #osdev
<mcrod>
i get the logic of what they're trying to do: -O0 is 'as close as it gets' to the source, and the fact that the system works fine without optimizations, performance is not an issue here, but -O1 is probably fine and would save us something
<mrvn>
mcrod: better than -O0
<mcrod>
i'll never understand that
<mrvn>
mcrod: -O0 is a stack machine. It's horrible code that has basically no relation with what the compiler will actually produce in release mode
<geist>
yeah i kinda get it
<mcrod>
when you compile with optimizations, shit is hoisted out or even straight up removed
<zid>
-O0 isn't even as close as it gets to the source ime
<heat>
great
<zid>
because it spills registers so aggressively and awkwardly
<mcrod>
but we don't have to care about that
<mcrod>
I mean, yes we _DO_
<heat>
-Os would make it soooo much faster, you're running out of flash remember?
<geist>
but really it depends on what IAR does. may be it's -O0 is like one level of optimizations past gcc/clangs
<geist>
like -Og equivalent maybe
<mcrod>
maybe
<mcrod>
they have it somewhere online
<mrvn>
zid: it takes every expression and emits building blocks for it based on a stack machine. No register allocations at all, which is why you see all those loads and stores.
<geist>
you can look at the dissassembly and see. the big one is does it aggressively load/store everything on the stack
<zid>
like, f or g, which one is most like the source? :P
<puck>
i considered writing an llvm backend
<puck>
but i'm not sure llvm can deal with 2^32 registers
<heat>
we should use computers with loads and loads of registers and lots of out-of-order execution, maybe with funky instructions
<geist>
yeah, this is the sometimes frustrating aspect of embedded programming. it only has to work well enough and then ship it
<geist>
doesn't matter how the sausage is made
<puck>
the C11 compiler for the TI c2000 DSPs was cute
<mcrod>
i'm of the opinion that code size is the only thing that matters in an embedded system until you've proven you need to optimize a certain portion of the program to meet timing requirements
<heat>
titanium? sounds like a cool name for a new architecture
<geist>
puck: is that the Piccolo? I've had to use that one reently
<zid>
I'm a big fan of shitty embedded devices where they run really slowly so that the buttons are really unresponsive
<geist>
weird little 16 bit DSP. like hard 16bit. smallest addressible anything
<zid>
you have to hold them for nyquist to make sure they work
<zid>
sometimes you get lucky and your touch lines up with the poll and they work instantly, sometimes you're waiting 2 seconds
<puck>
geist: i think so, but
<puck>
geist: whatever i used had 8-bit read/write instructions, but they were weird
<geist>
mcrod: unless you can get a cheaper smaller mcu and save $0.01 on the BOM
<puck>
i never used those, but did enjoy using uint_least8_t and static assertss
<geist>
puck: yeah that sounds a bit like the piccolo
Turn_Left has joined #osdev
<puck>
geist: it was somehow the nicest code i've written
<puck>
with the funniest conditional ever
<mcrod>
i wonder how small you can get strlen()
<mcrod>
IAR's version for some reason is _huge_
<mcrod>
*huge* I tell you
<geist>
look at the dissassembly
<mcrod>
yeah I haven't had a chance
<geist>
that answers all. then you can see why it's huge
<puck>
geist: uint_least8_t rx_serial(void) { uint_least8_t data = *whatever_i_named_the_rx_register; if (data > 0xFF) fail(BYTE_NOT_BYTE); return data; }
<geist>
may just be stupid, but it also may be trying to be clever. or something you dont know
<geist>
puck: yeah, looks like piccolo is in the C2000 series
<mcrod>
note that for what we're doing, *keep this in mind, performance doesn't matter. there are no complex edge cases we care about.*
<zid>
clang 3 lines shorter on O0 too :p
<zid>
O on gcc also gives better diagnostics, which is the main reason to use it at all tbh
<zid>
even on a PC
<zid>
same with lto
<puck>
> The wchar_t type is implemented as int (16 bits) for COFF and long (32 bits) for EABI.
<geist>
also dont forget -Og which i think works fairly well
<puck>
hrmm. apparently i misremembered the EABI/COFF bit size thing, it's actually to do with CLA
<geist>
i think we use that at work for our 'debug' build
<puck>
(control law accelerator)
<mcrod>
on clang that's the same as -O1 I think
<heat>
Og does not exist for clang btw
<heat>
yes
<heat>
iirc the zircon build takes that into account
<geist>
oh hmm. i thought there was some sort of Odebug for clang?
<puck>
> To access data in increments of 8 bits, use the __byte() and __mov_byte() intrinsics described in Section 7.6.
<mcrod>
not as far as I'm aware
<geist>
oh guess not then
<heat>
you may be thinking of Ofast
<mcrod>
I love -Ofast and maybe I shouldn't
<geist>
well, i remember the discussion existing, but maybe it was just solved with 'yeah we can't do that on clang'
<heat>
you shouldn't
<mcrod>
because sometimes -O3, or hell even -O2 is faster depending
<zid>
Ofast is bad and you should feel bad
<geist>
possibly from back when we were still building with gcc
<mcrod>
why is it bad
<zid>
It's "fast in ways that breaks the code"
<zid>
specifically
<zid>
that's the intention of Ofast
<geist>
we always build the kernel with -O2 though, just hard rule
<heat>
Ofast is invariably fast
<heat>
Ofast go vroooooooom
<mcrod>
most people don't have to care about what -Ofast is breaking unless they're in scientific computing
<zid>
Ofast go sigfpe :P
<geist>
relal the biggest thing you can do in any of these cases is explore LTO or some variant thereof
<zid>
"Disregard strict standards compliance. -Ofast enables all -O3 optimizations. It also enables optimizations that are not valid for all standard-compliant programs."
<geist>
as much as i dont really like working with the results of LTO, it can be a large win
<mcrod>
yeah?
<heat>
geist, how big of a win is LTO for zircon?
<mcrod>
i don't necessarily see the problem
<geist>
for the kernel, not terribly so bcause we're already quite good at inlining things, etc
<geist>
for lots of user space, it can be large. especially rust
<mcrod>
i mean, if you're in a situation where you're worrying about e.g. reordering float computations that'll be a problem yes
<mcrod>
all depends on your use case
<geist>
but i've seen other random projects in the wild that benefit tremendously from LTO. usually because they hvae lots of little .c or .cc files without inlining
<heat>
C++!
<mcrod>
geist: why don't you like working with the results of LTO?
<geist>
klike, for example, i added LTO to the commanderx16 emulator the other day and it sped things up like 33%
<heat>
because it's a garbled mess
<heat>
the output has no logical sense
<mcrod>
may be a garbled mess, but possibly as you say
<geist>
likes to aggressively inlie stuff from all over the place. basically if something is called once, it'll be inlined in the one place that calls it
<mcrod>
'vrooooooooooooom'
<geist>
even if it's across the binary
<heat>
i've seen it inline half the kernel init into the main function
<geist>
right
<heat>
LTO is not necessarily a win
<geist>
also it's quite aggressive about devirtualizing virtual methods
<zid>
Yea LTO just inlines your entire program into main
<zid>
because 99% of programs do main() { check a thing; NAME_OF_PROGRAM(); clean(); }
<mcrod>
well that's why I said possibly
<zid>
and that can all inline
<mcrod>
in an embedded context it would be super dangerous
<geist>
it's one of the reasons we dont actually use LTO for zircon kernel, though we have compiles for both thinlto and lto
<geist>
actually thinlto is the good compromise, and really what you should use most of the time
<mcrod>
i would think devirtualization would be a win
<zid>
LTO is disgusting to debug just because gcc can't generate good debug info for it, imo
<geist>
it can be, though iirc thinlto can't devirtualize
<zid>
It isn't some natural feature of LTO
<mcrod>
worst case scenario you could just do CRTP :')
<zid>
My entire gameboy emulator turns into ROLA.83493
<geist>
but if you're compiling some thing you dont care about debugging, enable it and dont think about it too hard
<zid>
as one giant symbol
<geist>
yah, for emulators and whatnot i think it can be a massive win
<geist>
since at the core there is a big switch statement effectively
<mcrod>
right
<geist>
or at least turns your code into that
<zid>
It honestly does nothing
<geist>
that's what it did to the commanderx16 emulator
<mcrod>
it's a gameboy emulator
<geist>
really sped things up
<zid>
just inlines everything into main and throws away all the names :(
<morgan>
also unless you're tracking a LTO-induced linker bug presumably you could rebuild without LTO if you wanna get the debugger on it
<mcrod>
i doubt you're going to see tremendous gains
<heat>
no
<heat>
i've had to debug issues that were introduced by LTO
<zid>
But, it stops memory access from the lcd needing a function call
<zid>
so that's a small win at least
<geist>
yah like i said it helps different code bases differently
<zid>
main reason I do it is to catch bugs, like I said
<mcrod>
like everything else in this field
<mcrod>
"it depends"
<geist>
depends a lot on how aggressively it can inline across file boundaries and ho wmuch of a win that is
<zid>
it both gives better diagnostics, and aggressively turns UB into crashes.
<heat>
linux for instance has dubious gains with LTO
<geist>
yah i think it has a potential to help C++ style codebases more: in general more functions more oppruntity to help
<zid>
LTO is basically a panacea to everything except debugging
<geist>
but then depends on how aggressive the codebase already is about putting things in headers and inlining
<heat>
yeah it's a big win for heavy C++
<zid>
faster, better diags, better sanitizing
<morgan>
oh right you guys have to worry about UB
<heat>
i can tell you that GCC was horrific when compiled with -flto, for Reasons
<zid>
I've compiled gcc with lto, worked fine for me
<mcrod>
RUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUST
<geist>
but the commanderx16 emulator i think was a perfect case for non C++. it had a ton of little routines for blitting this or that, sinc eit's emulating this whole sprite engine. and the way it was written was a ton of little routines
<morgan>
:3
<mcrod>
don't worry, rust isn't going to save us
<geist>
and the 6502 core was written in a particularly inefficient way: a big dispatch tble of functions each for every instruction
<zid>
rust makes huge slow binaries in exchange for no UB, doesn't really work for embedded
<geist>
and via a function pointer, constructed at run time
<heat>
zid, i had huge binaries that blew up in size to several tens or hundreds of MB, i don't know
<morgan>
i'm doing some rust embedded right now and it's going fine /shrug
<heat>
maybe just doing CFLAGS=-fPIC ./configure && make isn't the way to go about it
<zid>
heat: did you port them to rust without noticing
gmacd has joined #osdev
<heat>
oopsie, felt cute, ported gcc to rust, might delete later
<geist>
morgan: yeah i dont ssee why it's instnatly going to be huge, but it has the potential to, depending on the constructs
<morgan>
and so can c++ if you go crazy with virtual and templates
<zid>
hello world in rust is 3MiB
<zid>
bye bye "six times my entire flash"
<heat>
rust statically links everything
<heat>
that may be your problem
<heat>
at least by default, that is
<nortti>
also includes stuff like "oops, all the error message strings" and unwinding support by default
<bslsk05>
johnthagen/min-sized-rust - 🦀 How to minimize Rust binary size 📦 (163 forks/5808 stargazers/MIT)
<zid>
you can unbloat it a little
andreas303 has quit [Ping timeout: 250 seconds]
<morgan>
well my firmware image at the moment is 90 kB-ish and it does a whole lot more than hello world
<zid>
but it's still going to be generally bigger no matter what they do
<bnchs>
zid: that is 75% of an average sega mega drive cartidge flash chip (4 MiB)
<bnchs>
for a fucking hello world
<zid>
(embedded is a tiny amount of real products these days though, even casio watches are basically PCs)
<pog>
hi
gmacd has quit [Ping timeout: 240 seconds]
<kof123>
going through old backups i found cmi-1.0.0.src.tar.xz https://0x0.st/s/L2oHh9F9kd7cUNBXbsBnNg/Hcst.tar.xz a kind person can mirror this so future me does not lose it. you need an old haskell. cross module inliner for c , gpl 2 (so mirror away)
<bnchs>
i've seen C games in that platform take up like 1.5 MiB and such
<bnchs>
all without removing stdlib and shit
goliath has quit [Quit: SIGSEGV]
sebonirc has quit [Ping timeout: 248 seconds]
<mcrod>
no matter what, I will always be a fan of C
<mcrod>
despite all of its legitimate issues
<mcrod>
it is a true love
<morgan>
i started with c but i'm not really sure i miss it
<mcrod>
i work with it daily
<mcrod>
it's lovely
<mcrod>
that sounds crazy, I know
<mcrod>
but, _but_
<mcrod>
it would have almost certainly ended up an overly complicated mess if we used anything else
<geist>
agreed. that's my general torn feeling about it. i love C for the same reason, but then i realize that most people dont feel the same way
<geist>
and there are disadvantages, etc. it's kinda like working with say hand tools for your carpentry
<mcrod>
when you're writing code
<geist>
you can love doing it
<mcrod>
you should view it with a sort of childlike simplicity, because all code should be as _simple as it can be_
<morgan>
yeah but that holds up right until you encounter a complex problem
<mcrod>
nonsense
<mcrod>
physicists go out of their way to make shit as simple as they can
<morgan>
physics? no i mean actual complex problems like string manipulation or date math
<morgan>
:p
<mcrod>
point is, in an ideal world, I should be able to print out the source code and read through it without the assistance of an IDE or something, almost like I'm reading a book sipping tea at the fireplace
<mcrod>
proper commenting and all
<mcrod>
note that I have to say ideal world
<morgan>
ah see i don't ever want to read code in an environment that doesn't have a "Jump to definition" button
<mcrod>
so print a glossary
<mcrod>
table of contents I should say
<mcrod>
note that I'm not being quite that literal
<mcrod>
I'm saying that complicated problems are indeed complicated, but implementing them should be as simple as they can fucking be
<mcrod>
otherwise it will quickly become an unmaintainable mess
<mcrod>
and by that I mean "neither you, nor someone a year from now will be able to understand why you did this"
<morgan>
i find languages with strong type systems to make that easier though
<bslsk05>
'Garfield dancing to American Boy, but low quality' by Hugo Fernandes (00:04:45)
<morgan>
why guess about exactly how the output parameter and integer return value works when it could be a `Result<&T, _>`
<mcrod>
i don't know what that means.
<mcrod>
"how does an integer return value work" simple, `return 666;`
<mcrod>
heat: this is nightmare fuel
<morgan>
"you're looking at a function declared as int do_something(int mode, struct foo *out)" vs "you're looking at a function declared as fn do_something(mode: Mode) -> Result<Foo, Error>", as a hypothetical case
<morgan>
sure you *probably* call the C function with a `MODE_XXX` constant and an uninitialized `&foo_goes_here` and get a 0 or 1 to represent failure or success, but with the Rust function the details are completely unambiguous. i'd much rather come back to the latter in a year
sebonirc has joined #osdev
<pog>
i'm a c# dev in my day job and i actually like it for application dev
<pog>
i've taken a look at COSMOS too
<pog>
i might try to cobble something together with it at some point