danilogondolfo has quit [Remote host closed the connection]
epony has joined #osdev
spikeheron has quit [Quit: WeeChat 3.8]
srjek has joined #osdev
<epony>
"I hard-forked MINIX with a UNIX-like kernel stub (reset clock to 1984 for copying BSD) that grew from the GNU glibc application store, just later found out about the UNIX filesystem, but sideways" --future OCD (Oregon Cookie Developer) with a hypey need for marketing campaigns
wootehfoot has quit [Read error: Connection reset by peer]
fedorafan has quit [Ping timeout: 246 seconds]
x8dcc has quit [Quit: leaving]
slidercrank has quit [Ping timeout: 268 seconds]
<epony>
a late C compiler from AT&T, GNU did not even exist a whole decade after CSRG (the BSD authoring group), and GCC was not released a decade after this compiler which was used on BSD before GCC became available 20 years after the C language was created at Bell Labs and 10 years after CSRG was doing BSD releases
<epony>
so Linux got mostly the Minix and GNU mixed bag of nuts and tried to shift to UNIX-like without being UNIX and remains off-UNIX to this day
<epony>
UNIX ran off from 1970 to 1985 and went off to become BSD, and commercial AT&T which crashed
<epony>
Linux is like BSD but does not admit it and that created incompatibility and failure of applications and broken file systems on Linux for decades..
<geist>
epony: again, can you stop just posting random blater for hours on end?
<epony>
Minix remains unpopular on general purpose computers to this day, and other micro-kernel operating systems are niche usage on the middle class of machines
<epony>
ok
<mrvn>
geist: he won't listen. just /ignore him
<epony>
I listen.. ;-)
<geist>
listens to me. it's one thing to post a topic and see if anyone bites
<geist>
but after a whiel if no one is responding it's not really worth anyones times
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<zid>
"Can you please stop being neurodivergent?"
<epony>
of course, said the normie
mctpyt has joined #osdev
[itchyjunk] has quit [Ping timeout: 252 seconds]
[itchyjunk] has joined #osdev
<sakasama>
A person being neurodivergent doesn't imply a lack of respect for community well-being.
<heat>
yooooooooooo
<heat>
objdump from binutils 2.40 has coloring!
<geist>
oh hey cool
<mrvn>
what does that mean?
<Mutabah>
I assume coloured output when rendering to the terminal?
<mrvn>
nice. But it still can't align it's output corectly (the # comments)
<heat>
i'm ok with that "misalignment"
<kazinsal>
the alignment probably makes sense if you're unironically writing gnu style indented code
<heat>
llvm-objdump seems to be a good bit slower than objdump
<heat>
:|
<geist>
FWIW the output of objdump definitely assumes a 8 space tab, when viewing it in vim i always have to ts=8
<geist>
heat: yeah that's surprising huh? and in general it's not as good as binutils objdump
<mrvn>
is speed something you notice with objdump?
<heat>
geist, why's it not as good?
<heat>
mrvn, noticeable here doing objdump of libssl
<geist>
historically at least it was not as pretty to read
<geist>
for example jmps to an address it wouldn't compute the address
<geist>
would just be like branch <offset>
<geist>
or some sort of constant calculation on particular instruction sequences, etc
<geist>
binutils objdump at least for certain architectures has a bit more mileage and some amount of 'for humans to read' polish that llvm-objdump hasnt added yet
* zid
tempted emerge -1 =sys-devel/binutils-2.4.0
<geist>
symbol resolution is also one of them. i'd seen llvm-objdump just show branches or loads from address, no attempt to display what symbol that was
<geist>
but.. caveat. this was a while back, a few years ago. may have gotten some work since then. also i think i was mostly looking at arm64 disasm
<heat>
i like that llvm-objdump supports everything
<geist>
yah. FWIW there is a way to build an uber binutils. i forget the syntax when configuring
<geist>
something like --target-all
<heat>
that sounds scary
<heat>
all target emuls
<geist>
not particularly, it just has a huge list of target emuls
<geist>
great for exactly disassebmly
<zid>
mine only comes with 'zstd' as an option :(
<zid>
needs a buddhism use flag
<geist>
one of the other deficiencies i remember is that llvm-c++filt stops after the first match
<heat>
hm?
<heat>
match of what?
<geist>
first match of a manged name
<geist>
mangled
<geist>
you can just pipe any pile of text through c++filt and it'll demangle what it sees as a mangled name
<heat>
works with llvm-cxxfilt here
<geist>
ah good, guess they fixed that
<heat>
now, i'll ruin binutils for you
<heat>
$ nm -
<heat>
nm: '-': No such file
<mrvn>
mangling and demangling should be a library function
<geist>
for the longest time objdump didn't have the -C options so you would generally just pipe objdump -d through c++filt
<geist>
but now you can just request it already inline with -C
<heat>
mrvn, a demangling function is part of the itanium c++ abi
<mrvn>
but I need to mangle function names
<geist>
IAAAAAAAATANAAIM
<heat>
IAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
<geist>
RUSSSST FOR IAAAA64
<mrvn>
every FFI interface basically needs that if you want to interface with c++
<kazinsal>
geist: off chance do you know if your current toolchain builder supports vax? got a couple bad ideas for osdev april fools jokes and that's a prerequisite for one of them...
MiningMarsh has joined #osdev
unimplemented has quit [Read error: Connection reset by peer]
<heat>
kazinsal, can't you just build one?
<kazinsal>
sadly the answer appears to be no
<kazinsal>
`*** BFD does not support target vax-dec-elf`
rorx has quit [Ping timeout: 260 seconds]
<heat>
kazinsal, 2.24 should work
<heat>
dunno if there's anything newer
<kazinsal>
I have a feeling I'm gonna need to do a custom manual build old school
<kazinsal>
all this for a dumb joke
birdman has left #osdev [WeeChat 3.6]
<klange>
worth it, imo
<kazinsal>
the dumb joke is to make my EVE alliance's alerting system run on a VAX and dial alerts over Bell 202 to a vintage cisco and have that sent over SIP to our mumble so it gets bridged to discord
xenos1984 has joined #osdev
<klange>
Hmm. That does feel a bit convoluted, the humor may not be appreciated.
<kazinsal>
my alliance leader was the one who convinced me to try to work the vax into this
<kazinsal>
sure, I could run this on netbsd, ooooooooooor I could write my own kernel for it
<heat>
write kern
<heat>
doing this on netbsd would have little value outside the dumb joke
<heat>
learning how to write a kernel for the VAX would also have little actual value
bradd has quit [Ping timeout: 248 seconds]
<kazinsal>
definitely not going to win me any crowds of screaming women a la a mid 1960s beatles concert
<epony>
a normal person knows the VAX was an early 32bit computer that was phased out after porting UNIX to other 32bit machines
<epony>
being a retardant repeater of some 1991 jokes is.. 30+ years late to the party
<epony>
which ended in 1988
<epony>
before NetPeeSD
<epony>
about 5 years in advance
<epony>
your parents did not know what a computer is back then, and you did not exist in the plans
rorx has joined #osdev
<epony>
it's not a bad thing to retroactively rediscover what hp9k was
gog has joined #osdev
[itchyjunk] has joined #osdev
<Ermine>
heat: I think writing a kernel for VAX can be fun
<epony>
in 1985
<epony>
early 32bit machines without memory management.. is like 16bit machnes with extra bits, get it.. they suck and you don't know enough to handle that
<epony>
"should be less to know but more to rediscover, what you wanted to know originally for modern computers"
<epony>
^ it's not less work
<epony>
could be single units remaining at their last museum "start me up to fail quick" runs
<epony>
a lot quicker than you need to test your "20 year work in progress one man kernel" project
<epony>
a bit nutty, don't you think in perspective?
<epony>
so, to compact the nonsense, you start with careful evaluation of the machine capabilities, obviously your mentor is joking with you and seeing how ignorant you could be getting your way into the joke
<epony>
will be great laugh at the end
<dinkelhacker>
So I've been thinking about the whole 'the dtb got loaded to where the bss is'-dilemma (when using raw binarys instead of elfs) I've been annoying you with yesterday^^... As some pointed out one could just map the bss to somewhere else, e.g. after the dtb. However, currently I see one drawback to this approach: the naive implementation of phys_to_virt won't work anymore for anything inside .bss
<dinkelhacker>
because the mapping is not linear anymore.That means you can't just subtract a common offset from the va to get the pa... Any thought?
<mrvn>
as said, add a gap between .data and .bss in the linker script.
<mrvn>
or copy the DTB to after the .bss
<mrvn>
and before you do either check out the situation for when you have an initrd
<dinkelhacker>
Don't get the intird part.
<mrvn>
where will that be loaded? Will .bss overwrite that too?
<dinkelhacker>
Oh okay.. yeah that is something I'll have to consider.
<zid>
I mean
<zid>
you could just include the bss in your binary
<zid>
given you're only doing it for -kernel
<dinkelhacker>
No my goal is to have an approach that will almost always work...
<zid>
packing the bss in will infact, always work
<zid>
you just lose out on the optimization
<mrvn>
if (random() == 0) panic();
<mrvn>
problem fixed, it will sometimes fail.
<dinkelhacker>
Right it will always work. I thought you asked if I just want to do that for using it with qemu.
<zid>
I mean, there's no point doing it if you have a real elf loader bootloading you, so yes technically only qemu's -kernel needs it
<zid>
so you could keep it for just qemu if you wanted to be cleaner
<dinkelhacker>
I kinda feel like all the options are sub optimal. Either you pack in the bss -> bigger image. You add a virtual gap of say 2MB -> if your dtb is only 1MB you'll waste 1MB (allthough one could reclaim that leftover memory).
<Ermine>
Question on terminology: ATA on wiki.osdev.org stands for something commonly known as IDE and SATA is... SATA?
<zid>
sata is serial ata
<mrvn>
Ermine: sata is scsi
<zid>
ATA is 'at attachment' I think
<dinkelhacker>
zid: The pi loads raw images, linux also doesn't ship as elf? So how often do you really face an _real elf loader_?
<zid>
I mean, on real platforms and loaders? constantly :P
<zid>
"The first version of what is now called the ATA/ATAPI interface was developed by Western Digital under the name Integrated Drive Electronics (IDE)."
<mrvn>
dinkelhacker: if you are security conscientious then always, your own but still an elf loader.
<zid>
The spec is named IDE, the technology is called ATA, is how I would put it.
<zid>
like USB and UHCI
<Ermine>
zid: okay, thank you. I just want to make sure I'm reading the thing I need.
<dinkelhacker>
mrvn: what makes elf loaders more secure?
<mrvn>
dinkelhacker: what's wrong with moving the DTB out of the way?
<mrvn>
dinkelhacker: kernel address randomization
<dinkelhacker>
mrvn: but again, isn't linux a raw binary? Like i look at my /boot/vmlinuz and it is not an elf? So how can it be that kernel address randomization would rely on the kernel beeing an elf? I might be missing some obvious thing here^^
<sham1>
What makes ELF loaders more secure? Moving them to user-space
<mrvn>
dinkelhacker: linux compresses the kernel and either has a stub in front of it for uncompressing or the bootloader uncompresses it
<epony>
linuz
<dinkelhacker>
so what you're saying is that it's an elf under the hood?
<zid>
my pc setup is an elf that loads an elf
<zid>
cus.. elf :D
<mrvn>
dinkelhacker: probably some intermediate format that's easier to parse. Point though is that the phyiscal pages get mapped to different virtual addresses so your trivial PHYS_TO_VIRT constant won't work anyway.
<dinkelhacker>
yeah exactely it only works for kernel memory that was mapped 'linear'.
<zid>
I think my first elf doesn't have a bss
<mrvn>
zid: stack in the .data section?
<epony>
ne
<dinkelhacker>
mrvn: coming back to moving it out of the way. Nothing particularry wrong with that. Just trying to find out what is the best approach. I mean since the bss and the dtb could overlap just a tiny bit, one whould still have to copy it after the end of the dtb which means you'd still end up with a gap between the end of bss and the start of the dtb that you have to reclaim
<mrvn>
other than alignment why would you leave any gap after .bss?
bgs has joined #osdev
<mrvn>
s/memcpy/memmove/ just in case
<dinkelhacker>
mrvn: say the bss and the dtb start at the same address, the bss is 20k, the dtb, is 1 MB. If I copy the start of the dtb to after the bss (20K) I'll actually override data of the dtb I'll have to move later.
<mrvn>
I think moving it out of the way is your only choice if you want to keep your PHYS_TO_VIRT because the initrd will have the same problem and you don't want to limit that in size.
<mrvn>
dinkelhacker: memmove handles that
<dinkelhacker>
mrvn: oh so you were refering to a specifc implementation that can handle it?
<dinkelhacker>
I thought you just meant "just move it"
<mrvn>
dinkelhacker: no. That's the difference between memcpy and memmove in the specs. memmove handles overlaps.
<dinkelhacker>
Okay right.. that would be good. I mean still you probably would have to do some assumptions regarding the available memory to do the 2 step moving but if that fails I'm doomed anyways^^
<mrvn>
if you run out of memory moving the DTB then you have other problems.
<mrvn>
you also don't need to do 2 steps. just copy backwards if you have overlap and damn the speed loss.
<dinkelhacker>
Ah nvm.. you're right. I'm making things more complicated then they are. I think my time working on safety relevant embedded systems has made me overly concered about any possible oom situation.
JerryXiao has quit [Quit: Bye]
<epony>
that's what virtual memory is for
<epony>
solving those concerns
<dinkelhacker>
Well we never even had virtual memory
<epony>
that can be fine if working with constant data sets
<epony>
or sustained rates that do not exceed data structures etc
<epony>
"static" operation
<epony>
you're still achieving exceptional reliability with size limited / range set operations anyway
slidercrank has quit [Ping timeout: 248 seconds]
<mrvn>
virtual memory is an illusion
<kof123>
a lot of vax enthusiasm today...
small_ has quit [Quit: Konversation terminated!]
<mrvn>
is today national vax day?
<Ermine>
international vax day
<sham1>
mrvn: virtual memory is illusionary. That's why it's virtual
<mrvn>
sham1: it's no fun if you have to explain the joke
<Ermine>
ur operating systems live in the virtual world!
smach has joined #osdev
<mrvn>
mine runs on a hypervisor, twice the virtual.
unimplemented has joined #osdev
<sham1>
Like gods within our little virtual worlds
brynet has quit [Quit: leaving]
<mrvn>
one ring to bind them all
<mrvn>
.oO(Now you have proof that x86 is evil)
<Ermine>
drop x86 into the volcano!
<sham1>
But we already knew that x86 is evil
<sham1>
No non-diabolical person would design an ISA with such fee registers
<sham1>
few, even
<mrvn>
sham1: stack machines have 0 registers.
srjek has joined #osdev
<sham1>
Well ISA registers anyhow. Otherwise I couldn't see how they'd implement things like stack rotations, but fair enough
<mrvn>
sham1: rotate register. load 2 values from stack, rotate by 1 value, store back to stack
<mrvn>
s/register/circuit/
<Ermine>
maybe they have some internal state which is not exposed to programmers?
<sham1>
I dunno, that sounds like an internal register to me
<mrvn>
latches probably
gildasio1 has quit [Ping timeout: 255 seconds]
gildasio1 has joined #osdev
Rubikoid has quit [Read error: Connection reset by peer]
Rubikoid has joined #osdev
divine has joined #osdev
brynet has joined #osdev
smach has quit [Remote host closed the connection]
danilogondolfo has joined #osdev
foudfou has quit [Ping timeout: 255 seconds]
foudfou has joined #osdev
gildasio1 has quit [Ping timeout: 255 seconds]
<heat>
Ermine, oh yeah totes fun just not very relevant
JerryXiao has joined #osdev
<zid>
I can't parry gwyn heat
<zid>
how do
craigo has quit [Quit: Leaving]
craigo has joined #osdev
<heat>
git gud
<heat>
the strat is to parry, riposte, get behind him, estus, he does the easy-parry-attack, riposte, repeat
<mjg>
stop talking shit and get to work
<zid>
why would you need to heat
<zid>
if you parry and riposte everything
<mjg>
for example watch faily-friendly youtube videos
<zid>
I can't catch the damn jump
<heat>
zid, cuz the strat is to force them to give you the nice parryable attack
<heat>
if you can't parry the jump attack, git gud
<zid>
yea what is time
<heat>
20 second
<zid>
when I finally get it I am going to be too surprised to riposte
<heat>
😲
<mrvn>
zid: time is a function (pointer to time_t) returning time_t.
<geist>
i hadnt tried building any newer versions of gcc than that, but it's not like it's getting any new advancements in codegen
<geist>
gcc 7.x was a nice vintage, it was just before it started getting a bit more complicated to build
<Ermine>
is it upstream support?
<heat>
geist, did anything change after 7?
<geist>
i forget honestly. at smoe point the build was trickier
<geist>
also they started building parts of the toolchain in C++, not that it mattered much
<geist>
i think it took on more dependencies in general
<mrvn>
You think there are no advancements in codegen between gcc 7 and 12?
<heat>
hm? hasn't gcc been C++ since 4.x?
<geist>
mrvn: well nothing for vax
<geist>
and honestly if you're hacking on vax right now i kinda doubt you're that seriously interested in bleeding edge C++ features
<geist>
just something that compiles some code and generates something valid is probably all you want
<geist>
heat: probably. honestly i dont remember. something about 8 or maybe 10 was harder to build and i remember havinv to futz about it a bunch
<geist>
i can probably just go through my toolchains repo history to see where the change was, but dont care
<geist>
and yes before someone points it out: i'm sure newer gccs have better frontend codegen which will help the backend even if it's not getting any new code, etc etc
<geist>
again, it's vax. you probably want to just have something that works at all
<mrvn>
and -Os
<geist>
yah. i remember it's codegen is not great in terms of picking ideal instructions. vax being the ciscyess if cisc arches would tend to mean it has infinity choices of how to generate any given thing
<geist>
especially with full memory-to-memory instructions
<geist>
and from what i remember gcc seems to be a little more register to register than i'd think.
<geist>
but that could be a case of the back end not getting any real support for a while so it's muching a bunch of match definitions for particular sequences the front end is generating
<geist>
so it ends up using fallbacks more often
<geist>
s/muching/missing
<heat>
geist, probably the largest problem could be having something written in e.g c++20
<heat>
not really codegen
<heat>
but if you're writing in C++20 do you really care about VAX? probably unlikely
<geist>
the biggest problem is VAX doesn't have IEEE754 floating point
<mrvn>
so what?
<geist>
so anything that uses libm or whatnot is completely broken
<heat>
ugh
<heat>
really?
<geist>
to be fair, VAX predates IEEE754 by like 5-10 years
<mrvn>
you mean the float hacks in libm won't work?
<geist>
so it's not like they were being dumbasses about it
<geist>
the bit layout of vax float is completely different
<geist>
also the number of mantissa/exponent bits is different, etc
<geist>
frnakly i think it's pretty logical to me
<mrvn>
does it have 16bit floats?
<geist>
i think so
<geist>
all the way up to 128 bit foats
<geist>
it's an etension of PDP-11 floats
<geist>
which is incidentaly i think where folks get the idea of mixed-endian. ie, each 16 bit word within the float is big endian, but multiple words are arranged little endian, i think
<geist>
or vice versa
<geist>
it's not as bad as you think, it's kinda logical. means the first 16 bit word that contains the sign and exponent aways comes first
<geist>
hmm, that doesn't list 16 bit format. i thought there was one (from pdp-11) maybe not
<geist>
(so actually the opposite. within each 16 bits the bits are arranged big endian, but the 16 bit words are arrange little endian in memory order)
<geist>
anyway. it's something you dot think abot much now since virtually all modern machines except for exotic DSPs or gpus are IEEE754 compliant, so floating point is generally just a thing you dont have to think about too much
<mrvn>
unless you interact with other systems or numeric applications I wouldn't think you have to think about it at all
<mrvn>
So what if the mantisse is smaller or bigger. Most stuff doesn't care.
<geist>
yah
<geist>
of course like i said things like libm would have to have an #if VAX fork of alot of their bit twiddling routines
<geist>
and i'm not sure they do anymore
<mrvn>
.oO(except printf. there you are majorly screwed)
<geist>
yah, printf is a good example
<mrvn>
if you have to write libc/libm then the bits matter. but otherwise ...
<geist>
yep. obviously folks used to deal with this when vax was more relevant, but i suspect most of that code has aged out. would be interesting to see if glibc still has support for this stuff, for example (or if it ever did)
<mrvn>
definetly where you want an old libc, which means an old gcc to build it.
<mrvn>
first think you need to install on VAX is distcc.
<mrvn>
thing even
<mrvn>
Does vax work on qemu?
<mrvn>
bash: qemu-system-vax: command not found
<samis>
you want simh for vax
<geist>
no, simh
<Ermine>
which is max register size on vax? maybe floating point operations can be emulated?
<geist>
32bit
<Ermine>
enough for float, but not enough for double
<mrvn>
you can do float with 2bit registers, just takes more operations
<geist>
yah i dont have it handy in front of me, but i had a little simh script to load my LK binary into it. simh operates on a startup script thing where you configure ht ehardware and then run a series of load/start/etc routines, effectively on its console
<Ermine>
like, gcc uses SSE registers to implement floating point stuff afaik
<geist>
so it's quite configurable. took me a while to find the right combination of stuff there
<geist>
well, that's because SSE actually implements floating point
<Ermine>
Ah
<geist>
thats not emulation, that's just using the SSE version of floating point. it completely supercedes x87
<mrvn>
that's vectorization
<geist>
well no there's also all the scalar SSE routines
<geist>
you are basically using the 0th slot of SSE for scalar floating point math
<Ermine>
Also, I tried to install MS QuickC to compile a program under DOS one day. It asked whether I had a coprocessor or do I need emulation library
<geist>
yah, wasn't terribly common before pentium to have a FPU on your x86 machine. i think the vast majority of use cases before then were actual programs that needed a lot of math
<geist>
probably later days of the 486 you might get a 486dx because it was faster and by then i bet the prices were coming down
<geist>
but in the 286 and 386 days it was an extra chip and probably non-trivial amount of $$
<Ermine>
there's an intel commercial about 486sx which can be upgraded
<geist>
yep, some mobos had an extra socket that you could buy a 487 to put in
<geist>
fun fact: the 487s were actually a full 486 with the fpu on board, and when you socketted it it basically shut down your original cpu and took over
<geist>
by then it was already simpler to just do that than try to keep a coherent coprocessor bus going on
<Ermine>
Megamind engineering
<geist>
i dont rembmer if all the 486 clones had a similar thing going on. i think maybe the amd486s just aways had an fpu
<Ermine>
Maybe someone tried to keep both processors on and get a multiprocessor system?
<geist>
for that you need a bunch of external logic, though there were SMP 486s
<geist>
that's where stuff like the ioapics and whatnot started coming into play. at that point ioapic and local apics were actually external chips that you stuffed on your motherboard to deal with irq routing
<geist>
then in pentium they pulled the 'local' apic side of the logic into the cpu die itself, and yo no longer needed a physical local apic
<Ermine>
ah indeed
fedorafan has quit [Ping timeout: 260 seconds]
bauen1 has joined #osdev
fedorafan has joined #osdev
gildasio1 has quit [Remote host closed the connection]
gildasio1 has joined #osdev
<Clockface>
how expensive is it to actually swap between CPU modes
<Clockface>
is it worse now that most programs dont ever do it?
<mrvn>
what cpu and what modes?
<Clockface>
any cpu made in the last 7 years
xenos1984 has quit [Read error: Connection reset by peer]
<Clockface>
and lets say protected mode and real mode
<mrvn>
you can't get back to real mode from long mode afaik
<Clockface>
i think you can
<Clockface>
i heard that some stuff switches between long and protected mode too
<mrvn>
there is a virtual mode for it but that works slightly different
<Clockface>
i read somewhere on the wiki that a version of macOS did it
<mrvn>
32bit / 64bit mode happens at no cost at the syscall interface
<Clockface>
where it was a 32 bit kernel that switched to 64 bit when necissary
<mrvn>
that's not what you do. You have a 64bit kernel with 32bit processes
<Clockface>
i remember reading about it last night
<Clockface>
and it sounds really screwed up
<Clockface>
but i think they actually did do it at one point
<mrvn>
you can't.
<mrvn>
64bit processes would call into a 64bit kernel.
<Clockface>
i think it had little stubbies that switched it into 32 bit mode for 64 bit processes
<Clockface>
unless i was dreaming
<mrvn>
I would say so. That would be insane
<Clockface>
but what about real mode and protected mode?
<Clockface>
it seems like it should be expensive but it also seems like its done a lot
<mrvn>
Kernels used to do that to do bios calls. But that's the deep deep past.
<mrvn>
It's a pain to do and not 100% real mode. Just something that behaves mostly like it.
<Clockface>
thats the thing, how much time do you lose on a mode switch?
<Clockface>
thats what im wondering
<mrvn>
tons. and bios is really slow.
<Clockface>
besides bios
<Clockface>
pretend the code on both ends is well written
<Clockface>
how much does the cpu slow itself down alone?
<mrvn>
the cpu doesn't slow down. the rom is just slow.
<mrvn>
and the 16bit code
<Clockface>
that makes sense
<mrvn>
loading segment register isn't fast either
<Clockface>
the switch itself though
<Clockface>
the instant the CPU swaps modes
<mrvn>
segment checks are slower too than the 0/4G setup modern kernels use
<Clockface>
is the toggle a fat pig or does it take a comparable amount of time to anything else that you might do
<Clockface>
thats what i dont get
<mrvn>
from what I remember it's not just a bit you flip. Although that flipping the mode is slow too.
<mrvn>
but really, why would you want to do it anyway?
<Clockface>
compatibility :D
<mrvn>
that's what bochs it for. There you can set the speed to run at the proper 16MHz so the game remains playable.
<mrvn>
Any hardware access faults and needs to be emulated from protected mode. you can imagine how fast that is when you use it to do bios / driver calls.
<mrvn>
i.e. to access hardware without native drivers.