5 ms·

The low-down on LOADALL (1990)

36 points by mmastrac 6y ago

tomcam 6y ago
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.
- h2odragon 6y ago
  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.
- tenebrisalietum 6y ago
  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.
  - emily-c 6y ago
    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.
FartyMcFarter 6y ago
Piece of trivia: > ** 0F 05 hex ** Nowadays this opcode is used for the "syscall" instruction.
- rahimiali 6y ago
  isn't 0x80 the syscall opcode on x86?
  - FartyMcFarter 6y ago
    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-int-0x80-or-syscall-in-32-bit-code-on-linux https://stackoverflow.com/questions/12806584/what-is-better-...
    - rahimiali 6y ago
      that's indeed my confusion. thank you for explaining.
    - toast0 6y ago
      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.
rahimiali 6y ago
This one quote was like biting into a madeleine and being transported into a distant past: "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".
pavlov 6y ago
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 https://en.wikipedia.org/wiki/Intel_80286]
- mschaef 6y ago
  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.)
  - TedDoesntTalk 6y ago
    What was Windows/386?
    - pavlov 6y ago
      IIRC, it was a version of Windows 2.1 which could multitask DOS applications using the 8086 virtualization mode available on the i386.

36 points by mmastrac 6y ago

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.

h2odragon 6y ago
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.
tenebrisalietum 6y ago
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.
- emily-c 6y ago
  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.

FartyMcFarter 6y ago

Piece of trivia: > ** 0F 05 hex ** Nowadays this opcode is used for the "syscall" instruction.

rahimiali 6y ago
isn't 0x80 the syscall opcode on x86?
- FartyMcFarter 6y ago
  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-int-0x80-or-syscall-in-32-bit-code-on-linux https://stackoverflow.com/questions/12806584/what-is-better-...
  - rahimiali 6y ago
    that's indeed my confusion. thank you for explaining.
  - toast0 6y ago
    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.

rahimiali 6y ago

This one quote was like biting into a madeleine and being transported into a distant past: "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".

pavlov 6y ago

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 https://en.wikipedia.org/wiki/Intel_80286]

mschaef 6y ago
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.)
- TedDoesntTalk 6y ago
  What was Windows/386?
  - pavlov 6y ago
    IIRC, it was a version of Windows 2.1 which could multitask DOS applications using the 8086 virtualization mode available on the i386.