[HN Gopher] The low-down on LOADALL (1990)
___________________________________________________________________
The low-down on LOADALL (1990)
Author : mmastrac
Score : 29 points
Date : 2021-01-18 17:12 UTC (1 days ago)
(HTM) web link (gist.github.com)
(TXT) w3m dump (gist.github.com)
| FartyMcFarter wrote:
| Piece of trivia:
|
| > ** 0F 05 hex **
|
| Nowadays this opcode is used for the "syscall" instruction.
| rahimiali wrote:
| isn't 0x80 the syscall opcode on x86?
| FartyMcFarter wrote:
| 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-...
| toast0 wrote:
| 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 wrote:
| that's indeed my confusion. thank you for explaining.
| tomcam wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| rahimiali wrote:
| 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 wrote:
| 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]
| mschaef wrote:
| 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.)
| pavlov wrote:
| _> "...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.
| TedDoesntTalk wrote:
| What was Windows/386?
| mschaef wrote:
| 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.
| pavlov wrote:
| IIRC, it was a version of Windows 2.1 which could multitask
| DOS applications using the 8086 virtualization mode
| available on the i386.
___________________________________________________________________
(page generated 2021-01-19 23:01 UTC)