The low-down on LOADALL (1990)(gist.github.com)
gist.github.com
The low-down on LOADALL (1990)
https://gist.github.com/luelista/557dd8f7f5b28cc1f9c28776c88ec347
19 comments
The 80286 was a pretty weird CPU. I don't think Intel anticipated that it would be primarily used for faster IBM PC compatibles.
Wikipedia seems to confirm this:
"Intel did not expect personal computers to use the 286. The CPU was designed for multi-user systems with multitasking applications, including communications (such as automated PBXs) and real-time process control." [https://en.wikipedia.org/wiki/Intel_80286]
Wikipedia seems to confirm this:
"Intel did not expect personal computers to use the 286. The CPU was designed for multi-user systems with multitasking applications, including communications (such as automated PBXs) and real-time process control." [https://en.wikipedia.org/wiki/Intel_80286]
Around this time there was another significant CPU architecture in play at Intel, the iAPX 432. The 432 was the intentional follow on to the 8-bit series (8080) and suffered from a number of the usual second system effects - it was big, complicated, and slow. The 8086/8 was a stop gap measure while the 432 was being sorted out, and my understanding is also that the 8087 math chip was essentially a 432 component that had been redesigned to work with the other chip series.
Viewed in the context of the 432, it's not hard to imagine Intel viewing an 8086 follow on chip as a niche market CPU while their would-be-anointed successor takes the more mainstream PC market.
What's maybe more interesting to consider is the role of the 80386, and how its design process might have gone. By the time of the 80386, Intel built in features to the chip explicitly useful for the purpose of bringing multitasking to the PC space. One of the 386's many noteworthy features, was 'V86' mode, which was designed to allow it to easily multitask multiple real mode 8086/8 apps at the same time. This was essentially a 'run several DOS programs at once' feature, and there were a couple major PC "OS"'s that used it - most notably Windows/386 and DesqView/386.
(You should also note that this is not close to the first time that Intel tried to get away from x86 - the iAPX 432, i860, and Itanium all represent varying attempts to achieve that goal.)
Viewed in the context of the 432, it's not hard to imagine Intel viewing an 8086 follow on chip as a niche market CPU while their would-be-anointed successor takes the more mainstream PC market.
What's maybe more interesting to consider is the role of the 80386, and how its design process might have gone. By the time of the 80386, Intel built in features to the chip explicitly useful for the purpose of bringing multitasking to the PC space. One of the 386's many noteworthy features, was 'V86' mode, which was designed to allow it to easily multitask multiple real mode 8086/8 apps at the same time. This was essentially a 'run several DOS programs at once' feature, and there were a couple major PC "OS"'s that used it - most notably Windows/386 and DesqView/386.
(You should also note that this is not close to the first time that Intel tried to get away from x86 - the iAPX 432, i860, and Itanium all represent varying attempts to achieve that goal.)
What was Windows/386?
pavlov is right.
Early versions of Windows all ran in real mode. Multiple Windows programs were loaded into the same real mode address space (no protection) and co-operatively multitasked based on the GUI's messaging infrastructure. (A program could just stop processing GUI messages and totally monopolize the CPU.) There was also some limited support for memory relocation via a block lock/unlock mechanism built into the memory manager. If you wanted to run a DOS program, this was all suspended, with the DOS program given control over the full machine in the interim.
What Windows/386 did is put a 386-specific V86 multitasker called VMM underneath all of this. This multitasker had isolation between the processes it ran, one of which would be the Windows GUI environment I described above and others could be other DOS Programs, for which there were also provisions to put the output into a window of the GUI. This is really the first moment Windows got protected mode support, although none of the user processes actually saw the larger address space.
It's Windows 3.0 that let the GUI itself run in protected mode, albeit still with 64K segmentation. Combined with some graphics and usability improvements in 3.0, this is really why 3.0 'got it right' in terms of feature set and price point.
Windows for Workgroups 3.11 then moved the file system to protected mode, a product called Win32s let Windows programs themselves use 32-bit segment addressing, and combination of all of that that was the foundation for the 'fully 32-bit' Windows 95, which just moved a bunch more functionality into 32-bit code and the VMM 32-bit multitasker originally introduced in Windows/386.
Early versions of Windows all ran in real mode. Multiple Windows programs were loaded into the same real mode address space (no protection) and co-operatively multitasked based on the GUI's messaging infrastructure. (A program could just stop processing GUI messages and totally monopolize the CPU.) There was also some limited support for memory relocation via a block lock/unlock mechanism built into the memory manager. If you wanted to run a DOS program, this was all suspended, with the DOS program given control over the full machine in the interim.
What Windows/386 did is put a 386-specific V86 multitasker called VMM underneath all of this. This multitasker had isolation between the processes it ran, one of which would be the Windows GUI environment I described above and others could be other DOS Programs, for which there were also provisions to put the output into a window of the GUI. This is really the first moment Windows got protected mode support, although none of the user processes actually saw the larger address space.
It's Windows 3.0 that let the GUI itself run in protected mode, albeit still with 64K segmentation. Combined with some graphics and usability improvements in 3.0, this is really why 3.0 'got it right' in terms of feature set and price point.
Windows for Workgroups 3.11 then moved the file system to protected mode, a product called Win32s let Windows programs themselves use 32-bit segment addressing, and combination of all of that that was the foundation for the 'fully 32-bit' Windows 95, which just moved a bunch more functionality into 32-bit code and the VMM 32-bit multitasker originally introduced in Windows/386.
> This is really the first moment Windows got protected mode support, although none of the user processes actually saw the larger address space.
What about the 286 protected mode support. Did that come later?
What about the 286 protected mode support. Did that come later?
> What about the 286 protected mode support. Did that come later?
Yeah... Protected mode came to Windows in fits and starts. Windows/386 introduced it via the V86 multitasker. The Windows VMM layer ran in protected mode, but all the client processes ran in real mode. The implication of this is that they were limited to a 20-bit address space, plus whatever auxiliary memory you could map in with a bank switching standard like EMS.
So at this point (up to 1990 and Windows 3.0), all Windows programs ran in real mode and shared a single 1MB heap. The official path forward from this advocated by the IBM/Microsoft partnership was OS/2. OS/2 put everything in 286 protected mode, but had enough API and EXE format differences that you had to have OS/2 specific software to use it.
However... in the late 80's, a Microsoft engineer named David Weise came up with a way to run Windows itself in protected mode that mostly retained compatibility with existing Windows software. (There was a flag that had to be set in EXE's that enabled protected mode operation, but the format and API's were all exactly the same. This is true to the extent that there were utilities that would toggle just the flag and often let you run an otherwise unmodified program.)
https://landley.net/history/mirror/ms/davidweise.html
It was Weise's work that enabled Windows 3.0, which came with a largely fulfilled process of getting you OS/2's larger address space, but at a much lower cost of entry. Part of the way they achieved that was to let it run in three modes:
* Real mode - This is essentially how Windows 2.x ran. Everything in real mode, and DOS apps preempted everything.
* Standard mode - This was the new addition. This gave you protected mode for compatible Windows apps, but they had to be marked compatible. DOS apps still preempted everything
* "386 Enhanced" mode - This was the Windows/386 equivalent for bigger Windows 3.0. (But it came in the same box as part of the same SKU.) It combined the new protected mode Windows features along with the ability to pre-emptively multitask DOS apps.
Note that everything I've mentioned (aside from the low level VMM multitasker) used 16-bit segment offsets. So even though your address space was 20 bits, you still had to worry about segment arithmetic for blocks of memory beyond 64K. 32-bit segments were fully native to the Windows NT kernel and came into the original windows codebase via Win32s, which was essentially the Windows equivalent of a DOS extender.
(Note that interestingly, this all implies that 386-specific protected mode came to Windows first, with 286-specific protected mode later.)
Yeah... Protected mode came to Windows in fits and starts. Windows/386 introduced it via the V86 multitasker. The Windows VMM layer ran in protected mode, but all the client processes ran in real mode. The implication of this is that they were limited to a 20-bit address space, plus whatever auxiliary memory you could map in with a bank switching standard like EMS.
So at this point (up to 1990 and Windows 3.0), all Windows programs ran in real mode and shared a single 1MB heap. The official path forward from this advocated by the IBM/Microsoft partnership was OS/2. OS/2 put everything in 286 protected mode, but had enough API and EXE format differences that you had to have OS/2 specific software to use it.
However... in the late 80's, a Microsoft engineer named David Weise came up with a way to run Windows itself in protected mode that mostly retained compatibility with existing Windows software. (There was a flag that had to be set in EXE's that enabled protected mode operation, but the format and API's were all exactly the same. This is true to the extent that there were utilities that would toggle just the flag and often let you run an otherwise unmodified program.)
https://landley.net/history/mirror/ms/davidweise.html
It was Weise's work that enabled Windows 3.0, which came with a largely fulfilled process of getting you OS/2's larger address space, but at a much lower cost of entry. Part of the way they achieved that was to let it run in three modes:
* Real mode - This is essentially how Windows 2.x ran. Everything in real mode, and DOS apps preempted everything.
* Standard mode - This was the new addition. This gave you protected mode for compatible Windows apps, but they had to be marked compatible. DOS apps still preempted everything
* "386 Enhanced" mode - This was the Windows/386 equivalent for bigger Windows 3.0. (But it came in the same box as part of the same SKU.) It combined the new protected mode Windows features along with the ability to pre-emptively multitask DOS apps.
Note that everything I've mentioned (aside from the low level VMM multitasker) used 16-bit segment offsets. So even though your address space was 20 bits, you still had to worry about segment arithmetic for blocks of memory beyond 64K. 32-bit segments were fully native to the Windows NT kernel and came into the original windows codebase via Win32s, which was essentially the Windows equivalent of a DOS extender.
(Note that interestingly, this all implies that 386-specific protected mode came to Windows first, with 286-specific protected mode later.)
IIRC, it was a version of Windows 2.1 which could multitask DOS applications using the 8086 virtualization mode available on the i386.
Windows/386 is Windows 2.x that required 386 processor.
To be more confusing - Windows 2.0 have 2 versions. First is regular that runs on 8086 and other was Windows/386 2.0.
But confusion continue with Windows 2.1. There was also two versions - Windows/286 2.1 (that also can run on 8086) and Windows/386 2.1.
Windows 3.0 was like One-Size-Fits-All because minimum was 8086. Except when you run it on protected mode. Windows 3.0 with Multimedia minimum was 286. And Windows for Workgroups 3.11 minimum was 386 because dropped standard mode.
To be more confusing - Windows 2.0 have 2 versions. First is regular that runs on 8086 and other was Windows/386 2.0.
But confusion continue with Windows 2.1. There was also two versions - Windows/286 2.1 (that also can run on 8086) and Windows/386 2.1.
Windows 3.0 was like One-Size-Fits-All because minimum was 8086. Except when you run it on protected mode. Windows 3.0 with Multimedia minimum was 286. And Windows for Workgroups 3.11 minimum was 386 because dropped standard mode.
> "...Intel tried to get away from x86 - the iAPX 432, i860, and Itanium all represent varying attempts to achieve that goal."
It's a strange irony that none of these homegrown attempts worked out, but x86 is now threatened by the one external architecture where Intel was a performance leader in 2000-2005 with their StrongARM / XScale chips.
Intel giving up on ARM in 2006 was IMO one of the greatest strategic blunders of all time.
It's a strange irony that none of these homegrown attempts worked out, but x86 is now threatened by the one external architecture where Intel was a performance leader in 2000-2005 with their StrongARM / XScale chips.
Intel giving up on ARM in 2006 was IMO one of the greatest strategic blunders of all time.
I cannot wait for people smarter than I am to contribute to this conversation. I have so many questions, among them, what is the modern equivalent or is it in continued used to this day? I wrote a massive amount of code in assembly for my compiler back in the 80s and this would’ve been really sweet to know about.
If it has been kept over for compatibility purposes, I would like to know whether it has been completely superseded by other instructions or if it still has a place in cogeneration.
If it has been kept over for compatibility purposes, I would like to know whether it has been completely superseded by other instructions or if it still has a place in cogeneration.
I think most of the chip testing facilities like LOADALL eventually got subsumed into the System Management Mode mechanism, triggered by "System Management Interrupts." It's become used by the portion of UEFI/BIOS firmware that's continually running in the background controlling fans and power, and has the ability to run completely hidden from the operating system by design.
This is correct. The functionality of LOADALL now largely happens in the RSM instruction which returns back to normal execution context from an SMI. In modern firmware, before the SMI handler is invoked by the SMM dispatcher the firmware will switch the mode away from real mode and have its own GDT/descriptors. All this needs to be restored on SMI return thus RSM will parse a specially formatted block of processor context to dump everything back.
286 only, in that form; there's similar capabilities in modern cpus but they're so different its not really comparable.
once you toss aside the OS and look at the hardware with "what can i make it do?" there's still some joyous horrors possible. DOS was good in that it was so little OS to throw aside, where it got between you and the hardware at all.
once you toss aside the OS and look at the hardware with "what can i make it do?" there's still some joyous horrors possible. DOS was good in that it was so little OS to throw aside, where it got between you and the hardware at all.
Piece of trivia:
> ** 0F 05 hex **
Nowadays this opcode is used for the "syscall" instruction.
> ** 0F 05 hex **
Nowadays this opcode is used for the "syscall" instruction.
isn't 0x80 the syscall opcode on x86?
You might be thinking of "int 0x80" which gets assembled to 0xCD 0x80.
According to this stackoverflow answer, "int 0x80" is a Linux-specific legacy way to do syscalls:
https://stackoverflow.com/questions/12806584/what-is-better-...
According to this stackoverflow answer, "int 0x80" is a Linux-specific legacy way to do syscalls:
https://stackoverflow.com/questions/12806584/what-is-better-...
int 0x80 is legacy, and x86, but it isn't specific to Linux.
FreeBSD (and AFAIK other BSDs) also use(d) it; most likely any Unix system on x86 that doesn't require a processor with sysenter/syscall instructions would use int 0x80 to do syscalls.
FreeBSD (and AFAIK other BSDs) also use(d) it; most likely any Unix system on x86 that doesn't require a processor with sysenter/syscall instructions would use int 0x80 to do syscalls.
that's indeed my confusion. thank you for explaining.
"The power of being able to re-program ANY and ALL of the registers of the CPU with one single instruction opens up a whole new world of possibilities. Including, but not limited to:... installing most of the guts of custom TSR's".