klange changed the topic of #osdev to: Operating System Development || Don't ask to ask---just ask! || For 3+ LoC, use a pastebin (for example https://gist.github.com/) || Stats + Old logs: http://osdev-logs.qzx.com New Logs: https://libera.irclog.whitequark.org/osdev || Visit https://wiki.osdev.org and https://forum.osdev.org || Books: https://wiki.osdev.org/Books
parrott has joined #osdev
mahmutov has quit [Ping timeout: 272 seconds]
LostFrog has quit [Remote host closed the connection]
PapaFrog has joined #osdev
Likorn has quit [Quit: WeeChat 3.4.1]
Ali_A has quit [Quit: Connection closed]
Likorn has joined #osdev
PIKMN31467 has joined #osdev
PIKMN31467 has quit [Quit: Client closed]
theruran has quit [Quit: Connection closed for inactivity]
freakazoid333 has joined #osdev
Likorn has quit [Quit: WeeChat 3.4.1]
nyah has quit [Ping timeout: 260 seconds]
mahmutov has joined #osdev
mahmutov has quit [Ping timeout: 260 seconds]
<heat> ah great nap I just had
srjek has quit [Ping timeout: 260 seconds]
<heat> if I had a superpower I would very much like the ability to have naps whenever I want
sonny has joined #osdev
<heat> oh wait haha that was actually a fork bomb
<heat> wait no
<heat> that's not a fork bomb
<heat> it still waits for the job to finish no?
<heat> agreed
m3a has joined #osdev
freakazoid333 has quit [Read error: Connection reset by peer]
heat has quit [Remote host closed the connection]
heat has joined #osdev
freakazoid333 has joined #osdev
Ali_A has joined #osdev
Ali_A has quit [Quit: Connection closed]
gog has quit [Ping timeout: 260 seconds]
Ali_A has joined #osdev
<heat> https://warosu.org/g/thread/71487871#p71503692 <-------- ahah here's my 10 seconds of fame
<bslsk05> ​warosu.org: Please Wait... | Cloudflare
<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> ​'"The Linux Kernel Hidden Inside Windows 10" techtalk by Alex Ionescu' by ReactOS Community (00:52:29)
<sonny> it's still there? :D
<heat> yeah
<sonny> haha nice
<heat> you can still use wsl1
<heat> i genuinely cannot reproduce this fucking bug
<heat> jesus
joe9 has quit [Ping timeout: 260 seconds]
<sonny> are they any other famous windows devs like alex?
pretty_dumm_guy has quit [Ping timeout: 260 seconds]
<heat> alex is not a windows dev
<heat> but sure, gabe newell
joe9 has joined #osdev
<heat> raymond chen
pretty_dumm_guy has joined #osdev
<sonny> I thought he did the interals book with mark?
<heat> yes but he was never a windows dev
<heat> in fact he worked on reactos
<sonny> oh neat
<sonny> that's pretty crazy then ...
<sonny> that a windows book is written by folks outside microsoft
parrott has quit [Read error: Connection reset by peer]
GeDaMo has joined #osdev
sonny has quit [Quit: Client closed]
the_lanetly_052 has joined #osdev
mahmutov has joined #osdev
C-Man has quit [Ping timeout: 272 seconds]
Likorn has joined #osdev
m3a has joined #osdev
heat has quit [Ping timeout: 256 seconds]
papaya has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
xenos1984 has quit [Read error: Connection reset by peer]
freakazoid333 has quit [Remote host closed the connection]
Likorn has quit [Quit: WeeChat 3.4.1]
xenos1984 has joined #osdev
Likorn has joined #osdev
theruran has joined #osdev
wootehfoot has joined #osdev
C-Man has joined #osdev
vimal has joined #osdev
ss4 has joined #osdev
atrapa has joined #osdev
wootehfoot has quit [Ping timeout: 260 seconds]
wootehfoot has joined #osdev
ss4 has quit [Ping timeout: 260 seconds]
Burgundy has joined #osdev
Likorn has quit [Quit: WeeChat 3.4.1]
Likorn has joined #osdev
mahmutov has quit [Ping timeout: 260 seconds]
toulene has quit [Ping timeout: 260 seconds]
toulene has joined #osdev
atrapa has quit [Quit: atrapa]
scripted has joined #osdev
<scripted> Hello, I'm back. This time with enough sleep.
<scripted> So the value of mbd in kmain is 38144. It's the same in shell.c
m3a has quit [Quit: leaving]
<sortie> Yay sleep
<scripted> Okay, so the value of the members in kmain (where it's getting passed by the bootloader) is in fact 0 too.
<scripted> Something must've gone wrong while it's getting passed.
<mrvn> scripted: ignore them and parse the memory map.
<scripted> mrvn: What do you mean ignore them? How should I parse an empty memory map?
<mrvn> scripted: who says the memory map is empty?
<scripted> mrvn: the members value of the members are in fact 0
<mrvn> last I looked you only printed the low and high mem values.
<scripted> I just tried flags too
<scripted> it's 0 too.
mahmutov has joined #osdev
<scripted> something must've gone wrong in the bootloader
<mrvn> what's the url again?
<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?
<bslsk05> ​gist.github.com: boot.asm · GitHub
<scripted> that's what I did
<nomagno> I'm asking how y'all would find it
<mrvn> nomagno: horrible
<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
<FatalNIX> That is always fun
<scripted> anyways
<scripted> this is what I'm working on right now https://github.com/ScriptedDeveloper/CrazeOS/tree/unstable
<bslsk05> ​github.com: GitHub - ScriptedDeveloper/CrazeOS at unstable
<scripted> for some reason
<scripted> the flags and every member of the multiboot structure passed to kmain() is 0
<scripted> its in kernel/kernel.c
<scripted> kernel/boot.asm
<scripted> I would appreciate any help
<mrvn> scripted: and you are still not printing flags first thing in kmain
<scripted> mrvn: I did
<scripted> its 0
<mrvn> nope, not in the code.
<scripted> oh my fucking god
<scripted> do you want me to do it now on github?
<mrvn> obviously
<mrvn> can't help you with your code if you don't share it
<scripted> did it now
<FatalNIX> So what's the issue with this project anyways
<scripted> so
<scripted> the members of the multiboot2 structure are 0
<scripted> but the magic number is somehow passed correctly
<scripted> dont fucking know what I did wrong
<mrvn> how does the disassembly of kmain look? Is it getting the right value from the stack?
ZetItUp has quit []
<scripted> eh
<scripted> not sure how to do that
<gog> you have a multiboot1 magic number, you won't be given multiboot2 data structures
<mrvn> objdump -d
<mrvn> gog: everything is multiboot 1 as far as I see
<scripted> thats a lot
<gog> hm
<scripted> let me put it in a file
<bslsk05> ​gist.github.com: fuckery.txt · GitHub
<scripted> gog: how can I fix that?
<Mutabah> Have you printed the multiboot pointer? Have you checked the magic number at that address?
<scripted> I did print out the multiboot pointer
<Mutabah> scripted: Also, as gog/mrvn implied - this code is multiboot legacy/1 not multiboot 2
<scripted> using lltoa
<scripted> it was 31844
<Mutabah> That's... low
<Mutabah> Even if that's hex, it's low
<scripted> Mutabah: how in the cockfuckery can I fix that?
<Mutabah> Language.
<Mutabah> Please mind your language
<scripted> Sorry
<Mutabah> Also - You should write a `printf` impl, that `lltoa` method is using a hidden buffer so is not thread-safe (and kinda unidiomatic)
<Mutabah> Really, that multiboot mismatch it's not something to fix - multiboot1 is more common
<scripted> yeah I will do that after I took a vacation from this osdev fuc-
<Mutabah> if the magic matches, then all good.
<mrvn> scripted: it's obvious from the asm why it doesn't work. You aren't printing flags.
<scripted> mrvn: wait what
<mrvn> first think kmain does i call 112f <terminal_clear_screen>
<scripted> ah
<scripted> wait
<scripted> lol
<scripted> old compiled version
<FatalNIX> ...
<scripted> sorry
<scripted> oops
<FatalNIX> :)
<FatalNIX> We can't help you if you don't know how to manage your own code XD
<FatalNIX> I am one to talk though. I do shit like that myself.
<scripted> sorry that happens if you have like 10 neovim tabs open
<scripted> with the same file
<FatalNIX> heh
<Mutabah> Heh, you do this sort of thing long enough, and your first fix when things don't work is to close your editor and clean rebuild
<scripted> I edited it
<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
srjek has joined #osdev
<scripted> these are the registers
<scripted> Mutabah
<FatalNIX> You know I was just looking at my old C programming book from computer engineering
<FatalNIX> and I just realized the book completely lacks inline functions
<scripted> lol
<FatalNIX> It's enetirely absent from the index
<scripted> I think mine's lacking too
<scripted> https://imgur.com/a/cOpGWSM register ebx and eax
<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
<bslsk05> ​gist.github.com: boot.asm · GitHub
<scripted> this is at least giving me 10kb
<scripted> I think I will stop for today
<scripted> going nowhere
<FatalNIX> I was pretty sure ODR is a C++ thing
<moon-child> a.c: int f() {} b.c: int f() {}
<moon-child> ^ is illegal
<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: lk-overlay/v3d.c at master · librerpi/lk-overlay · GitHub
<clever> here is a different example
<clever> i'm printing registers, each time i print the name of the reg, and the value of the reg
<clever> and i stash the value in t, for optional further decoding
<clever> an inlined function cant do that, i would have to specify every register twice, as both a string and addr
<mrvn> when we have introspection we can remove the stringifying from the macro.
Likorn has quit [Quit: WeeChat 3.4.1]
<mrvn> the "#x" is something you can only do with macros right now.
<clever> #define GP_FSEL0 HW_REGISTER_RW( 0x7e200000 )
<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
<mrvn> That's the fix c++ has for the issue.
<geist> yah https://en.cppreference.com/w/c/language/inline talks a bit about the differences at the bottom, and it's more or less what i remember
<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.]
dzwdz has joined #osdev
mavhq has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
<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
<zid> because the C standard is 2 standards
<heat> zid: linux actually upgraded to C11!
<zid> one is the freetsanding and one is the hosted
<heat> that's the same with C++
<mrvn> nomagno: just passing arguments is outside the language syntax anyway.
<zid> and the freestanding one declares float/iso646/limits/stdarg/stdbool/stddef/stdint as part of C in all situations
<zid> not just cases where you have a standard library
<zid> ergo stdarg is part of C and not stdlib
<nomagno> gog: My personal definition for freestanding (more like 'embedded' but whatever) is stddef, stdint, limits
<geist> and yeah it's the float thing: https://gcc.godbolt.org/z/sP3qTzjM8
<gog> stdarg is now too
<geist> see how it puts 1 in eax if yuo call it with a float?
<nomagno> The three headers that ONLY contain macros
<nomagno> But yes, it's better
<nomagno> I said it's what I consider actually freestanding
<nomagno> The standard disagrees
<nomagno> That much is clear
<geist> that's varargs behavior. as far as i know x86-64 ABI is the only one that does that
<heat> C++ has a lot of stuff in freestanding
<heat> <exception>, <atomic>, <type_traits>
<mrvn> geist: ahh, that "xor eax, eax" is on the call, not inside the function.
<geist> yah because it's passing 'there are no floats here'
<gog> stdatomic is freestanding in C too
<geist> https://gcc.godbolt.org/z/xnhPqccKs is a better example
<nomagno> Well I was talking about C99 freestanding I guess
<gog> C99 was a mistake
<nomagno> Huh?
<gog> joking
<gog> sort of
<zid> heat: I saw something about a macro expansion leaking a definition or something that they could fix with a newer std revision?
<gog> VLA's were a mistake
<nomagno> It's on the cleaner side of standard revisions IMO
<zid> C99 allowing mixed declarations and // was also a mistake
<nomagno> VLAs being mandated was a bit iffy
<gog> nah // comments are good
<heat> zid, yup
<heat> it's because you can't declare variables inside for loops
<heat> so the variable leaked outside of the for
<nomagno> I don't use //, but I wouldn't go so far as to not support them.
<nomagno> They're like 3 lines of code
<zid> Yea that's the sole used of mixed decs I ever allow
<nomagno> Less effort to implement in the preprocessor/parser/whatever than /**/ comments
<zid> Just because I get to rationalise it as being part of the if
<nomagno> Literally free
<zid> because of precisely that reason, it scopes the thing to the start of a block, like code should
<mrvn> why does x86_64 ABI put the number of floats in eax? What do other archs to to capture float args in vaargs?
<nomagno> cat source.c | sed 's///.*$//g'
<nomagno> There, // comments implemented
<geist> it's an optimization so the recipient varargs function doesn't have to dump any more to the stack than it needs to
<nomagno> Like I said, literally free
<geist> ie, it dumps as many floats to the stack as there are args passed
<heat> shell wizards, is it possible to create a temp file in a sourced script and then delete it at script exit (even if on signal, etc)?
<mrvn> and what does it do on arm and aarch64?
<zid> geist: Someone just wanted an excuse to use duff's device
<geist> mrvn: doens't do that
<nomagno> heat: You want a temp file to be created at the start of a .sh file, and deleted when the last command in that sourced file executes?
<mrvn> but does it save all the fpu registers on the stack then?
<geist> i dunno. <points at godbolt>
<geist> feel free to discover on your own
<heat> nomagno, I want it deleted at exit, even if there's a signal or whatnot
<zid> tmpfs is how we normally deal with this is it not
<geist> i only know about this rax thing because there's a switch on gcc/clang to turn that behavior off
<heat> it also needs to be openable by other processes
<geist> it's an ABI breaker, but useful if you dont have any varargs floats (ie, printfs in a kernel weith floats disabled)
<clever> heat: if you keep the file handle open, and delete the file immediately after creation, then that handle is the only thing keeping it alive
<nomagno> heat: you want to look at trap and related commands for portable ways, but this escapes my level of wizardry
<clever> so any exit of your process will result in it being deleted
<geist> the switch saves an extraneous xor rax before every printf
<nomagno> Only recently started looking into signals
<mrvn> heat: you can catch signals in shell scripts
<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)
<geist> something like https://en.wikipedia.org/wiki/DEC_Alpha#Instruction_formats is about as simple as you get
<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
<nomagno> I figured out a way to do (fake) preemptiveness in C99: https://termbin.com/dmzv
<heat> why's the channel +r again? :|
<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> 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
<heat> but first I need to pick a build system
<heat> this is too useful to remain as a port
parrott has joined #osdev
<klange> mbed was pretty straightforward
<klange> I really want to roll my own.
parrott has quit [Ping timeout: 260 seconds]
<heat> rolling your own crypto? brave heh