Thus finally the 0F FF believers were rewarded by being give the honor of op code UD0 making it the one and true original invalid opcode permanently disgracing the 0F B9 adherents with the shame of UD1.
We also got UDB (D6), the one-byte variant that arrived with x86-64 for 64-bit mode.
And we have always had UDW (FF FF), aka group #5 (1st FF) with a modrm byte of mod=11b r/m=111b (/7) reg=111b (2nd FF) -- that one matters for memory with all bits set to 1, or for buses terminated to all 1 when no device claims an access.
> It’s called ud2 because the 0F FF variant was retroactively named ud0, and the 0F B9 variant was retroactively named ud1, leaving ud2 as the recommended undefined opcode.
It was a surprise for me as a reader. When I came to this sentence I assumed that 0f ff would become #1 and 0fb9 -- #2. But no, Intel counts from zero, so there is a third ud.
I'm not much of an x86 person but on other architectures you can raise software interrupts/exceptions. Does x86 not have this or did those facilities not cover enough use cases?
Maybe because if the code wants to call the invalid opcode interrupt handler (INT6), it needs extra code to populate the flags and registers expected by that handler, whereas actually triggering an invalid opcode exception will get all those parameters populated automatically.
It's basically a convention. The alternative is to raise interrupts of course, but that might be application specific, or use other invalid instructions than the designated one, but they might work differently on other processor types.
There's a bit of convention and practicality The only thing you really need is that your "fatal error" instruction and "syscall" instruction can be reasonably discriminated without needing to set registers at the call site. Needing to set register to identify a fatal error is not great for code size, especially in languages that generate a lot of them (memory safe languages, mostly).
Though, yes, convention does play a role. On ARMv8 you get both SVC <imm> and BRK <imm>. SVC and BRK raise different exception codes (which satisfies the "easy to distinguish requirement) but in principle you could just use BRK with a well-known immediate and eliminate the need for SVC since BRK's immediate is reported in the exception status register. And, anyways, if you have an SVC instruction and a BRK instruction, you may as well use the SVC instruction for syscalls since it's right there.
A: and B: were not specific to the type of drive. It was common to have two drives before fixed storage became common, often you would have the application disk in one and your data disk in the other though there were other common use patterns for two drives also (with the OS, or at least the core of it, resident in memory you can copy and otherwise manage data over two data disks, and so on).
The first hard-drive in a system was made C: to reserve A: and B: in part because there was software out there that assumed A: and B: were floppy drives and could cause problems if something else was allocated to those signifiers. There are many things that are due to long forgotten compatibility issues like this (try naming file LPT1 under Windows to see another). Another reason is that the BIOS on many PCs was just hard-wired to assume two floppy drives so DOS would see that even if there were no drives really there.
From what I recall from the time I still used MS-DOS, even if you only have one floppy disk drive, it's accessible as both A: and B: and it prompts you to insert the other floppy disk when you change the drive letter. That is, it's "virtualizing" two floppy disk drives using a single physical one. That explains why the first hard disk drive was always C: even when you only had one floppy disk drive (and of course you had at least one floppy disk drive, how could you use a computer without one?)
Which is very convenient (and necessary for backwards compatibility) because programs could be (and were) written to assume they're in B: (and the DOS disk is in A:), or that they're in A: and the user's data is in B:, or a two-disk program is in both. All of that just worked (tm) even with a single drive, as long as the program didn't try to interleave accesses to both drives (I think it would still work because DOS was single-process, single-thread, it would just annoy the user!)
Both of these things are true: commands like diskcopy have special handling to allow the same drive to be used as both source and destination, and the DOS I/O has special handling to request disk changes from A: to B: on single-drive systems for programs that lack specific support.
Even further back into time, before 3.5" disks, both A: and B: were 5.25" disks. And, although my memory is hazy, 3.5's were commonly slotted into B: at first, because no one had 3.5" boot disks until the drives became somewhat common.
You are forgetting 8” floppies. IBM used only the soft sector ones (one hole punched close to the spindle to mark sector 0) but there were also hard sector ones (a ring of 32 holes close to the spindle hole).
There was a lot of experimentation back in those days. The Wikipedia’s page on floppy disks is surprisingly long!
8" floppy drives were not compatible mechanically with IBM PC cases, but there were 8" floppy drives with their own enclosures and power supplies, which could be put on a desktop along the PC case.
IBM PCs have never supported 8" floppy drives, but it was easy to make an adapter between IBM PC floppy cables and 8" floppy drives, so there have existed IBM PC clones from countries where 5¼" floppies were scarce (e.g. Eastern Europe), which supported the attachment of 8" floppy drives.
The original 5¼" floppies had only the size advantage, but they had both a lower capacity and a lower speed than 8" floppies, so attaching 8" floppy drives would have been a higher performance option in the beginning.
Only after the IBM PC/AT introduced the high-density 1.2 Mbyte floppy disks, the 5¼" format matched (actually very slightly exceeded) the performance of the old 8" floppies.
But in the context of drive lettering, although CP/M supported 8" floppies, MS-DOS never did. MS-DOS adopted the naming scheme, but not the boot style.
Floppies, superfloppies, removable hard disks (platter-only, as opposed to modern external hard drives that incorporate the entire drive mechanism), magneto-optical disks, rewritable CD/DVD, even today magnetic tape is still used as removable storage in applications where large capacity is required and shelf life is more important than fast random access.
The floppies got A and B because hard drives were expensive and for a time a lot of people got by without them, though everybody had at least one floppy.
Even if you only had one floppy, it was both A and B, so you could say "copy a:DOC.TXT b:" and it would read the doc and then ask you to insert the floppy you're considering B (and depending on file size and available memory, sometimes switch back and forth a few more times)
What the instruction does is well documented, and the history of other invalid instructions being used for the same purpose in the past I'm guessing there is also well known, though a quick search doesn't turn up any official Intel documentation on the matter.
Given who this is and the overall quality of his output over the years, I'm willing to trust it isn't pure guesswork - and anyway, I'd trust his guesswork over many other people's absolute facts.
We also got UDB (D6), the one-byte variant that arrived with x86-64 for 64-bit mode.
And we have always had UDW (FF FF), aka group #5 (1st FF) with a modrm byte of mod=11b r/m=111b (/7) reg=111b (2nd FF) -- that one matters for memory with all bits set to 1, or for buses terminated to all 1 when no device claims an access.
It was a surprise for me as a reader. When I came to this sentence I assumed that 0f ff would become #1 and 0fb9 -- #2. But no, Intel counts from zero, so there is a third ud.
Though, yes, convention does play a role. On ARMv8 you get both SVC <imm> and BRK <imm>. SVC and BRK raise different exception codes (which satisfies the "easy to distinguish requirement) but in principle you could just use BRK with a well-known immediate and eliminate the need for SVC since BRK's immediate is reported in the exception status register. And, anyways, if you have an SVC instruction and a BRK instruction, you may as well use the SVC instruction for syscalls since it's right there.
INT Ib INT1 INT3 INTO BOUND
The first hard-drive in a system was made C: to reserve A: and B: in part because there was software out there that assumed A: and B: were floppy drives and could cause problems if something else was allocated to those signifiers. There are many things that are due to long forgotten compatibility issues like this (try naming file LPT1 under Windows to see another). Another reason is that the BIOS on many PCs was just hard-wired to assume two floppy drives so DOS would see that even if there were no drives really there.
https://github.com/microsoft/MS-DOS/blob/2d04cacc5322951f187...
There was a lot of experimentation back in those days. The Wikipedia’s page on floppy disks is surprisingly long!
IBM PCs have never supported 8" floppy drives, but it was easy to make an adapter between IBM PC floppy cables and 8" floppy drives, so there have existed IBM PC clones from countries where 5¼" floppies were scarce (e.g. Eastern Europe), which supported the attachment of 8" floppy drives.
The original 5¼" floppies had only the size advantage, but they had both a lower capacity and a lower speed than 8" floppies, so attaching 8" floppy drives would have been a higher performance option in the beginning.
Only after the IBM PC/AT introduced the high-density 1.2 Mbyte floppy disks, the 5¼" format matched (actually very slightly exceeded) the performance of the old 8" floppies.
But in the context of drive lettering, although CP/M supported 8" floppies, MS-DOS never did. MS-DOS adopted the naming scheme, but not the boot style.
Even if you only had one floppy, it was both A and B, so you could say "copy a:DOC.TXT b:" and it would read the doc and then ask you to insert the floppy you're considering B (and depending on file size and available memory, sometimes switch back and forth a few more times)
Given who this is and the overall quality of his output over the years, I'm willing to trust it isn't pure guesswork - and anyway, I'd trust his guesswork over many other people's absolute facts.