clipka <ano### [at] anonymousorg> wrote:
> > Speaking of which, even though the 80386 processor was introduced
> > in 1985 (that's almost 30 years ago), PCs still boot up in 16-bit
> > mode. Yes, even the new 64-bit ones.

> Not all of them. Look up UEFI and coreboot.

An x86 CPU will start in 16-bit mode when it's powered-up. I don't think
there's any way to bypass that via anything. The only thing that a
32/64-bit BIOS can do is to make the switch to 32/64-bit mode earlier
in the bootup process.

However, such a BIOS could theoretically allow for a x86 CPU to drop
16-bit support completely (if the OS can, thanks to such a BIOS, assume
the CPU is already running in 32/64-bit mode when it boots.)

> > The very first thing that the OS does is to switch to either 32-bit
> > mode (if the CPU is that old) or to 64-bit mode. After that it will
> > usually never revert back to 16-bit mode ever again.

> I thought the 64-bit mode was exactly the same as the 32-bit one, except 
> that some memory pages are flagged differently?

Actually, if I have understood correctly, the 64-bit mode in an x86-64
architecture is quite different from its 32-bit mode. For instance, a
whole family of CPU opcodes are treated completely differently in
64-bit mode than in 32-bit mode (for example to account for the larger
number of available CPU registers.)

16-bit and 32-bit modes are much more tied together. For instance, you
can access 32-bit registers in 16-bit mode and vice-versa (and IIRC it
happens by using the exact same opcode prefix). However, the 64-bit mode
is so separate that you can't eg. use 64-bit CPU registers in 32-bit mode
at all.

There are some completely different CPU architectures where the
distinction between 32-bit and 64-bit modes is much more transparent.
The UltraSparc would be a perfect example. It's so transparent that it
doesn't even need separate modes for 32-bit and 64-bit code: They both
run just fine as-is, even if you mix them up. (The original Sparc
architecture was 32-bit, and the UltraSparc is 64-bit, but was designed
in such a manner that it can run old 32-bit code as-is, without having
to switch to any kind of compatibility mode, like the x86-64 has to.
32-bit code will use the same 64-bit registers as 64-bit code, but be
none the wiser.)

-- 
                                                          - Warp

Post a reply to this message

On 22/01/2014 1:40 AM, Francois Labreque wrote:
> not quite, but...
>
> Ever since I tried to install the latest Blender, whenever I boot my PC,
> I get the system32 folder that opens.  I suppose there's a registry
> entry somewhere that got created improperly and instead of trying to
> load "C:\Windows\System32\whatchamacallit.dll" or
> "%SYSTEM_ROOT%\System32\foobar.exe" it simply loads "C:\Windows\System32".
>
> How do I find out which one it is?  Regedit's search function is not
> smart enough to let me search for ( "system32" except when it's
> "system32\" )
>
>

I've seen this before, have a look here:

http://support.microsoft.com/kb/170086

Cheers Dre

Post a reply to this message

On 22/01/2014 04:54 PM, Warp wrote:
> Orchid Win7 v1<voi### [at] devnull>  wrote:
>> Next up: Why, in the year 2014, am I still running installers that have
>> 16-bit dithered logos? WTF?
>
> Obviously you need to be able to run it in safe mode...

I didn't think even Safe Mode runs in 16-bit colour any more. And even 
if it does... so make the OS convert from 24-bit down to 16-bit on the 
fly! Sheesh.

> Speaking of which, even though the 80386 processor was introduced
> in 1985 (that's almost 30 years ago), PCs still boot up in 16-bit
> mode. Yes, even the new 64-bit ones.

I got the impression that 64-bit CPUs cut back on some of the really 
ancient 16-bit stuff. (I don't have an actual site for that though.)

> The very first thing that the OS does is to switch to either 32-bit
> mode (if the CPU is that old) or to 64-bit mode. After that it will
> usually never revert back to 16-bit mode ever again.

Ah yes - by toggling line 20 on the address bus. Obviously. (WTF?)

Well, that's only in so-called "IBM PC-compatibles". (How compatible are 
any of these with the 30-year old dinosaur?) I think the Apple Mac does 
it differently...

> Support for 16-bitness increases the CPU complexity and thus its price,
> and is overall just dead weight that has little to no purpose.

Oh, but that's not all.

Did you know that your graphics card starts up emulating an 
IBM-manufactured video board from 27 years ago? And then you have to run 
special driver software to turn off all the pointless emulation and put 
the card into 24-bit, memory-mapped mode at a real-world screen 
resolution. Go figure...

Overall, PCs are just *full* of this crap. (Some of you may remember I 
once set out on a misguided quest to "write my own OS". I read up on 
some of this stuff.) And yet, when somebody produces a technically 
superior system that lacks lashings of backwards compatibility, nobody 
actually buys it...

Post a reply to this message

>> Speaking of which, even though the 80386 processor was introduced
>> in 1985 (that's almost 30 years ago), PCs still boot up in 16-bit
>> mode. Yes, even the new 64-bit ones.
>
> Not all of them. Look up UEFI and coreboot.

As Warp says, this is a function of the CPU, not the OS or the BIOS or 
anything else. It's in Intel and AMD's reference manuals. (Although I 
haven't looked into 64-bit; maybe it starts in a less-ancient emulation 
mode?)

> I thought the 64-bit mode was exactly the same as the 32-bit one, except
> that some memory pages are flagged differently?

No. In "long mode" (i.e., 64-bit mode) there are several brand new CPU 
registers available. It doesn't just make the existing ones wider. This 
means that code which is very register-heavy should hypothetically run 
faster, since you can hold more stuff in registers rather than on the 
stack or the heap.

IIRC, POV-Ray runs about 6% faster in long mode, indicating that 
actually the L1 cache makes the difference pretty damned moot anyway. 
(Contrary to my expectations.)

Post a reply to this message

> An x86 CPU will start in 16-bit mode when it's powered-up. I don't think
> there's any way to bypass that via anything. The only thing that a
> 32/64-bit BIOS can do is to make the switch to 32/64-bit mode earlier
> in the bootup process.
>
> However, such a BIOS could theoretically allow for a x86 CPU to drop
> 16-bit support completely (if the OS can, thanks to such a BIOS, assume
> the CPU is already running in 32/64-bit mode when it boots.)

Let us hope this happens someday.

> There are some completely different CPU architectures where the
> distinction between 32-bit and 64-bit modes is much more transparent.
> The UltraSparc would be a perfect example. It's so transparent that it
> doesn't even need separate modes for 32-bit and 64-bit code: They both
> run just fine as-is, even if you mix them up.

The Motorola 68000 was a 16-bit CPU, but it had opcodes for 32-bit 
operations. It's just that they take twice as long. Then if you upgrade 
to an M68020 (?), it's 32-bit, and all your software goes 2x as fast. 
(Because ALMOST EVERYTHING uses mostly 32-bit arithmetic.)

Going to 64-bit took longer, because nobody really needs 64-bit integer 
arithmetic (and we already have 80-bit floating-point arithmetic), so 
the only real advantage is increased address space. [Which only matters 
once GB-sized RAM started to be manufactured.]

Post a reply to this message

Am 22.01.2014 23:19, schrieb Orchid Win7 v1:
> On 22/01/2014 04:54 PM, Warp wrote:
>> Orchid Win7 v1<voi### [at] devnull>  wrote:
>>> Next up: Why, in the year 2014, am I still running installers that have
>>> 16-bit dithered logos? WTF?
>>
>> Obviously you need to be able to run it in safe mode...
>
> I didn't think even Safe Mode runs in 16-bit colour any more. And even
> if it does... so make the OS convert from 24-bit down to 16-bit on the
> fly! Sheesh.
>
>> Speaking of which, even though the 80386 processor was introduced
>> in 1985 (that's almost 30 years ago), PCs still boot up in 16-bit
>> mode. Yes, even the new 64-bit ones.
>
> I got the impression that 64-bit CPUs cut back on some of the really
> ancient 16-bit stuff. (I don't have an actual site for that though.)

That might well be. After all, you could emulate them via unknown-opcode 
traps.


>> The very first thing that the OS does is to switch to either 32-bit
>> mode (if the CPU is that old) or to 64-bit mode. After that it will
>> usually never revert back to 16-bit mode ever again.
>
> Ah yes - by toggling line 20 on the address bus. Obviously. (WTF?)

No, no - that A20 line thing is just for a small detail of the 16-bit mode.

> Well, that's only in so-called "IBM PC-compatibles". (How compatible are
> any of these with the 30-year old dinosaur?) I think the Apple Mac does
> it differently...

I'd be surprised if Macs came without A20 line gate. After all, it's the 
type of logic that's needed for IBM PC-compatibility but has been moved 
from discrete gates on the mainboard into the chipset decades ago already.


> Overall, PCs are just *full* of this crap. (Some of you may remember I
> once set out on a misguided quest to "write my own OS". I read up on
> some of this stuff.) And yet, when somebody produces a technically
> superior system that lacks lashings of backwards compatibility, nobody
> actually buys it...

... because of that very lack of backwards compatibility.

Actually, MS-DOS - and probably the IBM PCs as well - wouldn't have had 
any chance of success in the first place, had it not been for MS-DOS's 
backwards compatibility with CP/M at the application programming level.

Post a reply to this message

Am 22.01.2014 23:19, schrieb Orchid Win7 v1:

> (Some of you may remember I
> once set out on a misguided quest to "write my own OS". I read up on
> some of this stuff.)

That does sound like an intriguing challenge, provided you don't set out 
to design the best OS that has ever been.

If you get to the point where you can compile, link and run a "Hello 
World" C program on that platform, that's certainly good enough for 
starters.


And if PC hardware seems too messy and non-standardized (which most 
certainly is the case), something like the Raspberry Pi might be an 
interesting target.


Then again, why design a whole OS if I'd only want to run a very limited 
set of programs on it anyway... it can't be too complicated to build a 
POV-Ray version that runs directly atop the BIOS, can it? :-P

Post a reply to this message

On Thu, 23 Jan 2014 01:14:01 +0100, clipka wrote:

>> I got the impression that 64-bit CPUs cut back on some of the really
>> ancient 16-bit stuff. (I don't have an actual site for that though.)
> 
> That might well be. After all, you could emulate them via unknown-opcode
> traps.

I don't know if it's the case or not, but I had a recent discussion with 
someone about supporting NetWare 2.x (don't ask) on modern hardware, and 
the question of whether the A20 line was still supported on modern 
processors came up, because at least 2.15 and earlier require that.

Jim
-- 
"I learned long ago, never to wrestle with a pig. You get dirty, and 
besides, the pig likes it." - George Bernard Shaw

Post a reply to this message

On 1/22/2014 5:14 PM, clipka wrote:
>> Well, that's only in so-called "IBM PC-compatibles". (How compatible are
>> any of these with the 30-year old dinosaur?) I think the Apple Mac does
>> it differently...
>
> I'd be surprised if Macs came without A20 line gate. After all, it's the
> type of logic that's needed for IBM PC-compatibility but has been moved
> from discrete gates on the mainboard into the chipset decades ago already.
>

I thought that, some time back, the only "functional" difference between 
Mac and PC had finally come down to an extra chip on the board, which 
basically prevented the OS from booting, if it wasn't on a machine that 
had it, and.. I am guessing the GUI functionality isn't in firmware/ROM 
anymore, right? But, there was a whole huge thing with trying to get PC 
stuff to boot on a Mac, and a Mac to boot on standard PC hardware, and 
it all came down, not to architectural differences, so much as just, 
"There is this extra chip on the board."

Or, maybe I was just imagining that?

-- 
Commander Vimes: "You take a bunch of people who don't seem any 
different from you and me, but when you add them all together you get 
this sort of huge raving maniac with national borders and an anthem."

Post a reply to this message

>> (Some of you may remember I
>> once set out on a misguided quest to "write my own OS". I read up on
>> some of this stuff.)
>
> That does sound like an intriguing challenge, provided you don't set out
> to design the best OS that has ever been.

Rather, I set out to design an OS that doesn't work like Unix, and 
doesn't work like Windows. (Seemingly all extent OS designs are based on 
one or the other - but I remember a time before that...)

> If you get to the point where you can compile, link and run a "Hello
> World" C program on that platform, that's certainly good enough for
> starters.

Again, my goal was to design an OS where nothing is ever written in C, 
but rather written in safe higher-level languages with don't have buffer 
overrun exploits all over the place.

> And if PC hardware seems too messy and non-standardized (which most
> certainly is the case), something like the Raspberry Pi might be an
> interesting target.

The Raspberry Pi didn't exist ten years ago, but now that I think about 
it, that *would* be an interesting target...

> Then again, why design a whole OS if I'd only want to run a very limited
> set of programs on it anyway... it can't be too complicated to build a
> POV-Ray version that runs directly atop the BIOS, can it? :-P

The key problem with writing your own OS is that it's almost impossible 
to debug it! Not if you run it on real hardware, anyway. Last I checked, 
most VM software isn't really designed for this kind of thing either...

It's probably much, much easier to design something like the Java VM, 
and then write your own proto-OS that runs inside that. And if you ever 
get anywhere with that, *then* try targeting bare metal...

Post a reply to this message