<zid>
"I am doing awful work" becomes "I am performing a good work"
<mcrod>
i'll buy you a chocolate bar.
<zid>
will it be american chocolate?
<zid>
Refuses to say, I knew it sounded too good to be true
<mcrod>
:(
gmacd has joined #osdev
kpel has joined #osdev
<zid>
how did you do that, I suddenly have an occular migraine
<zid>
I think he's a witch
<mcrod>
you thought of hershey bars and suddenly got a headache
<zid>
ah that might be it
<zid>
more likely to suddenly get a nasty gustitation though
<gog>
mcrod: yes
<gog>
i'm at work and i'm not having a nice time
<gog>
some dipshit fucked up their activity config and now i have to find out why it crashes import
<gog>
and i can't reproduce
gmacd has quit [Ping timeout: 250 seconds]
<mcrod>
i'm not going to have a nice time today, either.
<mcrod>
when someone tells me to use strcmp() on data that isn't null terminated...
<mcrod>
god.
<mcrod>
help me.
<mcrod>
just help me.
<zid>
strncmp duh
<kpel>
ignore them and use strncmp
<mcrod>
yes yes I know that
<zid>
make it some weird linux revision only, strncmpivfa
<mcrod>
the amazing thing is the data isn't remotely anything related to strings at all
<heat>
memcmp
<zid>
nooo
<mcrod>
so memcmp() is honestly more appropriate
<mcrod>
which... i was using
<heat>
pog
<zid>
heat: What do we think to a C revision that allows == on structs?
<heat>
c++
<mcrod>
I can't wait to tell someone that using strcmp() will cause that function call to run forever until it happens to hit a 0 in memory
<zid>
pardon
<zid>
mcrod: You mean, the compiler will see the obvious UB for access an object past the end, and optimize it to starting nethac
<zid>
heat: pardon?
<heat>
see plus plus
<mcrod>
nah, our compiler isn't that smart.
<zid>
...
<zid>
Stop beig awkward
<mcrod>
it's a corporate compiler
<heat>
its the c revision you want
<zid>
what
<mcrod>
for the record, this compiler costs the company like $35k/yr
<mcrod>
if not more
<zid>
why are you being like this
<heat>
like what
<Ermine>
gog: may I pet you
<zid>
I ask you your opinion and being able to compare structs in C, and you say "lol just use C++"
<mcrod>
i'm glad gcc got -ffold-simple-inlines
<mcrod>
due to some blog post about debug performance
<heat>
C++ allows for this, thats what im saying. it is t e h C revision
<mcrod>
still boggles the mind that it was not done sooner
<zid>
so you're still doing it on purpose, why act like you're not
<heat>
and, it's a cute idea, but obviously not as simple as memcmp
<heat>
you cannot compare padding for instance
<zid>
the padding is precisely why I think it might be useful
<zid>
stops you needing to write a silly comparitor function for every type by hand
<zid>
just so that you don't end up with significant padding
<heat>
oh actually C++ does not allow for this by default, you need to define your own operator==
<heat>
for Some Reason
<zid>
can we stop talking about C++?
<heat>
there's either a decent reason or they're all dipshits
<zid>
you'd be better off saying what rust does
<zid>
I'm more likely to use it or give a shit
<heat>
ok
<zid>
The question now becomes: Why the fuck is this not part of the language already? (I mean, other than the obvious answer that the C spec only gets C++ handmedowns)
<zid>
maybe because they can contain arrays?
<zid>
and there's some pathological aversion to == on arrays
<zid>
FMAs too
<zid>
FAM*
<heat>
== on flexible array members makes little sense
<zid>
..yes that's what I am talking about
<heat>
ah yes
<heat>
/shrug
<zid>
I don't think it's beyond us to say "Error: Cannot apply binary `==` to structure with flexible array member" or something
<heat>
i told you <that language with a letter and two pluses> does not do this by default, for some reason, so there may be a good reason why this is not done in general
<zid>
I don't care
<zid>
I really don't care
<zid>
I really really really don't care
<heat>
erm, ok then
<zid>
it's an entirely different language, that I don't know, don't like, don't use, don't care about, can't read, and can't comment on
<zid>
I'll add it to my .txt of things C will have in the universe where I was responsible for C99
<zid>
unless anyone can think of any other errata than FAMs
<gog>
i fixed it yaaaaaaaaay
<gog>
but there's no gym today boooooooooo
<zid>
Did you reproduce it?
<gog>
yes
<zid>
Did you rub their face in it
<gog>
no
<gog>
because it was actually a bug with a related method
<zid>
ah good my migraine is gone, back to book
<heat>
gog lets go to the gym
<heat>
leg day sounds great to me
<zid>
I don't have legs, that's ablist
<kof123>
considering assingment of a struct from another struct looks defined, it is strange. what situation would comparison not be proper, yet such an assignment not run into whatever supposed issue?
<gog>
the compiler will emit a memcpy for assignment but doing a memcmp for two structs might not work right because of alignment padding
<gog>
the value stored in the padding is undefined
<gog>
so the comparison has to be item-by-item
<kof123>
that makes sense, but sounds like "go easy on compiler people"
Terlisimo has quit [Quit: Connection reset by beer]
gmacd has joined #osdev
<gog>
you can't know how the values in the struct are being initialized
<gog>
they might be coming from a file where the padding bytes are nulled, they might be coming from the stack where they're not
<gog>
so there's no single solution for compariosn that's going to work right in all situations
<gog>
unless the compilier has complex logic to compare only the bytes it knows are relevant
<gog>
to emit a comparison for only the bytes it knows are relevant *
<kof123>
^^^ yes, but i mean if the compiler knows the types/members, it could surely just compare each individually. if padding is undefined, should not be part of such a comparison IMO
<zid>
element-wise is almost always what you want
<kof123>
if it can assign already, why not compare
<zid>
and if you don't like the fact it can't emit a memcmp directly, fix your struct's packing
<zid>
so that it can
<gog>
the compiler will then basically be writing anonymous functions for you
<gog>
i don't want that
<kof123>
i guess memcpy you dont have to know the types/members, just the size
<zid>
it does all sorts of shit for me
<zid>
already
<kof123>
*total size
<zid>
like, gcc will happily optimize a histogram generator on static strings into an array with a few avx movs covering the alphabet
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Vercas5 has joined #osdev
Vercas has quit [Ping timeout: 240 seconds]
Vercas5 is now known as Vercas
muffin has joined #osdev
dzwdz has quit [Ping timeout: 240 seconds]
<HeTo>
at least in the 20 version, this one language got a way to have the compiler generate the comparison operator for you, you just need to request it. well, a few ways actually, but one of them is bool operator==(const S&) const = default;
<heat>
oh cool, good to know
kpel has quit [Quit: Leaving]
<HeTo>
the other way is making it a friend so implicit conversions are also allowed on the left side, friend bool operator==(const S&, const S&) = default; or if it's a small struct, it might make more sense to do friend bool operator==(S, S) = default;
<HeTo>
but also, if you define operator<=>, whether defaulted or hand-written, you get equality comparisons too, of course (as well as all the other comparisons)
<mrvn>
HeTo: how is (S, S) ever better than const references?
<sham1>
For a small struct passing by copy would be easier than by reference because you could potentially be smaller than the reference
<HeTo>
mrvn: the compiler knows there won't be aliasing so it doesn't need to store stuff to memory and load it from memory just in case there is. also you might be able to pass the structs in registers rather than allocate stack space for temporary objects and thereby avoid indirection
<sham1>
With calling conventions like that of System-V and thus Itanium, you'd still pass by the 64-bit registers or whatever, but I still think that was the idea
<mrvn>
sham1: expect for maybe some 8 bit cpus that's utterly pointless. A refernce is just a pointer, usually in a register. Loading a smaller type into a register might even be more expensive.
<sham1>
Right, and using a copy constructed version for comparisons would really only make sense for trivially copyable types, but yeah
<HeTo>
mrvn: how do you plan on avoiding loading a smaller type into a register? in the end the compared values have to be in registers (apart from maybe x86 where maybe one of them can stay in memory)
<mrvn>
HeTo: good point.
<mrvn>
But if your object is such a trivial / small type then why isn't your operator== in the class itself or inline for friends? Or use LTO. The compiler would just inline and optimize it all ways.
<mrvn>
s/ways/away/
<mrvn>
Only place you where avoid creating the temporary would be classes that fit into a register. So you really would want to inline those.
<mrvn>
I feel confident in saying the work you potentially save is less than the overhead of a function call.
<mrvn>
HeTo: With const references how is aliasing a problem? The operator== is never going to store anything so it never has to reload anything either.
<mrvn>
(ignoring classes that mutate const objects here)
slidercrank has quit [Ping timeout: 240 seconds]
<mrvn>
(classes with caches or something that mutates in a const object are hardly trivially copyable usually)
<HeTo>
mrvn: well... I suppose if you write them as inline or use LTO, the compiler can see that aliasing is not a problem, so I suppose there either is no performance problem or you have other performance problems besides aliasing, unless this is something where the equality for a member is really tricky to determine even though it is relatively small
dzwdz has joined #osdev
<HeTo>
mrvn: but if the compiler can't see the implementation, it can't just assume that operator== for one of the members doesn't just go and const_cast the const away. or mutate some global object that happens to be one of the arguments, or something like that
<mrvn>
HeTo: assume no inlining nor lto. The operator gets two pointers. It loads the values through each pointer and compares. It really should make no difference wether the pointers are the same or not.
<mrvn>
oh, you mean it makes a difference for the caller? Don't see that either.
<mrvn>
any mutation the operator== does would still muatte and require reloads when there is no aliasing.
dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
<sham1>
I think the best argument against (S, S) vs. const references to S would be that operator=(const& S, const& S) is the more "prototypical" and "proper" way to do that
<HeTo>
mrvn: assume a class with two members. let's say the compiler even knows what operator== for the latter does but doesn't see what operator== for the former member does. now it can't assume anything about the latter member before it has called the comparison for the former member
<mrvn>
true. but true with and without aliasing.
<HeTo>
sham1: I'd say that it's more prototypical to use whatever you'd use for that type in other contexts where the parameter is an in parameter. shouldn't matter whether it's operator== or doSomethingGreat
<sham1>
Well most of the time you'd use const& no matter if operator== or doSomethingGreat
<sham1>
Because you want to be const most of the time
<mrvn>
sham1: If you have something like an "uint60" class then passing by value might really be more "prototypical" and "proper".
<mrvn>
My point was rather that you normally would end up with the same binary anyway.
<HeTo>
mrvn: eh? let's say struct Foo { Bar bar; int i; friend bool operator==(Foo, Foo) = default; }; now it knows that Bar::operator== cannot access the i member of either of the parameters of the operator== for Foos
<HeTo>
so it can, for example, compare the is first and only then call operator== for bar (although it will have to make that call regardless of the result of the i comparison)
<mrvn>
HeTo: bar might mutate i.
<HeTo>
mrvn: it cannot. it doesn't get anything that would give it access to either i
<HeTo>
(yes it can do undefined behaviour but if you do undefined behaviour you get undefined behaviour)
<mrvn>
HeTo: How do you know? bar might have gottent the address of "i" in the constructor. Or access some global "int*" that points to "i".
<mrvn>
Actually in this case aliasing would be helpfull. If you know you are comparing the same object then the compiler can skip comparing "i" since that's always equal.
Jari-- has joined #osdev
<Jari-->
hi
<Jari-->
on Fedora, good bye Windows 10...
<Jari-->
a new laptop, my first Core i5 ever :-)
<Jari-->
lets see how fast the kernel compiles compared to a core duo from 2007
<Jari-->
I used core duo level entrylevel system to code the OSDEV project
<mrvn>
HeTo: unless the compiler knows a function is pure and function call invalidates any non-local object or local objects passed to a previous non-pure fuction. And gcc/clang assume every object is potentially mutated after a function call.
<mrvn>
They tend to reload more than they have to.
<mrvn>
s/pure and/pure any/
<HeTo>
mrvn: hmm. well the only thing that could've stored a pointer to i somewhere here is a Foo constructor. but ok, if the compiler doesn't check all the constructors, then I suppose you have a point
<mrvn>
yeah. the compiler has to analyze which objects or part of objects escape the scope. Anything that could have escaped is supect.
<mrvn>
One of the reasons inline functions or LTO give you a lot of speedup even if the functions don't get inlined in the end. The compiler gets more knowledge to optimize.
<HeTo>
the Foo objects are constructed for this particular call, so other than the constructors or the operator== for Foo itself, there's nothing that could leak those i addresses
<HeTo>
well, if LTO gives you a speed-up, then here it should be possible to conclude that no constructors leak the i address without LTO, because the compiler can know what all the constructors do from the class definition alone
<mrvn>
no. LTO means the compiler sees all the code. That would let it know more. You couldn't assume the same without LTO.
<mrvn>
e.g. when the Foo constructor isn't inlined.
<mrvn>
.oO(Although why would you inline opertaor== but not the constructor?)
<mrvn>
Also note: copying two Foo and doing a function call isn't free. compare that to having to compare two ints.
<HeTo>
well, you can assume that Bar does not get an address to Foo's i member even without LTO here
<HeTo>
in case of value parameters of a function (like the operator== for Foo)
<mrvn>
bar might still cause an observable side effect though. So the compiler can't do "return (foo1.i == foo2.i) && (foo1.bar == foo2.bar);"
<HeTo>
because the ways to construct either of those Foo objects are: default construction, doesn't pass address of i to bar; copy and move construction (if allowed by Bar), don't pass address of i to bar; or aggregate initialization, but I don't think it's possible to refer to the addresses of members of those temporary objects at the call site, so not possible there either
<HeTo>
mrvn: that's true. as I said, it would have to call the comparison on bars anyway. but it could do const auto ieq = foo1.i == foo2.i; return foo1.bar == foo2.bar && ieq;
<HeTo>
and that might mean it has to spill less on the stack (just the Boolean result, rather than the values of the i variables)
<mrvn>
at the cost of having to copy 2 Bar objects to the stack.
<mrvn>
You can probably construct a case where you save something overall. But I bet that inlining the operator== would then save you more.
<gog>
meow
* gog
spills her stack
heat has quit [Remote host closed the connection]
heat has joined #osdev
* bnchs
drinks gog's stack :3
<bnchs>
meow
<heat>
gcc
<gog>
clang
goliath has joined #osdev
<heat>
meowcc
<sham1>
msvc
<bnchs>
worst compiler
<heat>
msvc poggerest compiler
<gog>
i'm gonna work for microsoft writing compiler
<heat>
grog
<heat>
write compil
<heat>
make it go vroooooooooooooooom
<jimbzy>
I'd use gog's compiler.
<gog>
i'm not a very good programmer
<gog>
i'm an adequate programmer
<gog>
i replaced a component from one of our apps and now i need to see how much legacy js code is redundant and hooooly shit this file is long
<jimbzy>
I'm a terrible programmer unless someone says, "Make X work with Y" and then I can stick the pieces together like the Flex Seal guy.
<gog>
i'm better at writing things from scratch than i am making them interoperate
<heat>
im a brilliant flawless programmer
<gog>
we should team up jimbzy
<heat>
i'm a genius
<heat>
hell, no, im a genie
<jimbzy>
gog, The world couldn't handle us as a duo.
<sham1>
Good thing one doesn't need to be a good programmer since adequate is what the industry wants and needs
<heat>
mid
<jimbzy>
Interesting. I picked up my neighbor's garage door opener at 375.2500 MHz. XD
xenos1984 has quit [Ping timeout: 248 seconds]
<jimbzy>
That's kind of strange since they're usually at round frequencies. I may need to calibrate my SDR.
<heat>
steal his toolbox
<heat>
this is a perfect heist opportunity
<heat>
jimbzy's eleven
xenos1984 has joined #osdev
<jimbzy>
Oh please. If he had decent tools he would never visit me to borrow mine. ;)
gmacd has joined #osdev
innegatives has joined #osdev
<gog>
jimbzy: are you running some kind of rtl dongle
<gog>
those tend to drift as they heat up
<gog>
or you have an impediance mismatch with your antenna
<jimbzy>
Yeah. I always let mine warm up before messing with it.
<gog>
i bought the real cheap one from nooelec that was jsut a dvb receiver lol
<gog>
it was a pain but i could pick up lots of stuff
<heat>
heat up
<jimbzy>
They have shitty oscillators and usually need to be calibrated out of the box. I haven't checked it against a NOAA weather station to see what's up.
* heat
fingerguns
<sham1>
boo
<jimbzy>
I've been able to download NOAA images over APT and it does well with FM stuff.
plarke has joined #osdev
<jimbzy>
I really need to build a decent antenna and mount it above the roof line. Right now, I'm using a flimsy telescopic dipole mounted to my 2nd floor balcony facing N. I found out I can park my keep under it and it acts as a ground plane.
<gog>
i was able to get ads-b signals fairly reliably even from below roof line
<gog>
as long as the planes were > 45° elevation from my position lol
<jimbzy>
Yeah hehe
innegatives has quit [Ping timeout: 250 seconds]
dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
innegatives has joined #osdev
<sbalmos>
gog: 1090 or 978?
gmacd has quit [Ping timeout: 240 seconds]
<gog>
sbalmos: hm?
<gog>
ohh the adsb frequency
<gog>
978
<gog>
1090 was too noisy
<gog>
i had a small impediance mismatch with my aerial and i think it just couldn't work
innegatives has quit [Quit: WeeChat 3.8]
gmacd has joined #osdev
<gog>
time to go home bbiab
gog has quit [Quit: Konversation terminated!]
goliath has quit [Ping timeout: 265 seconds]
xenos1984 has quit [Ping timeout: 240 seconds]
xenos1984 has joined #osdev
osmten has quit [Quit: Client closed]
awita has quit [Remote host closed the connection]
goliath has joined #osdev
danilogondolfo has quit [Remote host closed the connection]
gmacd has quit [Ping timeout: 250 seconds]
gog has joined #osdev
goliath has quit [Quit: SIGSEGV]
gmacd has joined #osdev
<gog>
hi
<bnchs>
hi gog
plarke has quit [Remote host closed the connection]
Jari-- has quit [Remote host closed the connection]
<gog>
meow
<bnchs>
can i pet
gmacd has quit [Ping timeout: 268 seconds]
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<gog>
yes
* bnchs
hugs gog unexpectedly
* gog
hug
<jimbzy>
Whoa, that just made me think of something. Remember the Little HUG drinks that came in the little plastic barrels with the foil lid?
<gog>
yes
<jimbzy>
I haven't had one in years. I should buy a case sometime.
<jimbzy>
My old man always packed a few in his lunch, and he'd save one for me for when he got home from work.
Matt|home has joined #osdev
goliath has joined #osdev
<gog>
too much sugar
<sbalmos>
gog: oh btw, back to the ADS-B stuff... yeah, gotta remember 1090 is also the main frequency for transponders in general, not just the Mode S ES stuff. So it was probably a dumpsterfire of stuff that looked like noise
<mrvn>
Can anyone tell me what the point is of getaddrinfo returning IPv6, IPv4 for a node but IPv4, IPv6 for AI_PASSIVE, node=NULL?
<gog>
sbalmos: yeah, i only messed with it for a couple days because i was just seeing if i could make it work but i do remember not being able to get the ads-b mapping software thing i installed to work with my receiver on 1090
<gog>
i don't know much about it
<jimbzy>
You almost have to have a LNA from what I've heard.
<sbalmos>
gog: I need to play with SDRs... just as much as I need to actually get back to writing my kernel, rebuild my home lab, etc etc etc
<gog>
it's fun stuff deffo
<sbalmos>
gog: wasting time and money on actual flying is more fun though :)
<mrvn>
AI_PASSIVE seems to be pointless to harmfull that way.
<gog>
haha yes
<gog>
jimbzy: yeah anything higher than 1GHz was pretty fuzzy, iirc those rtl dongles max out at like 1300MHz
<gog>
even an LNA might not help
<sbalmos>
you get a lot of interference just from passing through building materials
innegatives has joined #osdev
<innegatives>
Why is it suggested that you should use your own GDT instead of one Limine gives you?
<gog>
because if the one limine gives you is ever unmapped and something reloads a segment register it'll #GP
<jimbzy>
gog, Yeah I think most people use frequency converters.
<gog>
you absolutely have to use your own GDT
<jimbzy>
Mine can receive HF with direct sampling, but I haven't tried it out.
<innegatives>
gog: why would it get unmapped?
<gog>
because eventually you're going to be in user mode
<sham1>
Please don't unmap me
slidercrank has joined #osdev
* gog
unmaps sham1
<sham1>
Nooooooooo…
* sham1
disappears
<gog>
the GDT should be at a virtual address somewhere in kernel space. it's safer and for using syscall/sysret it needs to be in a specific order anyway
* sbalmos
page-swaps gog
* gog
thrashes
muffin has quit [Ping timeout: 250 seconds]
<sbalmos>
what's that horrific thumping and banging sound from downstairs in the basement? oh, that's just the spinny platter disks writing gog out
<mrvn>
unmapping the limine GDT isn't really the real problem. What if you reuse the page the limine GDT is in and give it to a user. Now they can create their own GDT and mess you up. :)
<gog>
yes
<gog>
the second any segment register is reloaded you're traipsing into undefined behavior
<gog>
that's The Bad Place
<mrvn>
I'm assuming though the GDT is maybe below 1MB and you never use those pages? Then it probably keeps working.
<gog>
it's still a Bad Plan
<mrvn>
totally.
puck has quit [Excess Flood]
<gog>
oops
puck has joined #osdev
heat has quit [Remote host closed the connection]
heat has joined #osdev
<gog>
heat: bazinga
xenos1984 has quit [Ping timeout: 240 seconds]
xenos1984 has joined #osdev
muffin has joined #osdev
vai has joined #osdev
vai is now known as Jari--
<sham1>
At the risk of causing an IRC tyre fire, I think it's funny when people say that FLOSS shouldn't be political or that it used to be nice until people injected politics into it. Like geez, do these people not know what the whole impetus for free software is?
gorgonical has joined #osdev
<gorgonical>
how's everybody's day going
<sham1>
Fine, thanks. How is your day?
<gorgonical>
It's pretty good. Eating some gummy worms which is always nice. Farting around with qemu
<muffin>
Not too bad
<sham1>
How is the QEMU fart interface
<gorgonical>
Lots of beans are needed to operate it
<gorgonical>
I'm trying to make my qemu stack mirror a board stack I'm developing because I need to work on the firmware layer. And qemu just jumps right to your kernel if you don't pass firmware
xenos1984 has quit [Ping timeout: 240 seconds]
<innegatives>
Can you keep building your kernel in protected mode, I mean things like memory management, processes/scheduler, GUI, etc. and then switch to long mode with few changes and expect everything to work? Is it hard to abstract those things in a way that works both in protected mode and long mode or do they not rely on anything mode specific?
<mrvn>
innegatives: are cubes round?
<innegatives>
?
<mrvn>
note: a cube is a sphere with an exponent of 1
<innegatives>
how is that relevant?
<sham1>
A cube is also a sphere in the Chebyshev metric
<mrvn>
it's about as sensical as your question.
<mrvn>
by the way: The answer to your question is: yes.
<innegatives>
yes? as in, most subsystems should work in long mode as well without many changes?
<mrvn>
yes, as in I can build my kernel in protected mode,.... But as to your 2nd question that's a yes too. One or the other is true.
<mrvn>
Looking at it another way the answer is still yes: You can always find someone that will "expect everything to work", too. :)
<innegatives>
So say you've got protected mode OS that switches to long mode or not by checking cpuid, do you compile that with x86_64 toolchain and expect it to work on both protected mode only and long mode CPUs?
<mrvn>
"is it hard" is also verry subjective. Linux and BSDs have all abstracted things. Do you think they made it appear easy?
<mrvn>
innegatives: I don't think there are many kernel out there that will just switch to long mode when available. Usualy you select that at compile time and then build one or the other.
<sham1>
IMO treating x86 and AMD64 as anything but two separate arches for the purpose of this will just make things harder than they need to be
<mrvn>
There are bootloaders out there that will load one of kernels depending on cpu flags. E.g. isolinux can load a long mode kernel when the cpu has long mode and a 32bit kernel otherwise.
<mrvn>
RaspberryPI's firmware can do that too for ARM and AArch64
<sham1>
At least IMO one is better off building the kernel either as fully 64-bit or 32-bit and then have a bootstrap that sets up a pristine environment for either actual kernel
<sham1>
Way less confusion, way less fragile as a process and so on
<mrvn>
you certainly can't share any code past switching to long mode. Well, you probably could with a lot of work. But the same opcodes behave differently because the default register size differs.
xenos1984 has joined #osdev
<innegatives>
Is there any reason why SerenityOS doesn't support x86?
<mrvn>
because it's wasted effort?
<innegatives>
but is it really that much of an effort is what I really want to know
<mrvn>
it is. all the most horrible stuff in a kernel is different for x86 and x86_64
<innegatives>
can you name few of those horrible stuff?
<mrvn>
segment descriptors, gdt, tss, do I need to go on?
<innegatives>
so its arch setup stuff, the subsystems should be rather unaffected right?
<mrvn>
having all 32bit of address space have physical memory behind it
muffin has quit [Quit: WeeChat 3.8]
<innegatives>
so you are referring to not having to think about swapping to disk?
<mrvn>
No. I'm refering to not having any spare address space to work with without reducing the amount of phyiscal memory you can map. Most people map all physical memory somewhere so they can write to page tables or other without having to map pages manually all the time.
<mrvn>
or copy_from_user and copy_to_user
<innegatives>
ok thanks
elastic_dog has quit [Ping timeout: 250 seconds]
<sham1>
Moreover, going with 32-bit x86 doesn't really give you anything of note. It's just an inferior architecture. Just the fact that AMD64 has so many more registers just makes it a nicer platform by a long shot
<mrvn>
plus you know you have cmov, and fpu, sse2.
hmmmmm has joined #osdev
DoubleJ2 has joined #osdev
TkTech6 has joined #osdev
grange_c02 has joined #osdev
varad1 has joined #osdev
xvmt_ has joined #osdev
Archer has joined #osdev
tomaw_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
aws_ has joined #osdev
_koolazer has joined #osdev
Brnocris1 has joined #osdev
sham1_ has joined #osdev
sham1 has quit [Killed (NickServ (GHOST command used by sham1_))]
sham1_ is now known as sham1
elastic_dog has joined #osdev
<gorgonical>
an architecture with even more registers exists
<mrvn>
is there a 32bit cpu with fewer registers than x86?
Brnocrist has quit [*.net *.split]
hmmmm has quit [*.net *.split]
TkTech has quit [*.net *.split]
k0valski18891 has quit [*.net *.split]
xvmt has quit [*.net *.split]
tomaw has quit [*.net *.split]
grange_c0 has quit [*.net *.split]
koolazer has quit [*.net *.split]
remexre has quit [*.net *.split]
wgrant has quit [*.net *.split]
DoubleJ has quit [*.net *.split]
aws has quit [*.net *.split]
Dreg has quit [*.net *.split]
rein-er has quit [*.net *.split]
varad has quit [*.net *.split]
tomaw_ is now known as 082AABUHS
TkTech6 is now known as TkTech
grange_c02 is now known as grange_c0
varad1 is now known as varad
xvmt_ is now known as xvmt
DoubleJ2 is now known as DoubleJ
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
082AABUHS is now known as tomaw
<sham1>
gorgonical: well ofc, but this is a discussion about x86 vs AMD64. RISC-V and whatnot aren't really relevant
<gorgonical>
I can't resist, sorry
<innegatives>
Do you guys know of any niches one can create an OS in, given that general purposes Unix is done to death
wgrant has joined #osdev
<gorgonical>
Tangentially related, I'm thinking about learning some hdl and writing a simple, in-order riscv processor. I wrote a C simulator for a superscalar, out-of-order processor a few years ago and want a "real" chip
<mrvn>
I have a bucket of 74xx chips for that.
[itchyjunk] has joined #osdev
<mrvn>
/me makes some penguin shaped ice cubes.
<sham1>
innegatives: if you want a very major challenge, one type of an OS one can make is a so-called language OS. So you basically take a programming language (usually a managed language) and you build an implementation of it that can run in kernel space standalone
<sham1>
But that is a *very* advanced task that requires both good grasp of the OS development process, the hardware *and* programming language design theory and such
<heat>
i have a language OS in C/C++
<heat>
with "syscalls"
<sham1>
> C/C++
<sham1>
Anyway, a neat thing with using a managed language is that you can reap benefits similar to stuff like hardware memory protection while not using those things. Like if you don't have arbitrary pointers to memory, you can run all your processes and the like in ring 0
<sham1>
And your "syscalls" are just normal procedure calls and so on
<heat>
C/C++/assembly
deflated8837 has quit [Read error: Connection reset by peer]
deflated8837 has joined #osdev
<sbalmos>
a huge obstacle to overcome there, as you alluded to earlier, is the kernel must now also be a full-blown language JIT compiler
<heat>
and if there's a bug, you go booooooooooooooom
<heat>
like eBPF is a pretty good example here
<gorgonical>
As an interesting first step I could recommend doing a forth. It has many of the same properties. It's interpreted in a similar way albeit at a much lower, more basic level. It gives you a good look into the language development process, and you get to build the OS from absolute first principles
<sbalmos>
oh eBPF is a /fun/ way to blow off your feet with a 60-rounds-per-second deershot slug gun
<sbalmos>
one good rule, <enter>, and *bam* "why's my box suddenly turned into a wind tunnel? and nothing's happening on screen? what happened to my SSH session???"
<heat>
well, that's hard to do by accident
<heat>
because there's a very large eBPF verifier. but if there's a bug, oopsie there goes your kernel
goliath has quit [Quit: SIGSEGV]
<sbalmos>
easy to do when it's not you, copy-pasta'ing from SO or chatgpt
<heat>
no it's not?
<sbalmos>
I've been the one calling someone saying "what did you just do to the server?"
<heat>
it's not trivial to accidentally hang your machine using eBPF. because of the verifier
<heat>
if you mean stupid shit like rejecting every packet, that's doable with root yeah
<heat>
but it's also doable on purpose, and it's also undoable
<gorgonical>
sounds like a rumsfeld quote
<sbalmos>
I know. just ranting from one personal experience.
<sbalmos>
anyway, back to the joys of having to also embed a language compiler and runtime into the kernel
<heat>
ebpf has a lot of "problems" because it's essentially bytecode that can limitlessly do everything and anything
<heat>
like a language OS
<sbalmos>
and in microkernel form... would you run the compiler as a system service process, or in the kernel itself?
<mrvn>
it's kind of hard to undo dropping every network packet when you are logged into the server via ssh. :)
<mrvn>
sbalmos: yes
<heat>
i don't think a microkernel is compatible with a language OS
<mrvn>
heat: ada?
<mrvn>
smalltalk?
<heat>
language OS is kind of a big-brained very monolithic single-process ring0 thing
<sbalmos>
heat: I could maybe see something like a small precompiled bootstrap compiler/runtime as an initrd module, which then allow the kernel to compile and spawn the real compiler system process
<gorgonical>
would msoft's singularity fit in this definition?
<sbalmos>
yes and no
<mrvn>
more fun is to write an OS that you can link against existing binaries to make them run baremetal.
<gorgonical>
so a unikernel
<heat>
you're making me want to build a javascript kernel now
<mrvn>
exokernel
<heat>
kernel + v8 = profit??
<sbalmos>
heat: dear ${deity} no, please
<sbalmos>
heat: Last thing I need to deal with is NodeJSOS
<heat>
v8 should be hella safe though
<gorgonical>
but mrvn how would that not be a unikernel? is there some definitional overlap here?
<heat>
btw this is already a thing
<mrvn>
gorgonical: definetly
<gorgonical>
I love the endless continuum of kernels and their names
<gorgonical>
I hvae just hit the linguistic saturation for kernel and it looks like a non-word now
<sbalmos>
sustainable kernel, free range kernel, organic kernel
<mrvn>
you can build your kernel as crt0.o and libc and such and then just link some app against that to make it run in the cloud without kernel/os overhead.
<mrvn>
aerokernel?
<gorgonical>
aerokernel is a research kernel from northwestern and iirc it's basically a single aspace, no privilege thing. applications run in kernel mode. There are more things to it but it's been a while since I read about it
<gorgonical>
a research kernel idea*
<heat>
kernal
<mrvn>
that doesn't sound like a class of kernels but rather as a single implementation
<gorgonical>
aerocolonel
<heat>
linux colonel
<gorgonical>
the research project is nautilus
<sbalmos>
and how's that different than, say... DOS?
<heat>
well, you get a research grant to write one
<heat>
no one's giving you a grant to write DOS
<gorgonical>
I don't think it's majorly different. My understanding is that it
<sbalmos>
heat: gimme $$$ !!!
<gorgonical>
it's a good platform for modern kernel research and stuff. Old ideas aren't bad ones
<heat>
I'm looking for research projects to write UNIX
<heat>
UNIX, but with a different name I guess
<gorgonical>
you are 40 years late
slidercrank has quit [Ping timeout: 265 seconds]
<heat>
gog: lets fork()
<heat>
wait, no
<heat>
let's spoon()?
<heat>
still kind of dirty
<heat>
let's knife()
<gog>
hi i'm ada
Matt|home has quit [Remote host closed the connection]