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?
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.
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.
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.
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)
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!
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.
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.
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.
If you look at the intel instruction manual, you do see UD0 and UD1. This isn't specific to Microsoft. You would probably have to ask the cpu engineers who made the decision to add those instructions in?
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.
Nowadays UD0 UD1 UD2 are in the SDM and APM.
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.
Username checks out :)
> 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?
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.
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.
x86 has...
INT Ib INT1 INT3 INTO BOUND
It's like why the first (hard) drive letter is C.
A: drive is 3.5; B: drive is 5.25; C: drive is hard disk
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!)
I thought MS-DOS had special handling for A: and B: since it allowed you to copy from A: to B: even with just one floppy drive.
It does.
https://github.com/microsoft/MS-DOS/blob/2d04cacc5322951f187...
Yes, it did, or something did (maybe the individual commands rather than it being through the OS). I'd completely forgotten about that…
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.
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)
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!
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.
Trust me, I will never forget 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.
Yeah it's a relic from when computers booted off floppy and hard disks were rare and expensive
Is this just his speculation? Or is there evidence for it?
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.
If you look at the intel instruction manual, you do see UD0 and UD1. This isn't specific to Microsoft. You would probably have to ask the cpu engineers who made the decision to add those instructions in?
Did you read the friendly article?