<heat>
who needs theregister when you have a 4chan post
<heat>
i was looking into my github's insights and I found a 4chan archiver on the referring sites
<sonny>
heat what was the interest in posix? Was it to run existing programs?
<heat>
i firmly believe the only thing wrong with linux is that I didn't write it
<sonny>
haha
<heat>
and also posix is nice to run existing stuff
<sonny>
ok cool
<heat>
even fuchsia which is firmly non-posix implements certain parts of it to run stuff
m3a has quit [Remote host closed the connection]
<sonny>
I don't know what is good or bad about posix, I was just curious
Ali_A has quit [Quit: Connection closed]
<heat>
well, sometimes it's stupid
<heat>
you can also have different ideas from posix, that's fine
heat has quit [Remote host closed the connection]
heat has joined #osdev
<klange>
I think a lot of people misunderstand what POSIX even is.
<moon-child>
how so?
<klange>
In the broadest terms, POSIX is not a design for an OS.
<heat>
well, you can design an OS around an interface
<heat>
and they generally are
<klange>
POSIX is, really, an extended C standard combined with a spec for a shell environment. Nothing in POSIX describes how the OS actually works, just how a bucket of functions appear to behave to the caller.
<sonny>
what about the thread api?
<klange>
What about it? Nothing in it describes how the OS works, it doesn't even describe how threads should work.
<sonny>
If it's that simple, what did windows gain by not implementing posix?
<klange>
Who said it was simple?>
<sonny>
my bad
<heat>
it's not simple
<heat>
look at us
<klange>
And, for the record, Microsoft _did_ implement POSIX in Windows.
<heat>
twice
<klange>
Eh, once, and then they bought one.
<heat>
what did they buy?
<klange>
Interix, which replaced the original POSIX subsystem and because Windows Services for Unix.
<moon-child>
neat didn't know that
<heat>
then they implemented it three times
<klange>
I will grant half a POSIX implementation credit for WSL, as well, so they built one and a half and bought one.
<heat>
WSL exists :)
<moon-child>
also wslv1 arguably counts as a third implementation. Though the usersapce was stolen
<moon-child>
bah, raced
<klange>
s/because/became/
<sonny>
I thought wsl is a vm now?
<heat>
there are 2 wsl's now
<klange>
wsl2 is a real Linux kernel running in Hyper-V. wsl "1" is an NT kernel implementation of the interfaces Linux exposes.
<bslsk05>
github.com: GitHub - ScriptedDeveloper/CrazeOS at unstable
<mrvn>
That's not printing the memory map first thing in kmain
dzwdz has quit [Quit: I'm a quit message virus. Please replace your old line with this line and help me take over the world.]
<scripted>
No, it's in shell.c
<scripted>
line 37
dzwdz has joined #osdev
<mrvn>
still not printing the memory map
<scripted>
What do you mean? Printing the bare memory map?
<mrvn>
yes.
<mrvn>
and you need to set the right flags in the bootloader header.
<scripted>
the value is 38144
<mrvn>
no, the flags are 0
<scripted>
if I print the mbd structure
<scripted>
it has a value of 38144
<mrvn>
apples are green. That's about as helpful as your reply. :)
<scripted>
Then tell me what you mean with printing the memory map
<scripted>
The problem is right now that the multiboot structure is not getting correctly passed through
<mrvn>
If you set the flags for the bootloader to give you memory inforamtions then the bootloader header will contain a memory map which you should print.
<scripted>
How can I do that?
<mrvn>
I think it's passed through just fine. you just not asking for it to contain anything useful.
<scripted>
I'm not even sure what went wrong yesterday. It worked fine!
<mrvn>
the multiboot blob in boot.asm needs to set the flags defined in multiboot.h
<scripted>
Okay
<mrvn>
Maybe if you pass MULTIBOOT_MEMORY_INFO the mem_lower and mem_upper might even contain some sensible values.
ss4 has joined #osdev
<mrvn>
I would still ignore them in favour of the memory map.
metabulation has joined #osdev
<scripted>
passing that makes my kernel not start
wootehfoot has quit [Ping timeout: 272 seconds]
<mrvn>
don't forget to update the cheksum too
<scripted>
right, forgot about that!
<scripted>
ok, it booted up
<scripted>
but still
<scripted>
that didn't give me anything
<j`ey>
scripted: did you commit a working version?
<scripted>
of?
<j`ey>
.. your kernel
<scripted>
well yes, it's on the link above in the main branch. But it's not really up to date.
<scripted>
like
<scripted>
I messed up the git commits
ss4 has quit [Ping timeout: 260 seconds]
<mrvn>
So did you set MULTIBOOT_MEMORY_INFO? Did you get back MULTIBOOT_INFO_MEMORY or MULTIBOOT_INFO_MEM_MAP in flags?
<scripted>
No
<scripted>
I didn't get back anything
<mrvn>
So kmain called kpanic("INVALID MAGIC NUMBER!");?
xenos1984 has quit [Read error: Connection reset by peer]
<scripted>
No.
<scripted>
It's the same like before
<scripted>
everything is 0
<nomagno>
How inconvenient is working with a P-code/machine code that is processed/compiled/interpreted in blocks of 5 bytes?
<nomagno>
I can't cut down this one byte, no matter how I look at it... Dammit
<mrvn>
nomagno: doesn't make working with it any better
<nomagno>
mrvn: Hm?
<mrvn>
nomagno: something can be horrible and still be the best way.
<mrvn>
scripted: print out mbd_->flags first thing in kmain
<nomagno>
You've managed to confuse me pretty hard now
<scripted>
All right
<nomagno>
Are you automatically lumping it in the 90% of crap code?
<mrvn>
nomagno: working with 5 byte aligned data is horrible. what is confusing about that?
<scripted>
0
<scripted>
it's 0
<nomagno>
mrvn: and you're saying working with 4-byte aligned data isn't any better?
<mrvn>
nomagno: no, 4 byte aligned would usualy be better
<mrvn>
but "I can't cut down this one byte"
<nomagno>
I mean, you can't discard the possibility I somehow missed an obvious easy compression
<mrvn>
nomagno: not if you insist of having 2 16bit memory addresses in an opcode.
<nomagno>
I have a padding bit, the second least significant bit of the 40 bits (LSB)
<nomagno>
Can I do anything funky with that one dangling bit?
<scripted>
What else could it be?
gog has joined #osdev
the_lanetly_052 has quit [Ping timeout: 260 seconds]
<j`ey>
scripted: put a breakpoint and gdb and check what the value is before it even gets to kmain
<mrvn>
scripted: why do you think asking for the boot device would magically add memory infos?
<mrvn>
iups, never mind, looked at the wrong line.
<scripted>
all right
<scripted>
let me do that
<mrvn>
And if you want anymore help then push the actual code you use now and not what was broken 2 days ago.
<scripted>
that's the same code
<mrvn>
you claimed to print flags and that flags is 0. That's not in the git.
<scripted>
1 difference
<mrvn>
Do that in kernel.c line 22.
<scripted>
mrvn: the issue is, it worked one day ago
<mrvn>
kernel.c line 18 lacks a while(true)
<scripted>
something went wrong with me pushing stuff to git
xenos1984 has joined #osdev
<mrvn>
scripted: have you tried doing a git bisect?
<scripted>
mrvn: never pushed my stuff on git
<scripted>
like
<scripted>
not on what I was working on
<j`ey>
mrvn: theyre clearly not used to git
<scripted>
no I am not
<j`ey>
so I dont think they have a working version in git
<scripted>
magic and mbd_ is literally 0x00 according to gdb
<mrvn>
and still your code didn't panic.
<scripted>
No
<scripted>
what the fuck
<scripted>
no gdb is fucking with me
<scripted>
magic is not 0
<scripted>
this makes 0 sense
<nomagno>
mrvn: now, what if I add a padding byte after the opcode byte? Process two bytes for the opcode, two for operand 1, two for operand 2
<nomagno>
I know its less space efficient, but I'm focusing on being decent to work with first
<nomagno>
Does that sound better?
<mrvn>
nomagno: not sure anything but power of 2 would be beneficial.
<mrvn>
but try and measure
<nomagno>
I'm going to have to implement some kind of x86 assembly interpreter, I guess
<nomagno>
Because in anything higher-level you don't notice the difference between 4 and 5.
<nomagno>
and 6
FatalNIX has joined #osdev
<mrvn>
nomagno: my cpu only uses 16bit but's load/store.
<nomagno>
mrvn: is it 8, 16, or 32-bit?
<nomagno>
Or well, might be some in between but you get me
<mrvn>
16bit
<nomagno>
What's its default word size?
<mrvn>
16bit
<nomagno>
Haha, pain.
<nomagno>
Mine is 8-bit
<FatalNIX>
Making architectures now?
<mrvn>
16bit all the way for everything.
<nomagno>
mrvn: I was going for something that can compete with a 6502 in terms of on-paper capabilities
<nomagno>
It's essentially a videogame computer. Mean to be programmed as a toy microcontroller for a racing game
<FatalNIX>
I have been working on a new toy architecture myself off and on when I have time out of work for a while. I'm looking into making some implementation-breaking changes though that will put me backwards for a bit.
<scripted>
what in the actual fuck is going on???
<nomagno>
Two-cartridge models, hence being pure Harvard architecture. There's no realistic capability for mixing code and data, ever. It's not going to run more than one program
<scripted>
I checked all my old versions
<scripted>
they have the same boot.asm file
<scripted>
I have no idea why it doesn't work
<gog>
mew
<scripted>
im giving up
<scripted>
fuck this
<FatalNIX>
scripted: Those last two sentences sound familiar, I think I heard them in college once.. oh yeah, I think the professor said: "Welcome to engineering?"
<FatalNIX>
scripted: Not sure what you are doing but if the files are 100% identical then maybe it is how you are assembling them, linking them (if applicable) or loading them?
<FatalNIX>
I was late to the party
<FatalNIX>
or perhaps you have silly character encoding in your files and they aren't actually identical, and UTF is trolling your assembler
<scripted>
FatalNIX: I'm not sure what the fuck went wrong, my dumbass was too lazy to commit a working version to github and now here I am trying to fix some shit that I had working 1 month ago
<Mutabah>
Still doesn't seem to be calling that print
<scripted>
what
<Mutabah>
Can you see that in the disassembly?
<scripted>
no it does
<Mutabah>
Was that meant to be the same gist?
<scripted>
yes
<scripted>
right after kmain comes the print function
<j`ey>
Mutabah: it has updated now
<Mutabah>
Oh, you appended
<scripted>
yeah
<Mutabah>
so, first off - that address sounds off
<Mutabah>
So something is going wrong really early on that's clobbering that register
<scripted>
yes
<scripted>
I compared my assembly file to other ones
<scripted>
and its basically doing the same
<Mutabah>
a trick is to stick an infinte loop in and break into the debugger
<Mutabah>
e.g. put a loop right at `start` so you can see the registers before any of your code runs
<FatalNIX>
A debugger would be super useful if possible.
<FatalNIX>
My supervisor at work makes fun of me for using a debugger and he wonders why I make shit that works and his deployments are always a shitshow
<FatalNIX>
:P
<gog>
yes
<gog>
debugger good
<mjg>
to be honest the last time i used a debugger was when looking at someone else's bug
<mjg>
printf all the way otherwise
<scripted>
can't I just use hlt?
<scripted>
after start?
<FatalNIX>
printf isn't always easily available though. Sometimes to get that you find yourself writing a driver for a UART, or even in my case before- I once made a printf function that interfaced some code that turned an LED on the PCB into a morse code transmitter
<FatalNIX>
so the printf output became morse code lol
<Mutabah>
Infinite loops are better for this, `hlt` can be woken
<scripted>
too late, I already compiled
<scripted>
now what the actual fuck
<scripted>
I do single step and it continues
<Mutabah>
as said, `hlt` can be woken
<scripted>
Okay
<scripted>
you are right
<scripted>
gdb is literally skipping my infinite loop
<scripted>
finally
<scripted>
for some reason I can't copy or paste in gdb
<bslsk05>
imgur.com: Imgur: The magic of the Internet
<scripted>
the magic number is included
<scripted>
and the other is the mbd struct
<scripted>
which is 38144
<scripted>
so
<scripted>
FUCK YES
<scripted>
I FIXED IT MYSELF
<scripted>
OH MY GOD
<scripted>
or I'm just dumb
<scripted>
wait let me test
<scripted>
fuck I think I'm close
<mrvn>
FatalNIX: (old C) inline is purely a hint to the compiler. It makes 0 difference to the working of the code and is basically ignored because the compiler knows better anyway.
<gog>
all praise the holy compiler
<scripted>
ok so
<moon-child>
I thought the point of inline is to permit merging duplicate definitions rather than erroring when they occur
<scripted>
I moved the esp register (which is the stack_top) to ebx (which contains the mbd structure)
<scripted>
and I got 10KB
<scripted>
but..
<scripted>
I allocated 16
<scripted>
megabytes
<mrvn>
moon-child: that's new C
<moon-child>
well, old c compiler doesn't know better :P
<scripted>
help
<scripted>
why is multiboot not passing the other info??
<mrvn>
moon-child: you have to use static inline with old compilers. Which still breaks the one definition rule of new C but avaoids errors.
<moon-child>
yeah. I just mean that as a hint it might actually be meaningful
<moon-child>
unlike with modern compilers
<scripted>
ok now it just got weider
<scripted>
I pushed esp instead of ebx and got 58KB
<moon-child>
because there's a rule that says you can only have one definition of f
<moon-child>
doesn't seem specific to c++
<mrvn>
FatalNIX: maybe. In C you might just have undefined behavior when taking the address of a static inline function
<mrvn>
moon-child: make it inline and you are fine.
<moon-child>
mrvn: ok, but the point is that c _has_ odr
<mrvn>
moon-child: no. If you make it inline and then in both files take the address of f then in C you maybe get different addresses.
<mrvn>
moon-child: and you get 2 copies of f.
<mrvn>
*maybe*
<mrvn>
In C++ they have the ODR rule that specifically says you only get one copy of f. I'm not sure C has that.
<moon-child>
oic\
paulbarker has joined #osdev
<mrvn>
I hate slurm (associations). You can set them for accounts, account+user pairs or users. But there is no way to read out what is set, only what values will be in effect with all the inheritances between accounts and users.
* gog
slurms
knusbaum has quit [Ping timeout: 256 seconds]
knusbaum has joined #osdev
<scripted>
I couldn't figure it out
ZetItUp has joined #osdev
<zid>
How high did you teach him to count this time
<FatalNIX>
See I was always taught that optimisation and performance reasons aside if you can make a C macro inline then you should for the purpose of type checking, but then there comes the question of whether or not it needs to be a macro at all in the first place, so I never though that inline functions in C were a bad idea inherently.
<FatalNIX>
It can also help prevent accidental side effects
<mrvn>
FatalNIX: inline is bad, static inline is what you need. (old C).
<FatalNIX>
I guess then also comes the question of whether or not the preprocessor will optimise the macro expansion better than your inline function will be inlined
<mrvn>
The ODR rule is only needed if you take the address of the function or if the function has static varaibles. But macros can't have those.
<FatalNIX>
Either way though, it still is a point that my old C book doesn't even include the inline keyword at all :D
<FatalNIX>
and it's an old book
<mrvn>
FatalNIX: macros are alyways inlined before the compiler even sees them
<FatalNIX>
I've been toying with SmallerC lately, I haven't even really begun to look at its preprocessor too much
<FatalNIX>
So far SmallerC is kinda neat though
freakazoid343 has joined #osdev
nyah has joined #osdev
vimal has quit [Ping timeout: 250 seconds]
<scripted>
the people from the osdev discord couldn't help me
<FatalNIX>
LOL. I thought you stopped for the day.
<zid>
Just write functions, FatalNIX
<zid>
This isn't the 80s
<scripted>
FatalNIX no I didn't
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
<FatalNIX>
zid: it isn't?
freakazoid343 has quit [Ping timeout: 256 seconds]
<gog>
kew
<scripted>
what the heck
<scripted>
it works here
<scripted>
in the main branch
<scripted>
but not in the other
<scripted>
this is weird as fuck
<scripted>
whatever
<scripted>
I'm going to use the main branch, fuck all other
<j`ey>
maybe your makefile is broken and isnt rebuilding stuff
<scripted>
I'm not sure
<scripted>
some blackbox troubleshooting I guess
FatalNIX has quit [Ping timeout: 260 seconds]
metabulation has quit [Quit: Leaving]
<scripted>
Ok, I have no idea what the issue is but I'll continue on an old version
<scripted>
couldn't care less now
scripted has quit [Quit: WeeChat 3.5]
<mrvn>
self.set_modern_visibility(False)
<mrvn>
ups
<nomagno>
Macros and subroutines are really almost-equivalent ways of factoring out stuff most of the time
<mrvn>
macros are evil.
<clever>
untyped macros are evil
<clever>
some languages have typed macros, others just go hard on inlining support
<mrvn>
well, we were talking C preprocessor :)
<clever>
yeah, #define can be real ugly
<clever>
the only time i really like using it, is for either constants, or for reusing local vars without having to pass them by reference constantly
atrapa has joined #osdev
<mrvn>
you can use enums for that
<clever>
but its not just a constant int
<mrvn>
class enums are even better because you can limit what constants can be used where
<clever>
its in the form of `*((uint32_t*)0x12345678)`
<clever>
an enum cant do that
<mrvn>
const works too
<clever>
and depending on the target, it may constexpr itup, doing `0x12345678 - const + const` or even `0x12345678 - cost + var`
<bslsk05>
github.com: rpi-open-firmware/hardware.h at master · librerpi/rpi-open-firmware · GitHub
<clever>
mrvn: and what about this example?
<clever>
when compiling to the vpu, the macro just casts the addr into a pointer, and immediately dereferences it
<clever>
when compiling to baremetal arm, it will apply a constant offset, which the compiler will do at compile time
<clever>
when compiling to userland arm, it uses a global variable as an offset, so you can mmap /dev/mem
<clever>
mrvn: how would you do that differently?
Matt|home has quit [Ping timeout: 260 seconds]
heat has joined #osdev
<mrvn>
clever: I would like to do it as constexpr function but you can't do that.
<mrvn>
but there is no reason this couldn't be a normal function.
<mrvn>
With volatile being deprecated and having to use the volatile access functions making this function is much more reabable.
<mrvn>
s/much//
<mrvn>
clever: On that URL why does the RamSize enum have no 8GB value?
sonny has joined #osdev
knusbaum has quit [Ping timeout: 272 seconds]
knusbaum has joined #osdev
Likorn has joined #osdev
Likorn has quit [Client Quit]
freakazoid12345 has joined #osdev
sonny has quit [Remote host closed the connection]
sonny has joined #osdev
sonny has quit [Remote host closed the connection]
sonny has joined #osdev
sonny has quit [Remote host closed the connection]
freakazoid12345 has quit [Ping timeout: 260 seconds]
<clever>
mrvn: the 8gig model didnt exist when i last edited it
<clever>
and there are no ddr4 drivers yet, so it hasnt had to actually support it
<zid>
macros being typeless is what makes them useful, when people do typey stuff with them they become problematic
<j`ey>
typeof(x)!
<heat>
templates
<zid>
MAX(a, b) is a nice macro, DO_THING_TO_STRUCT_X(x) not so much
* geist
yawns
<geist>
good morning germs
<kaichiuchi>
hi
<heat>
wrong, it's evening ya doofus
<heat>
look out ya window!
<mrvn>
zid: MAX(a, b) is horrible if a and b don't have the same type
<moon-child>
why? Should promote
<moon-child>
problem is effects, not types
<mrvn>
moon-child: because you easily get odd results.
<geist>
oh there's the class double evaulation issue
<geist>
classic
<mrvn>
MAX(a++, b--)
<geist>
re: the old discussoin of inline and C, I think it's mostly because inline didn't become a real keyword until C11 or at least C99
<geist>
and it took a while for folks to really start utilizing it
<geist>
i do remember the whole inline vs static inline vs extern inline being a mess in the early/mid 2000s
<mrvn>
and people misused it to mean something else and now it means that
<geist>
so i'm starting to think maybe it was C11?
<heat>
inline doesn't actually mean inline
<mrvn>
geist: I think inline has been around since C99 or even before.
<geist>
yeah but there was some underspecified about it until later. in the mid 2000s i remember it was a real crapshoot if your compiler supported it right, or did what you expected
<mrvn>
inline doesn't mean anything useful in C is a pretty good summary
<geist>
ie, between MSVC and gcc and whatnot
<geist>
but worse it would create a linkage issue, independent of if it inlined or not, so there was i remember some amount of danger about it
<geist>
but i think that got firmly resolved in C11
<mrvn>
geist: does C11 have the ODR rule?
* geist
shrugs
<geist>
alls i know is it's safe to use now, and has been for a while
<bslsk05>
en.cppreference.com: inline function specifier - cppreference.com
<geist>
in that you pretty much always want to static inline in C but in C++ there are places where you can simply inline
<geist>
but especially headers that may be used in either languages you probably want to static inline
<geist>
static vairables inside inline functinos are a complex mess that i just avoid
<geist>
the downside i've seen, if you're looking for very small binaries, is a static inline function in C in a header file may still end up getting stamped out multiple times in the binary, and it wont merge them, because of the ODR rule
vimal has joined #osdev
<geist>
since it's free to not inline them, and then it becomes a local static function with local linkage so the compiler wont merge multiple copies
<kaichiuchi>
funny you guys mention inline, I had a weird thing yesterday
<kaichiuchi>
a function that was just `return (index * 2) + 1` wasn't inlined by the compiler
<kaichiuchi>
the compiler being clang :(
<geist>
huh. what optimization level were you at?
<kaichiuchi>
-O2
<geist>
huh was a function poitner taken to it?
<kaichiuchi>
nope
<geist>
odd
<geist>
but usual caveat: inline is just a hint
<heat>
alwaysinline best inline
<geist>
there are further attributes you can put that try to hard force it, which seem to work most of the time
<geist>
yah
<heat>
also nothing a good lto can't solve :P
<mrvn>
geist: Huh? The ODR rule says it merges the copies.
<geist>
mrvn: yeah but i dont think there's an ODR rule for C
<geist>
vs C++. the page i linked talks a bit aobut it, though obliquely
<mrvn>
heat: if it's not inlining it in the header then LTO shouldn't inline it either.
<heat>
lto inlines everything lol
<heat>
functions get flattened to shit
<mrvn>
geist: ahh, yes. I fear in C the inline / static inline is still a mess.
<geist>
right it would degrade a static inline to just a static function
<heat>
my x86_cpu_init() function turns into a mix of everything it calls, it's brilliant
<geist>
and now you have multiple static functions with the same name, and the compiler wont merge those because of no ODR
<geist>
(in C)
<geist>
heat: depends on if you consider that good or not. it's neat, but not if you'er trying to debug something
<mrvn>
geist: C static functions should be annonymous basically
<heat>
geist: yup, I wonder how you googlers debug user crashes since you like lto so much lol
<geist>
heat: we dont link the kernel LTO
<mrvn>
and if you have two function with the same name but different code: *BOOM* Who knows what will happen.
<geist>
but yeah user crashes? pretty hard
<heat>
1) why? 2) yeah I was talking about googlers in general
<heat>
like chrome and whatnot
<geist>
but with a full debugger with full dwarf, etc it is doable
<mrvn>
With LTO you also get functions with specialization and not just inlines.
<geist>
most of the time kernel crashes we have less facility to debug so we dont use LTO
<geist>
but partially it's because LTO doesn't seemt o help the kernel that much, and it's been generally buggy (LTO codegen for zircon)
<heat>
o really?
<geist>
and it takes a good minute to link the kernel, which is a super drag
<geist>
thinlto is a good compromise, but it still takes i think 45 seconds or so to link
<heat>
one thing I've noticed is that it makes my kernel *smaller*, which is nice
<mrvn>
For my kernel I have barriers to LTO I can enable in every directory. So all my string functions in lib/string/ get LTOed internally but stuff outside doesn't inline them.
<geist>
in general full LTO is unstable on the zircon kernel, for reasons that no one has had the time to debug aside from identifying codegen bugs in the compiler
<geist>
but i think thinlto is getting all the attentoin in clang, and probably has the future
<mrvn>
geist: odd. The codegen should be the same, it's just a larger input file.
<geist>
i think that's fairly stable codegen wise for the zircon kernel, but i think we've seen regressions from time to time
<geist>
gotta remember we roll the compiler like every week or so, so we're running pretty much mainline llvm
<mrvn>
geist: are you using -O2 or -Os?
<geist>
but yeah at some point someone will have the time to take point and make thinlto the default on the kernel. informal benchmarking i dont think showed a huge improvement, and since we manually backtrace most of the time for crashes and whatnot, its probably not a net win
<geist>
mrvn: -O2
<mrvn>
What does thinlto do?
<heat>
it's slightly worse but way faster
<heat>
also multithreaded
<geist>
it's a different mechanism for LTOing. one that's not global. i think gcc has a new thing thats roughly equivalent
<geist>
yah it basically divides the program into what it thinks are islands of code and then parallel LTOs within that
<geist>
the global selection algorithm is apparently pretty good
<geist>
also gotta remember we compile with a lot of anti-meltdown and whatnot switches and i suspect those are what interacts badly with LTO
<geist>
so we kinda push the edges of the compiler in specific ways
<geist>
predictably iirc LTO is buggy more on x86, because we have more switches for that
<mrvn>
geist: Do you have many small functions that aren't in headers that could be inlined across compilation units? Or functions in other compilation units that get called with constants?
<geist>
not really. if anything i think we aggressively over inline
<geist>
which is why i also think the LTO codegen isn't a huge win as it could be in our case
<mrvn>
that kind of makes LTO pointless
<geist>
right. remember the kernel is in C++, and we use fairly standard classes with lots of inline accessors and whatnot
<mrvn>
I kind of go the reverse. Not inline anything and let LTO do the smart thing.
<geist>
and a fair number of template only, mostly inline container classes, etc
<kaichiuchi>
i'm sorry to ask this question almost, but why was C++ chosen for the kernel anyway?
<geist>
vs what?
<heat>
r u
<heat>
s t
<kaichiuchi>
well, the traditional choice: C
<geist>
(there's always a versus, because everything is a tradeoff, or a compromise)
<kaichiuchi>
(no i'm afraid I wouldn't suggest Rust :p)
<mrvn>
kaichiuchi: C has verry bad generics (void * sucks)
<geist>
ah well, mostly because we feel that we're competant enough C++ programmers to use it wisely, and i think we generally are
<heat>
C is objectively worse than C++ if you don't need the portability
<geist>
kaichiuchi: well, the rust answer is different: first and foremost rust was not stable enough in 2016
<geist>
c++ is really a fine language for kernels, since kernels are usually fairly OO anyway. it's a good match
<geist>
you just have the usual use-it-wisely and having to deal with programmers that wont use it, dont like it, use it badly, etc
<heat>
linux does OO by hand
<mrvn>
kaichiuchi: c++ gives you templates, better type safety, RAII. It's well worth it even without RTTI and exceptions.
<j`ey>
_ops
<geist>
also it started out as C, since its a fork of LK
<geist>
so over the years we morphed it into C++
<kaichiuchi>
i've always had this sort of debate in my mind about C vs C++ for things today, and each time I think C is good, modern c++ just comes in and kills that notion
<geist>
but the deeper you go you get into more C like constructs
<kaichiuchi>
mrvn: all valid points I'll admit
<geist>
yah i'm slowly implementing new parts of LK in C++
<geist>
but sticking with C only APIs for all the modules
<kaichiuchi>
it's just because if you're writing stuff in C++, it might be harder to visualize what the compiler will generate
<heat>
do you need to? can you?
<mrvn>
kaichiuchi: other than template hell I don't really feel that's true
<geist>
yah but i agree that visulizing what it does is really important
<mrvn>
class methods might even be simpler to visualize than doing OO by hand in C.
<geist>
at least for me, and one of the reasons there's a blurry line where C++ turns into Fancy C++ where you can no longer sense what it's going to codegen
<mrvn>
Where is does get tricky is when you include move semantic from c++11 to c++20.
<geist>
and it's fairly subjective, and different based on the eye of the beholder
<mrvn>
Will this copy? will this move? does it elide the copy on return? WTF will this do?
<geist>
yah agreed. move semantics are an incredibly powerful tool but it starts to get harder to predict things in lots of contexts
<geist>
will it use move here and do it efficiently? or not?
<geist>
yah
<geist>
when it does it's fantastic
<mrvn>
It kind of helps if you have objects that can only move or only copy but not both.
<geist>
but i always worry about highly implicit situations where it would easily fall back to something much worse based on some context
<geist>
like, i dunno, suddenly an object becomes unmovable because some new member was added to it that wasn't, etc
<geist>
codegen changes for the worse and no one knows
<kaichiuchi>
see, the way I view it is computers don't have any notion of anything whatsoever related to OO
<kaichiuchi>
*however*
<geist>
i dunno, i think the notion of a 'struct' of memory with a base register and accessing things that are offset from it is pretty natural to register based arches
<geist>
it's even very efficient due to caching behaviors and locality and whatnot
<mrvn>
I've been using "this" since 1990 or so even in Amiga Basic and Pascal.
<geist>
of course is it because modern arches are designed after this pattern (vs say stack based arches)? probably
<geist>
dog chasing the tail for 40 years you end up with what we have
<kaichiuchi>
(doing my best to word this properly), I can't deny C++ makes a lot of things easier for everyone involved
<mrvn>
kaichiuchi: constructors and destructors and RAII as an extension to that is probably you biggest friend in the kernel when picking c++. It avoid so many bugs.
<geist>
unrelated: I think i'll write a 68k emulator today
<heat>
refcounting by hand is painful
<geist>
been meaning to, looksl ike fun. though clearly it's a lot of opcodes to deal with
<heat>
especially if you don't have many eyes on your code
<mrvn>
geist: only 65-70% of the 65536 possible opcodes.
<geist>
mrvn: agreed. even if you just write C style C++ using RAII for locks and wehatnot is a godsend
<geist>
mrvn: heh, but most of them are just mods on a single opcode. that's always the fun part: finding which ones are the same thing
<mrvn>
geist: unless you forget to give the lock guard a name. :)
<heat>
what's a good lightweight irc client with tls support?
<kaichiuchi>
it's kind of hard to argue my position when you guys are giving me solid counterarguments >:(
<kaichiuchi>
(that's a joke)
<mrvn>
geist: a lot of bits are the addressing mode. A single memoonic can cover a lot of the opcode space.
<kaichiuchi>
i'm on quassel-monolithic, buuuuuuuuuut i'd hardly call that lightweight
<heat>
need it to be terminal based
<heat>
i've looked at weechat but it has a lot of deps
<mrvn>
kaichiuchi: look at freestanding c++, then maybe drop rtti and exception as well. That's what most embedded / kernel programmers use.
<kaichiuchi>
irssi
vimal has quit [Remote host closed the connection]
<kaichiuchi>
yeah I never ever ever use RTTI or exceptions
<geist>
heat: prior to switching to irccloud i used irssi for like 15 years
<geist>
and its still pretty solid. irssi + screen is a good longliving solution
<kaichiuchi>
same
<kaichiuchi>
but irccloud and texual on mac/quassel-monolithic on linux is beautiful
<geist>
i finally just gave up and started using irccloud and it's been decent
<mrvn>
In most cases std::optional is better than exceptions. Or the std::value-or-error-thingy
<kaichiuchi>
textual*
<geist>
mrvn: i've also been generally happy with lightweight lambdas if nothing else to avoid having extraneous functions used for some callback purposes
<geist>
ie, lambdas that can be marshalled as functions
<mrvn>
And unpacking of return values in c++ is also great. No more out parameters.
<heat>
geist, ACK. i'm looking for a good client to port
<mrvn>
geist: lambdas with their capture are way better than having a callback + void *private all over the place.
<heat>
i was using sic but it's very simple and very crap
<heat>
also no tls
<geist>
mrvn: totally
<mrvn>
probably optimize better too
<heat>
template<typename Callable> void for_every_*(Callable c) is my favourite idiom
<heat>
lightweight std::function
<geist>
yep. use that pattern all over the place in zircon. useful for things like 'for ever page in this virtual memory object'
<geist>
have used it for some read/write routines too, where you write the function that loops through the things once, and provide a different routine for reading vs writing
<geist>
as an experiment i wrote the mmu code for riscv using that pattern in LK, and it kinda worked, though i think it's probably too complicated for its own good
<geist>
basically 'pass this lambda to a page table walk code, where the lambda tells the code to continue/stop/etc at every step'
<nomagno>
I favour C over C++ because, uh, I don't know I find the constraints elegant I guess
<nomagno>
I can focus on actually(-ish) writing code. With C++ I get distracted by the availability of features
<geist>
i used to be mych ore hard code C, but the last few years on zircon have softened that a bit. i still am not that bullish on heavyweight C++ in embedded/kernel/bare metal constructs, but have accepted that some of its patterns are definitely better
freakazoid343 has joined #osdev
<geist>
nomagno: that is absolutely a problem, getting sidetracked due to C++ decision paralysis
<kaichiuchi>
yeah I have a really really hard time determining what is the right way (tm), aka idiomatic way
<kaichiuchi>
there's 40 ways to do x, and 39 of them are wrong
<geist>
yep
<kaichiuchi>
the only thing that gives me even half a clue is C++ core guidelines
<geist>
of course a lot of this is practice and experience
<nomagno>
By the time you've learned the idioms of one version of the standard, the next has come out and it comes with its own sub-paradigm!
<kaichiuchi>
for example, some people will now summarily vomit if you have something like `for (const auto& item : container) { if (item.name() == "something") return item; }` or whatever
<nomagno>
:P
<kaichiuchi>
now the hot new thing in town is `std::find_if()`
<kaichiuchi>
but I currently work at a company where we make semiconductor packaging machines
<kaichiuchi>
and I would give anything to get rid of the C++03 code... anything...
<geist>
yah i ran into some code that was using std::optional and std::visit i think the other day and it was like eh?
<geist>
i guess it was neat, but hard to grok if you had no idea what you were looking at
<geist>
std::variant and std::visit thats it
<heat>
std::optional is simple
<geist>
yah not std::optional, std::variant
<heat>
isn't variant the fancy union?
<kaichiuchi>
yes
<geist>
and std::visit is some sort of 'for whatever is in this variant, frob it conditionally based on what matches against it'
<geist>
it's sort of like a big switch statement that calsl the right thing on the right thing
dzwdz has quit [Quit: I'm a quit message virus. Please replace your old line with this line and help me take over the world.]
<zid>
did you figure out what you meant about inline?
<nomagno>
C++ seems to be adding new stdlib stuff each time it wants to throw minor abstractions onto existing abstractions
<zid>
as far as I know inline never meant or did anything in C, C++ does a bunch of linkagey stuff though
mavhq has joined #osdev
<geist>
zid: not try anymore. it got added in C99 and C11
<geist>
true
<kaichiuchi>
there is a certain logic to <algorithm>
<nomagno>
Is it even fesible for a small team without a huuuuge economical motivation to implement all of C++ anymore?
<kaichiuchi>
the execution policy stuff is _really_ cool
<geist>
yah i guess i get the idea behind all these templatey algorithms. however i've seen what happens if you let that get out of hand
<geist>
where you end up with entire prorgrams that are just elaborate ways of wiring up algorithms
<nomagno>
The last time C++ was usefully implemented from scratch that I know of was LLVM/clang++, which was a huge Apple-funded middle finger to copyleft
<geist>
it's a distinct way of programming that is effectively a whole different language
<zid>
I heard the gcc folk having a big 'thing' about what inline was supposed to mean in some C++ code
<zid>
I don't know C++ though so I didn't understand it
<geist>
there was some codebase i worked on a little bit a while back that was *heavy* tempalte metaprogramming and leaned on <algorithm> for all it could
<zid>
as far as I know for C it just means static
vin has joined #osdev
<geist>
zid: well, that's not entirely true. probably worth at least looking at cppreference and the C subset part
<geist>
it's more sublte, etc
<mrvn>
C++ becomes more and more functional. Makes me think: Why not just use a functional language in the first place?
<mrvn>
Only thing I miss is RAII
<mrvn>
zid: In C inline means: Hey compiler, make more of an effort to inline this please.
<zid>
"inline says a function should be fast, what this means is nothing. A function declared inline is known as an inline function and must be defined in the same TU" is what c99 appears to say
<geist>
C11 may have scoped it better
<zid>
and if both an extern and inline dec are observed, IDB which one gets called
<geist>
right, that's why it's subtle. you probably almost always want `static inline` in C
troseman has joined #osdev
<zid>
oh right yea maybe that was what I gleaned from the convo
<geist>
since it may or may not inline it and if it doesn't then you dont get a linkage collision between .o files
<zid>
"This is underspecified but literally doesn't matter because nobody writes C like this, only C++"
<mrvn>
zid: in C if two compilation units see an inline function then it must be static I believe.
<zid>
where they slap inline on stuff that isn't static
<geist>
well, to be fair this is where people are simply not reading the spec
<geist>
there *is* a way to use it properly, and it does involve doing this or that
<geist>
but it's also a case where C and C++ are slightly different, and since lots of folks dont write C, they use the C++ idiom where they should be doing the C thing
<geist>
(ie, () vs (void), etc)
<zid>
I found out why I see char* so much, the C++ spec uses char*, char* , and char * at random to 'prove' it doesn't matter, and some C++ people have decided to differentiate pointers and references via spacing
<heat>
also () vs (void) is a pretty odd detail that no one talks about when teaching C
<zid>
and they've then gone to write some ugly C using it
<zid>
I talk about it :P
<mrvn>
That () vs (void) thing should have been removed from C ages ago. Implicit prototypes are just plain broken.
<zid>
It's actually relevent to codegen now we're all on amd64
<mrvn>
zid: it is?
<zid>
() needs an xor rax, rax
<geist>
i vaguely remember that the new C spec may formally remove it or something?
<zid>
Yea I think I heard that
<gog>
static inline void gog(void) {puts("mew");}
<mrvn>
zid: how does (void) avoid that?
<geist>
otherwise there are command line switches to defacto remove it and replace with a warning
<zid>
but it's 20+ years late
<geist>
with () it ends up being effectively a varargs, and x86-64 ABI has the extra 'eax holds the number of float args' thing
<zid>
I will still do it because the moment it releases 99.9% of code is compiled in gnu99 is still compiled gnu99
GeDaMo has quit [Remote host closed the connection]
<nomagno>
geist: however the variable args aren't accessible
<zid>
Maybe in 40 years C2x will be de-facto
<mrvn>
geist: and with (void) eax may still hold any value.
<nomagno>
My only grudge with C variable argument functions is how declaring a function prototype (...) Is part of the LANGUAGE SYNTAX, but accessing the arguments is part of the STANDARD LIBRARY
<nomagno>
Like, why!!!
<heat>
because fuck you that's why
<mrvn>
nomagno: compiler defined code
<gog>
nomagno: it's part of the freestanding library now so it's slightly better
<bslsk05>
www.mankier.com: trap man page - POSIX Commands | ManKier
<zid>
-mno-redzone is similar, thing you want for kernel code that isn't the normal abi
<heat>
isn't there a trap that traps any exit?
<clever>
heat: yes
<mrvn>
zid: redzone was a mistake in the first place I think
<mrvn>
heat: on-exit?
<gog>
computers were a mistake
<zid>
So was I
<geist>
note the rax on varargs is also from the same ABI, so my guess is whoever at AMD helped design the ABI was hot to trot for fancy new features
<heat>
mrvn: yes, any single exit, even if a signal
<mrvn>
heat: no, the on-exit signal
<moon-child>
what's wrong with redzone?
<geist>
for one thing it's totally incomptable with kernel code
<geist>
for a variety of reasons
<moon-child>
1. doesn't fred handle that?
<mrvn>
moon-child: it only helps functions large enough that modifying the stack would be free anyway at the cost of making signal handler having to adjust the stack for the red zone.
<geist>
for user space it's alright. i dunno if there are actual measuable performance differences
<moon-child>
2. so, turn it off in the kernel, but what about userspace?
<zid>
I want a fred cpu :(
<heat>
ok I think it's EXIT
<geist>
i discovered another intractable problem with red zone and ring 0: pushing/popping flags on the stack
<moon-child>
that's 'another' problem?
<geist>
which is a common idiom in kernel space since there's otherwise no way to get to eflags
<moon-child>
oh nvm
<geist>
if you were using red zone it'd trash the red zone every time you do that
<mrvn>
geist: why would you do that in user space?
<moon-child>
I thought you meant the automatic pushing/popping of flags it does when you get an interrupt, not doing it manually
<geist>
weithout red zone whatever is below the stack is fair game, so even if you temporarily push/pop, as long as you do it in a code sequence with nothing else you are okay
<geist>
mrvn: kernel space
<geist>
it's another reason i discovered a whiel back that red zone is incompatible with kernel code
<mrvn>
kernel space can't have a red zone if interrupts are enabled.
<zid>
can't redzone on a stack you might take an interrupt in
<zid>
is 'the problem'
<geist>
yes. catch up mrvn
<mrvn>
so not sure how you would ever run into the eflags issue.
<geist>
yes. i was outlying a *second* reason you can't use redzone in the kernel. aside from the interrupt problem
<geist>
you can use interrupts in the kernel if you use ISTs though, technically
freakazoid343 has quit [Ping timeout: 245 seconds]
<geist>
the eflags issue is *extremely* common in kernel code
<clever>
i cant see how you could deal with redzone and irq's properly
<geist>
it's the only way to read the current interrupt status
<clever>
decrementing the sp far enough requires a gp reg right?
<clever>
enless you can do `sub sp, sp, 0x4000`?
<geist>
since you otherwise can't get to eflags as a regular register
<mrvn>
clever: ISTs allow running IRQs on their own stack.
<clever>
and if you cant manipulate sp directly like that, you have no way to preserve the other regs
<geist>
yah you could put all irqs on an IST and then technically avoid the issue
<clever>
mrvn: yeah, thats one way around it, hw stack switching
<mrvn>
clever: only way I believe.
<clever>
yeah
<geist>
i *guess* you could also push the sp down past the red zone, then pushf, popf, and put it back
<mrvn>
Now on ARM/AArch64 you could have a red-zone since the CPU doesn't push anything on the stack.
<mrvn>
You can adjust the stack yourself, switch stacks or even run completly stack-less in the IRQ.
<geist>
anyway, dunno how fred would solve the red zone issue, honestly
<clever>
but how do you preserve the interrupted sp, while switching stacks?
<mrvn>
fred?
<geist>
i think all fred generally does at that level is push a large chunk of state on the stack, much more like 68k IMO
<geist>
and has less exception vectors
<clever>
from what i know, st can only store relative to an addr in an existing register
<mrvn>
clever: banked registers
<clever>
so you cant save the old sp to ram
<kaichiuchi>
what is this "fred"?
<clever>
ah right, arm32 banking, but didnt aarch64 get rid of that?
<geist>
clever: not entirely. SP is banked
<clever>
ah
<mrvn>
clever: and you have special thread registers in the CPU you can allocate for that use case.
<geist>
it's kinda neat. cleans up a lot of the arch
<geist>
if/when they finally implement it at least
<nomagno>
Is it possible to implement a modern OS with its multitude of processes with only cooperative multitasking
<nomagno>
?
<geist>
implement an OS, yes. implement a modern OS, no
<nomagno>
Better questions, are there any examples?
<mrvn>
nomagno: possible? yes. stupid? still yes
<geist>
there are certain assumptions of preemptiveness in modern OS designs
<geist>
if nothing else because programming models assume preemption
<mrvn>
I would have hoped cooperative multitasking died with windows 3
<mrvn>
geist: uhoh. Then I'm in trouble with my 100s time slices. :)
<mrvn>
If anything breaks in your programming model because the multitasking is cooperative then I think your code is buggy.
<mrvn>
Like do you start 2 task and have one assume the other finished already because you did a lot more work in one task than the other?
<geist>
so looking at the 68k opcodes, really bit 15-12 are a 4 bit opcode field that generally breaks things down into at least instruction forms
<geist>
well, or at last most of those opcode groupsh ave a consistent form, except for a few that require more parsing
<mrvn>
geist: sound right. Then you have op1 and op2 addressing modes or just op1 or op2 or none depending on the 4 bits.
<mrvn>
1 of the 16 is for the FPU.
<geist>
yah 1111 is for coprocessor stuff
<gog>
1111
<geist>
from looking at it if you parse bits 15-8 you realy get most of them, but the opcode group 0 instructions put a register in those
<geist>
and of course a large chunk of the instructions use bits 5-0 to encode an Effective Address, which then implies additional words in some cases. but is at least generic
<geist>
trying to decide if i should start with a table with structs that partially decode things, and then within that subdecode
<geist>
or a brute force nested switch style mechanism
<mrvn>
geist: it's pretty well ordered. You can just make a lookup table for which opcodes belongs to which addressing group and have them decode the args all with the same code.
<mrvn>
reg, reg. reg, mem. ...
Likorn has joined #osdev
<geist>
yah question is how wide to make the table. clearly 64k entries is a bit mcuh (unless using some sort of run time expansion) but 4 bit decode table isn't really useful either. thinking 8 bits gets you most of the fairly well decoded instructions, with a few of them needing further subdecoding
<mrvn>
geist: 4 bit
<geist>
4 bit is not worth a table, that's just a switch that subdivides into subdecodes
<geist>
but that's also a probably viable strategy. it's the 'table vs switch' pattern trying to decide on
atrapa has quit [Quit: atrapa]
<mrvn>
the 4 bit should tell you if you have 0, 1 or 2 arguments to decode. Then decoding those tells you how many extra words you have behind the opcode.
<geist>
not sure about that. i'm looking at the opcode breakdown in the 68k programmers manual and there are an awful lot of exceptions to that rule
<geist>
or maybe just opcode group 0, which seems to be the dumping ground of complicated things
<mrvn>
like?
<geist>
on the things that involve SR or CCR registers, RTM instruction
<geist>
CMP2, CHK2. take an additional arg
<geist>
BTST, BCHG, etc goes on
<geist>
lots of those instructions have an EA and then maybe an extra arg or two based on the instruction
<geist>
which is mostly fully decoded if you look at the first 8 bits in those cases
<geist>
but once you get out of group 0 it looks a bit more regular
<geist>
though looksl ike exceptions in group 0100: EXT, LINK, SWAP, BKPT
<geist>
oh and the MUL instructions which have like 3 or 4 args
<geist>
yah i think this is a complex enough ISA that a table driven approach may not work well. probably a heirarchial decode is in order
<CompanionCube>
isn't riscos still cooperative, does that count as modern?
<mrvn>
geist: I think most of that stuff is 680x0 for bigger x.
<mrvn>
They had to fit that into gaps when they extended 68000
<geist>
sure. i'm looking at the generic 68k programmers guide. which i think is up through 68040. i should see what plain 68000 looks like
<mrvn>
I want one of the military spec 80MHz 68060.
<mrvn>
Just for that little extra boost in speed.
xenos1984 has quit [Read error: Connection reset by peer]
<geist>
dont get me wrong, this is still an order of magnitude more straightforward than x86 from what i can tell
<geist>
even x86 at the time, which would have been 486 era
<mrvn>
worlds simpler
<geist>
yah having a consistent 16bit word wise decode helps immensely since they had enough bits to actually be fairly regular
<clever>
is arm similar?
<clever>
given it has a fixed 32bit opcode size, for both 32 and 64 (ignoring thumb)
<geist>
not really. arm32 up through about arm3 was i think pretty simpler
<mrvn>
geist: you have a 16bit data bus from the start so you don't have to fetch single bytes to decode opcode bits
<geist>
but they really painted themselves into some corners, and by the time armv4 came along they were really starting to hack up a bunch. the decode logic for classic arm32 is not particularly clean, especially by the time you got through armv7
<mrvn>
clever: I think ARM is even simpler since you don't have the extra 2, 4, 6, 8 byte data attached to the opcodes
<geist>
the initial layout of the arm32 opcode space is not very clean compared to a more 'pure' looking risc machine designed to be decoded
<geist>
right, it's simpler in that sense, but in a cleanliness of how they packed in stuff to the 32bits they had, they didn't do a fantastic job. arm64 is a bit cleaner, but i thik it was born into an era when they didn't care so much for simplicity of the decoder
freakazoid12345 has joined #osdev
<geist>
vs something that really does, like say Alpha, or microblaze. which look positively trivial to decode
<geist>
riscv is kinda in the middle. it's simple to parse, but has a few strange decisions that on the surface make it harder, but really are designed for hardware folks (notably the way immediates are sliced up all over riscv)
<bslsk05>
en.wikipedia.org: DEC Alpha - Wikipedia
<geist>
though i've seen ones that have even less formats than that
<geist>
really the key is how many different discrete instruction forms do you have and how do you reuse them
<geist>
what arm32 did that
<geist>
that's particiluarly wasteful is they burned 4 bits at the top for conditional stuff, so now theyeffectively have 28 bit opcodes
<geist>
and then a large chunk of the bottom of the instructions are burned for the barrel shifter for argument 2
<geist>
which is super neat, but uses a lot of space
<geist>
and they didn't leave themselves a lot of unused space in the initial stab, so as new things came along (multipliers, divide, byte/16bit load/stores) they started cramming those into spaces like invalid encodings from the initial stab
<clever>
VPU has both 16bit, 32bit, and 48bits of the same `mov r0,0x12` opcode, dynamically picking the right one for the immediate size
<clever>
at the cost of a dynamic opcode size, you can comptact things more
<geist>
yah riscv understands this and is far better at carving off unused space at a top level and whatnot
<geist>
and elegantly handles the variable opcode size stuff
<clever>
the 16bit opcode form, even sacrifices 1 bit of the register#
<clever>
so it can only reach half the registers
<geist>
yep RV does the same thing: 5 bits of registers gets shrunk to 3 for 16 bit instructions
<geist>
which picks out 8 of the 32 registers as the working set
<clever>
but there is also a shifter built in
<geist>
i think r8-r15 iirc
<clever>
it basically stores the immediate as 0x12 << 8
<clever>
so the dead bits arent actually stored
<geist>
indeed, even the r8-r15 thing you can just implement as hard coding 01 as the upper register selection bits in hardware
<geist>
i think arm really missed an opportunity to do a compressed form of arm64 but it was there call
<geist>
their call even
<mrvn>
ram is cheap
<geist>
most likely they were thinking that if you really needed a mixed environment you could run EL0 as arm32 and use thumb there
<geist>
and over a few years everything would transition to 64bit
xenos1984 has joined #osdev
papaya has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<heat>
alright, compiling irssi now
<heat>
meson is actually pretty neat to cross
<heat>
it needs a cross-compilation file which defines cflags, cc, pkgconfig stuff
<heat>
this is new lol, irssi's git uses meson, the release uses autoconf
freakazoid12345 has quit [Ping timeout: 240 seconds]
elastic_dog has quit [Ping timeout: 252 seconds]
mahmutov has quit [Ping timeout: 260 seconds]
elastic_dog has joined #osdev
nyah has quit [Ping timeout: 260 seconds]
Likorn has quit [Quit: WeeChat 3.4.1]
Burgundy has quit [Ping timeout: 260 seconds]
Vercas has quit [Quit: Ping timeout (120 seconds)]
Vercas8 has joined #osdev
<klange>
heat: a lot of stuff uses one build system for git builds but autoconf for release tarballs
<heat>
i wanted to connect to it with my OS but I'm not logged in
<klange>
Then log in (you can auth to libera over a non-TLS connection by messaging nickserv)
<nomagno>
Performance -99 but if you terminate all your function statements with $ instead of ; you actually get preemptiveness, tough not real time
<klange>
Signals are in C99, but only a limited set. With setjmp and a SIGINT handler, you can do pure C99 preemption by having the user hold ^C ;)
Ram-Z has quit [Ping timeout: 272 seconds]
<nomagno>
klange: that's POSIX C99 tho isn't it?
<klange>
No. C99 has all of that all on its own.
<nomagno>
My thingy is more freestanding, in my defense
<klange>
All the other signals in C99 are exceptions, SIGINT is the only soft one. If you have POSIX, you can use alarm() to enforce a periodic time signal.
heat-onyx has joined #osdev
<heat-onyx>
hello
<heat-onyx>
this would be a great screenshot if my vt emulation didn't suck
<heat-onyx>
i need to re-connect over the serial tty
<zid>
How sucky
heat-onyx has quit [Quit: leaving]
<zid>
at least it was a quit not a segfaulkt
<klange>
The last time I tried to port irssi, it was cranky about terminal support and I didn't have scroll regions at the time... but that was a while ago.
<klange>
Also I didn't have a standard sockets API, so...
heat-onyx has joined #osdev
<heat-onyx>
HELLO
<heat-onyx>
I AM HERE AGAIN OVER SERIAL
<heat-onyx>
klange: yah
Ram-Z has joined #osdev
<heat-onyx>
tbf I'm missing quite a lot of stuff and my tcp is kinda broken
<heat-onyx>
but here I am baby
<klange>
you are, of course, a cheater using musl, though ;)
<heat-onyx>
hehehe
<heat-onyx>
cheaters sometimes prosper :P
heat-onyx has quit [Quit: leaving]
<heat>
i need an ssl implementation that can fit with my build system