https://www.righto.com/2023/04/8086-microcode-string-operations.html
Intel introduced the 8086 microprocessor in 1978. This processor ended up being hugely influential, setting the path for the x86 architecture that is extensively used today. One interesting feature of the 8086 was instructions that can efficiently operate on blocks of memory up to 64K bytes long. These instructions rapidly copy, compare, or scan data and are known as "string" instructions.
In this blog post, I explain string operations in the 8086, analyze the microcode that it used, and discuss the hardware circuitry that helped it out.
[...] I'll explain the behavior of an ALU micro-operation since it is important for string operations. The Arithmetic/Logic Unit (ALU) is the heart of the processor, performing addition, subtraction, and logical operations. The ALU has three temporary input registers that are invisible to the programmer: tmpA, tmpB, and tmpC. An ALU operation takes its first argument from any temporary register, while the second argument always comes from tmpB. Performing an ALU operation requires two micro-instructions. The first micro-instruction specifies the ALU operation and source register, configuring the ALU. For instance, ADD tmpA configures the ALU to add the tmpA register to the default tmpB register. In the next micro-instruction (or a later one), the ALU result can be accessed through a special register called Σ (SIGMA) and moved to another register.
I'll also explain the memory read and write micro-operations. A memory operation uses two internal registers: IND (Indirect) holds the memory address, while OPR (Operand) holds the word that is read or written. A typical memory micro-instruction for a read is R DS,BL. This causes the Bus Interface Unit to compute the memory address by adding the Data Segment (DS) to the IND register and then perform the read. The Bus Interface Unit determines if the instruction is performing a byte operation or a word operation and reads a byte or word as appropriate, going through the necessary bus cycles. The BL option3 causes the Bus Interface Unit to update the IND register as appropriate,3 incrementing or decrementing it by 1 or 2 depending on the Direction Flag and the size of the access (byte or word). All of this complexity happens in the hardware of the Bus Interface Unit and is invisible to the microcode. The tradeoff is that this simplifies the microcode but makes the chip's hardware considerably more complicated.
(Score: 3, Interesting) by Tork on Friday April 07, @12:07AM (14 children)
My first PC was a 286 and I will never forget extended vs expanded memory and all that other nonsense that prevented me from seeing all of Wing Commander's bells and whistles. I was just curious if the explanation above for how the 808X addressed memory is similar to why having more than 640k of memory on a 286 was a real chore to use...? I realize I'm talking about different processors separated by a generation (or more...?) of evolution, but I never really did get why a 386 was needed for expanded memory. This description of how a megabyte of memory was addressed has given me a spark of understanding. I think. Heh
Slashdolt Logic: "25 year old jokes about sharks and lasers are +5, Funny." 💩
(Score: 5, Informative) by owl on Friday April 07, @01:34AM
The explanation is partly the reason. The part that was similar was the 64K max segment size. The 286 had the same 64K segment size limit that the 8086/88 chips had (largely because the 266 was still a 16-bit processor, and 16-bits (by itself) can address at most 64K). The 286 also kept the same four segment registers of the 8086/88 chips (CS, DS, SS, and ES) which meant that without changing segment register values, it could address at most 4x64K of memory at a time. And 25% of that was for code (CS) and another 25% was for stack (SS) so it would really only have 128k available as "general data storage". So this was 'partly' the reason, the limits imposed by the "segmentation system".
The other reason was that while you had a '286 CPU, you were running it as a glorified fast 8086 unless you happened to have one of the very few OS's that eventually arrived and that directly used it in 'protected mode' And when operating as a 'fast 8086' it was also subject to the exact same 1MB maximum addressable memory limit of the 8086/88 (in 'real mode' it operated exactly as a "fast 8086", including the above way of "addressing" using the segment registers). So while you might have had 4MB of physical ram installed, when using DOS and/or early windows (pre. 386 windows) the CPU simply could not talk to the extra 3MB of memory beyond the 1MB barrier.
The 'extended/expanded' nonsense was the way that grew up to allow programs, still written to run in 8086/286 'real mode' to address that memory. And they involved switching the chip into protected mode, copying memory around, and resetting back out of protected mode to real mode. The fact that any of this even worked at all, and was still faster than a 8086, was amazing all in and of itself.
The 386 was 32-bits, so its addresses could directly reference 4G of memory (not that any 386 ever had 4G attached). That was one reason.
But the big reason was that the 386 introduced two new features that made doing expanded memory (which is different from 'extended' memory) trivial with the CPU hardware. Those two features being the paged memory management unit (pMMU) and the virtual 8086 mode. The paged MMU allowed software to play games by making any 4k range of memory (aligned on a 4k boundary) appear to exist to programs running on the CPU as if it was at any address within the 4G max the chip could address. So while the 4k page might physically exist at address 0x12345000 in the memory hardware the pMMU can be setup to make a running program see that page as existing at address 0x00001000 instead. And because "expanded" memory started out as bank switching hardware to make memory, on an EMS card plugged into an ISA slot, appear to reside at (IIRC) 0xC0000 in the original IBM-PC memory map, the 386's pMMU could be programmed to make any desired set of those 4k pages of memory beyond 1MB appear to reside at 0xC0000, just like all the EMS using software expected.
The 286's segment registers could not be setup to perform that trick. They let you add "protection" to 64K max sized zones of memory, but they could not be setup to make memory, physically at 0x12345000, appear to be available at 0xC0000.
Then, with v8086 mode, your "EMS driver" could set things up so your DOS programs were actually running in v8086 mode, completely unaware that they were doing so. And because in v8086 mode, the pMMU was active, the "EMS driver" could then use the pMMU hardware to do the old hardware style "bank switching" that IBM-PC EMS cards did to add memory, and your EMS using programs thought they had an EMS hardware card plugged in.
(Score: 2) by Mojibake Tengu on Friday April 07, @01:52AM (10 children)
"640 kB ought to be enough for anybody"
https://en.wikiquote.org/wiki/Talk:Bill_Gates [wikiquote.org]
Though today's Microsoft propaganda (and Gates' blatant denial) about classical quote saying "Bill Gates never said "640 kB ought to be enough for anybody" is a spectacular example of current reality inversion by controlled media.
At least some of us are still remembering well.
The edge of 太玄 cannot be defined, for it is beyond every aspect of design
(Score: 2) by RS3 on Friday April 07, @02:08AM (6 children)
AFAIK it's more of a form of humor, maybe better appreciated by US tech people. I ascribe it more to being an "urban legend", "common misconception", rumor, etc. Of course the media help spread such things, and "freedom of the press" guarantees there will be some mistakes, so caveat emptor. AFAIK, Gates had nothing to do with Intel's CPU designs, nor IBM's choice of an Intel CPU for the PC, nor the memory map thereof.
(Score: 2) by Mojibake Tengu on Friday April 07, @02:24AM (5 children)
Yet for serious software he could adopt 68000 architecture instead of x86. He said it exactly in this context, to defend technical decadence.
The edge of 太玄 cannot be defined, for it is beyond every aspect of design
(Score: 3, Interesting) by RS3 on Friday April 07, @02:55AM (3 children)
In engineering many compromises are made, some for not so apparent reasons, often by short-sighted management. I'm not in charge.
Apple went with the 68000. The story I heard was that IBM wanted too many concessions from a CPU vendor, and too much control over the CPU designs. Intel was small and close to bankruptcy, and Motorola was generally a big company and said no way. It's quite self-evident that in the past 40 years, 30 for sure, that Intel has made many many design changes and functional additions to accommodate Microsoft.
Take it a step further: the RISC vs. CISC argument has raged as long as I can remember. I don't see any true winners- they both have advantages and disadvantages. I'll argue that today's "RISC" machines are far more complex than 30 or 40 years ago CISC machines. I'm okay with it- I'm happy with options. :)
(Score: 4, Informative) by owl on Friday April 07, @03:48AM (2 children)
The story I read somewhere (sadly, long ago lost the reference to said story) was that part of the "engineering concessions" that led to IBM picking the Intel 8088 for the IBM-PC was that IBM wanted a CPU that had a second source vendor (in case the primary goes belly up, or has a Fab. fire or some other "issue") and Intel had a "second source" vendor in AMD. AMD was an official licensed Intel second source vendor all the way through the 386 chip Intel cut them off at the 486 chip point. They built "identical" chips to Intel's during this timeframe.
The other part of the same story was, at the time IBM was designing the IBM-PC, the Intel chip was on the market, available, and available in quantity. Motorola's 68000 was not yet in production, and Motorola was apparently quoting IBM something like a 9+ month wait before the first CPU's would even be available for initial testing. And Motorola had no second source available for the 68000.
So IBM picked the chip that met their first requirement (must have second source available) and that was also on the market and available in quantity over the chip that was not yet even ready for its first initial small production run.
(Score: 2) by RS3 on Friday April 07, @04:16AM (1 child)
Wow, that all fits, thanks. IIRC up til that point IBM made all their own parts, or like you said, required at least a second source, so the IBM PC was a big move away from IBM proprietary stuff, using all electronics industry standard parts. Also IIRC IBM had not used TTL. Another IIRC, IBM never expected the PC to be as successful as it ended up being.
I don't spend much time thinking about it, but I do wonder how different the world would be if IBM had chosen Motorola 68000.
(Score: 3, Informative) by owl on Friday April 07, @02:13PM
IBM still makes a majority of their own chips. I've seen it said that if IBM were included in the ranking of DRAM chip makers that they would rank somewhere around #1 or #2 in the world in yearly output. They don't get included because they use all their own production in their own big-iron systems.
I very much doubt IBM realized what level of success the PC would ultimately have when they started the project. It was likely seen as something of a "loss leader" to keep from losing lower end office worker seats to machines that did not have the blue initials on them, and thereby keep those businesses in IBM's services contracts business. "Oh, you've outgrown your PC, well we have this next level up Mini right here, we can install it for you tomorrow and you'll be on your way once again...."
(Score: 3, Insightful) by owl on Friday April 07, @02:30PM
Except Bill G. didn't "adopt architectures" anywhere (and certainly not in the time before the PC arch. took over the world). Microsoft simply provided software for the CPU their customer picked out. If IBM had picked the TI chip from the 99/4a instead, MS would have been more than happy to supply a PC-DOS 99/4a version. Had IBM picked the 68000, PC/MS-DOS would have been Motorola 68000 code. MS (and Bill G) didn't care what CPU you used, they were in the market of providing you with software for your system (you pick the system).
(Score: 3, Funny) by owl on Friday April 07, @04:06AM (2 children)
Yes, the quote seems nonsensical today, what with our 16GiB of memory systems being as common as flies.
But, whether or not BG said, or didn't say, the quote, if you consider the quote in context of 1982, where the IBM-PC was competing with Atari 800's (max 48K without some fancy hardware cards), Apple II's (max 64k according to Wikipedia), Commodore 64's (64k) and so forth, and in an era where even multi-million dollar IBM mainframe systems only had at most 4GiB of memory (https://en.wikipedia.org/wiki/IBM_360#Table_of_System/360_models) one can see someone making just this comment, about a machine that has 10x the memory of most of it's competitors, and about 20% of the memory of the largest memory mainframe system, with a straight face and being actually serious.
At the time (1982) 640k likely seemed like a nearly limitless amount of memory. So BG may in fact have actually said that quote. Or he may not, but circa. 1982 when it would likely have been made, it was not quite as nonsensical a statement as it looks to us now.
(Score: 1) by shrewdsheep on Friday April 07, @09:17AM (1 child)
I believe that would be 4MiB. Still being amazing for the time.
(Score: 2) by owl on Friday April 07, @02:02PM
Indeed, yes, it would be. I fell into the very trap I was discussing, we've grown so accustomed to "gigabytes" (power of 2 variety) as a "unit" of RAM size that I typed GiB without even realizing I'd done so.
(Score: 3, Informative) by RS3 on Friday April 07, @03:10AM (1 child)
I'll add to / augment Owl's great write-up, but big disclaimer: IIRC it's been a long time since I've dug deeply into some of this stuff.
EMS (expanded) memory certainly did exist for the 8088/8086. It was on a hardware adapter card that plugged into a PC slot which provided a sort of a "window" into more RAM pages. It was typically a 64K window size, and the card could have many such pages.
The 86/88 CPU only runs in real mode. In real mode, which all Intel CPUs are in at boot (AFAIK), you can only access 1MB.
The 86/88 CPU had only 20 address lines, so 1MB was the max without doing some external RAM banking, which was/is totally possible, but EMS wasn't that.
IBM decided on a memory map that had RAM in the first 640K, graphics (VGA) display memory at A0000-AFFFF, text mode at B0000-B7FFF, 8-bit hard disk controller ROM at B8000-BFFFF, C0000-CFFFF for VGA ROM (if you had VGA), D0000-EFFFF typically empty / open to other adapter card ROM, EMS window, etc., and system BIOS typically at F0000-FFFFF. Reset, IRQ, and NMI vectors are at FFFF0-FFFFF so some kind of ROM needs to be there.
Adapter cards like hard disk controllers often had their own firmware that would reside somewhere in that B8000-EFFFF space. IIRC some of the early 8-bit disk controllers used B8000-BFFFF. AT disk controllers didn't need upper memory space for a ROM as the system's BIOS handled disk access. That said, I'm pretty sure some advanced AT (16-bit ISA slot) disk controllers (RLL, ESDI, SCSI) did have ROM, again, probably mapped at B8000-BFFFF.
https://en.wikipedia.org/wiki/Conventional_memory [wikipedia.org]
Anyway, hardware EMS boards usually had switches on them so you'd select which memory range to put the window. E0000 - EFFFF was common. The driver software controlled what "bank" of EMS board-mounted memory appeared in that window. Software had to know how to access EMS, otherwise it was useless.
As Owl explained, the 386 (and up) allowed memory mapping, so software like Microsoft's "emm386.exe", Qemm (which I used), and several other great ones did that EMS mapping if you wanted it. Again, EMS was only useful if the application knew how to use it.
"Extended" memory was just that- using the 386+ you could get access to RAM above 1MB, but again, application software had to be aware of it and able to use it. Disk cache software like Microsoft's smartdrv.exe and others of the day could use it, as well as many other applications.
Not sure if it was clear, but in real mode, CS, DS, SS, ES, can all be the same. IIRC, a "*.com" executable (application) could only be up to 64K, and all segment registers were given the same address. Again, IIRC- it's been quite a few years since I've messed with some of this stuff.
Speaking to the mapping Owl was talking about: the concept of "virtual memory", aka "swapfile". The CPU incorporated "exceptions"- for example, you could request a RAM address for which there is no actual RAM. It creates an "exception"- sort of an internal fault, which vectors to a handler, which says "RAM not here, but I can swap something else out to a special area on the hard disk (swapfile) and let you use that RAM." IIRC IBM invented that in the '60s.
(Score: 2) by owl on Friday April 07, @03:53AM
EMS was indeed "that" (external RAM banking). Those EMS cards that were available and plugged into IBM-PC's (and initially were used by Lotus123, which is also why EMS was originally named LIM [Lotus, Intel Microsoft) cards) were hardware bank switching cards that bank-switched their RAM in/out of the 1MB address space of the IBM-PC's memory map.
See Expanded memory [wikipedia.org] where the first paragraph states (emphasis added):
(Score: 4, Insightful) by janrinok on Friday April 07, @04:01PM (7 children)
When the coverage of this topic began several months ago we had no idea if it would create much of a discussion. Initially, there were only a few comments on the first story - quite a few page hits but it didn't seem to capture everybody's imagination. I thought that perhaps our community's interests had changed too much over the last few years. Undeterred, Owl produced the second and subsequent parts of the story and I for one have found it very interesting. I don't know if there is more to follow... By today's standard the 8086 is almost little more than a toy, although at the time it was ground breaking stuff for all its quirky design limitations.
But look at today's discussion here. So many intelligent points being discussed and I for one have learned far more about the 8086 then I ever thought that I would! It was never going to be the top story for comments but I am certainly glad that Owl kept making the submissions and, gradually, a small group of our community have chipped in (pun intended!) with their own contributions and experiences. Thank you to Owl for doing the hard work - and it shows that you really do know your stuff when it comes to this particular piece of hardware. As a way of showing our thanks I am granting 180 days of free subscription to your account which should see you through to the end of this year. Thank you.
(Score: 3, Interesting) by owl on Friday April 07, @05:38PM (6 children)
One clarification, I am not producing the actual blog posts, I'm just posting them here for the community to read. Please don't miss-interpret that I'm "Ken" -- I'm not.
And some got zero or one comment, so some of the early ones fell flat from the comments perspective. But as you say, there's been more 'involvement' as time has gone along.
Nor do I, that depends on Ken S. and whether he continues producing blog posts on 8086 stuff.
You are welcome, and part of what kept me at submitting them was some number of early ones that only got a few comments, but one of the comments was along the line of: "These stories don't seem to generate a lot of comments, but I very much enjoy reading them when they show up".
Owl's been around through this era. First 'PC' of the "IBM compatible" variety was an 8086 clone (the AT&T clone machine to be exact) and I even wrote some 8086 assembly way back in those days to speed up some of my slow Turbo Pascal programs. That and read a lot of assembly in DOS debug while cracking the copy protection on my games so I did not have to find and insert the "original disk" just to play that game right now.
Thanks much, that was unexpected, but appreciated.
(Score: 3, Insightful) by RS3 on Friday April 07, @06:46PM
My take is that your posts are very interesting and informative and there's not much to comment on, just read, learn, enjoy. :)
My first PC was also an AT&T (Olivetti) 6300. I also got into doing assembly on it, and Turbo C. Early-on learned of the NEC V30 chip, which sped it up significantly. Somehow I got a very fast '286- "CompuAdd" maybe? Or Compaq- it was 25MHz, which was quite fast, so the AT&T sat. I got a couple more of the 6300s from a surplus dealer / hamfest, and one had the enhanced color board, but by that point I had stopped using them. Oh yeah, somewhere I got an AT&T '386- I forget the model number. It worked by by then I was running an AMD '386 40MHz (IIRC) and getting into '486 (1994 or so?) and Linux.
Funny that. I've never been too much into games, but have always respected those who do, especially seeing the incredible code trickery people come up with to get PCs to do unimaginably fast screen stuff. Was it "Doom" that was one of the first first-person games? The speed they moved the screen pixels. I learned they didn't do (stupid) bit-blits (as I've seen programmers do) but moved the reference for the screen scan, if that makes any sense.
Anyway, I had bought a very inexpensive diet monitoring program on 5.25" floppy. It had a great database of common foods, including fast-foods, and all the various calories, vitamins, etc. You could copy all of it to your hard drive, but when you wanted to run it, it would search for the original floppy in the "A" drive.
You could not copy the floppy- it had been intentionally buggered, including there were specific sectors marked as bad, and the sector ordering was rearranged on at least one track (IIRC).
Frustrated, I debugged it. One of the many tricks they used- they trapped the single-step interrupt and sent you off into crashland. A lot of very fancy do-nothing loops, lots of fancy math and code processing- just to waste your time. Certainly including the routine that looked for the "bad" floppy sector.
I printed out the assy listing on continuous fanfold paper, traced it out, found the real code beginning, put in a jmp, and it worked. By then I lost interest in it, but I learned a lot.
(Score: 3, Informative) by janrinok on Saturday April 08, @01:32AM (4 children)
I know - you are the person that is preparing the submissions and following Ken's own blog.
There are very few technical blogs of interest nowadays. The bots that we use to collect stories do not work on blogs. Somebody has to check them regularly and bother to make a submission out of them.
It seems that you are not the only grey beard around here - many of us were there during that era. My own first 'computer' was a Nascom 1 [wikipedia.org] - where I had to solder each socket onto the motherboard and fit the various ICs!
(Score: 3, Funny) by owl on Saturday April 08, @02:27AM (3 children)
I hold no belief about being the only greybeard here. Others have posted enough of their history that I know I'm just one of a number who are old enough to have seen a lot of the earlier era's.
You may be somewhat greyer than me there. My first 'computer' was a Sinclair ZX-80 (the white plastic model). Sadly, not the 'kit' version, the pre-assembled variety. But even without that, the Radio Shack carpet burner soldering iron I had back then also saw plenty of usage along the way, so I'm no stranger to that process.
(Score: 2) by turgid on Sunday April 09, @12:51PM (2 children)
Wow, a ZX-80! Did you upgrade it to the "new" 8k ROM? I started out on a ZX-81 with glorious floating-point!
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by owl on Sunday April 09, @02:44PM (1 child)
No, did not upgrade to the new 8k rom. Was that new rom even out circa 1981?
The ZX-80 was relatively soon (read on the order of about 6mo to a year, IIRC) replaced by an Atari 800 Whereupon it (the ZX-80) was relegated to a small box in the attic.
(Score: 2) by turgid on Monday April 10, @09:08PM
The "new ROM" was effectively the ZX-81 ROM. My ZX-81 also has the Skywave FORTH ROM in it. The Atari 800 did indeed have all the graphics and sound.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].