Logic families did exist in the late 60's but I don't think the 7400 TTL logic family is that old.
Yeah, it wasn't available in 1964; it came out in 1966.
But, no, the original System/360s didn't use integrated circuits, they used Solid Logic Technology, where a die contained an individual transistor, a few of which were mounted on a wafer.
The 7400 chip family brought medium-scale stuff like the 74181 Arithmetic Logic Unit and 8 bit latches and buffer parts like the 74373 parts
But that was after the first 7400 chips, which were SSI.
Mac OS X does *not* have a walled garden. A user is free to install any app downloaded from the internet. Mac OS X will warn them and ask if they really want to do this and then proceed as the user says.
You say this but I don't think you have actually experienced the "process" that you go through to run a unsigned program that you have downloaded from the net.
I.e., control-click, select Open, and then say "yes, I know it's unsigned, I want to run it anyway" when asked, the first time you launch it?
MSSQL was a rebrand of Sybase -- in the early 90s.
Since then it has been completely rewritten. Here is a timeline
And MSSQL and Sybase SQL split in 1993, at least according to the Wikipedia article on Sybase, so, unless there was a Sybase SQL for Linux 2 years or so after the first version of the Linux kernel was released, Linux didn't have Sybase SQL before "microidiot bought the thing".
There is no way to permanently change this behavior, to the point where the recommended method of using a third party photo suite was to "sudo rm -rf/Applications/Photos.app" - which you can't do any more.
...unless you turn off System Integrity Protection.
They've already started by making it so that even root is blocked from editing files in locations such as/etc,/usr, and/bin, and blocks root from removing "important system apps" like iTunes and Photos (both of which have third party competitors).
Do they also prevent you from installing those competitors and prevent the competitors from registering to handle the file types handled by default by iTunes and Photos?
"A 360" in the sense of "an IBM System/360", or "a 360" in the sense of "a machine compatible - except perhaps at the supervisor-mode level - with an IBM System/360"?
While I may be wrong or simply out of date, my understanding is that CICS is an application running in what is essentially a virtual IBM/360. The virtualisation meant that CICS didn't have to be rewritten for the IBM.370 to take into account newfangled things like memory protection.
That wasn't newfangled; System/360 had protection even though all models other than the model 67 had no memory mapping, just physical memory access. Oh machines with storage protection (optional in the smaller models, and standard in the larger ones), a 2KB block of memory had a 4-bit "protection key" associated with it, and the processor status word had a "protection key" value giving the key of the current task (process). A block of memory could be stored into only if either the PSW protection key was 0 or was the same as the protection key on the block; with store-and-fetch protection (not available in some models), the block's storage key had an additional "fetch protection" bit which, if set, disallowed fetching from the block, as well as storing into the block, if the PSW protection key is non-zero and doesn't match the block's key.
And even on early versions of DOS/VS and OS/VS for System/370 models with "dynamic address translation" (i.e., an MMU), all tasks ran in the a single common virtual address space, so it wasn't that different from an S/360 in that regard.
CICS might have done its own multitasking of requests and responses within a DOS or OS task, and not protected individual "subtasks" from each other, but that wouldn't require virtualization, even on MVS where OS tasks ran in separate address spaces, so if you're referring to "The entire partition, or Multiple Virtual Storage (MVS) region, operated with the same memory protection key including the CICS kernel code." from the Wikipedia article, that doesn't require virtualization to run on later systems.
What I'm describing is just that the problem-state instruction set of an IBM z13 is, except for anything removed in the original S/360 to S/370 transition (such as ASCII mode), a superset of the original S/360 instruction set.
Back in the 1980s my then-employer shared the cost with the FAA of updating IBM's 1401 emulator to the latest architecture (IIRC whatever was the half generation between 370 and 390), so I wouldn't count on that 360 being the oldest!
Where were 1401's involved? The 9020s were based on 360/50 and 360/65 models, not on 1401s; unless 1401s were used prior to the 9020s (was air traffic control computerized at all before the 9020s), and the 1401 software run in emulator mode or under a simulator (I'm not sure the models 50 and 65 had 1401 emulator microcode - 709x, yes, but not 1401, which may have been used in the smaller models 30 and 40), I don't see how 1401s would have been involved. (As I remember reading, at least some of the 360s had microcode changes to add instructions to the S/360 instruction set to process radar scan lines, suggesting that the code was written in 360 assembler or compiled into 360 machine code, rather than 1401 code.)
"A 360" in the sense of "an IBM System/360", or "a 360" in the sense of "a machine compatible - except perhaps at the supervisor-mode level - with an IBM System/360"? If the latter, then that's not interesting; my laptop was purchased in 2015, but, as far as I know, its CPU is compatible, even at the ring 0 level, with the CPU from the original IBM Personal Computer (whether I could boot the original version of MS-DOS on it is another matter), and the most recent CPU design capable of running System/360 problem-state code was also announced in 2015.
Despite the FAA claiming security concerns,, it took me 10 minutes to find Lora
Presumably you meant "Loral".
was once bidding on a contract to replace IBM 9020Es,
They have Linux partitions on their OS/390 mainframes. It's been a while since I last touched it (must have been 12 years ago or so?), and it was behaving quite odd at the time (not many utilities, strange idea of what root constituted, and that horrible, horrible shell),
Are you thinking of Linux partitions or of UNIX System Services for OS/390 (and z/OS)? The former is Real Live Linux running as an OS; the latter is an add-on environment for MVS and its successors, providing some level of POSIX/Single UNIX Specification compatibility, but with, for example, EBCDIC rather than ASCII as its character set.
translate programs compiled to the various S-languages directly into microcode and execute the microcode.
What could possibly go wrong, in today's connected era. LOL.
That's pretty much what these guys do, although they've stopped calling what it gets translated to is "microcode" (in the current machines, it's Power Architecture code, possibly with a few extensions such as tag bits).
(They used to call the low-level OS and binary-to-binary translator code "vertical microcode", in the days before it was PowerPC/Power Architecture code, but that was for legal reasons; they didn't want to be forced to make the code available to clone makers. "Vertical microcode" ran out of main memory, and the binary-to-binary translator translated compiler output to the "vertical microcode" instruction set and ran it from main memory as well. The original "vertical microcode" instruction set was somewhat S/360-ish.)
Went RISC uOps to Get Perf. Anyone who thinks a PENTIUM was looking for Low Power Is AN IGNORANT SLUT!
(Pentium Pro, but whatever.)
No, but Transmeta did something similar to what it appears Soft Machine are doing, and did so to reduce power consumption; I think that's what "The basic concept of translating established instructions to something more efficient for the specific architecture isn't new; this is what yielded the first low-power x86 processors at the beginning of the century." was referring to.
Maybe, maybe not. An article about them on SemiAccurate says "SM can run what it calls personalities in software but they are not implemented in the expected way. Personalities are software and are loaded at boot time, but they are both light and low-level. They don’t emulate code, they just translate it to the native ISA, a 32-bit add is a 32-bit add on both native and emulated hardware, but probably have differing opcodes." and "Personalities are not purely software though, there are hardware hooks to assist in with the job, unfortunately SM did not go into more detail here."
Perhaps there's more hardware assistance than in Transmeta's chips, where I think the instruction set was somewhat oriented towards emulating an x86 and some hardware features helped, but the translation itself was done in software - maybe there's some hardware assistance in the translation process, although that might bias it towards particular instruction sets if done naively.
Yep - the B1700 did this in the 1970s. Been there, done that... (I was a CPU engineer on one of them.)
But they didn't translate programs compiled to the various S-languages directly into microcode and execute the microcode. From this article about them, it sounds as if that's what they're doing:
The next issue on the list was the ISA which moves from a 32-bit one on the prototype to a full 64-bit version in the Shasta/Mojave pair. SM can run what it calls personalities in software but they are not implemented in the expected way. Personalities are software and are loaded at boot time, but they are both light and low-level. They don’t emulate code, they just translate it to the native ISA, a 32-bit add is a 32-bit add on both native and emulated hardware, but probably have differing opcodes. Occasionally this software will need to do something more complex but the bulk of the work is basically a big lookup table.
Personalities are not purely software though, there are hardware hooks to assist in with the job, unfortunately SM did not go into more detail here. One thing they did say is that the code is not user accessible and runs underneath everything including a hypervisor where applicable. In x86 terms, think of this as ring -2 or something similar. To running code and users, everything should appear to be native hardware, assuming it all works as promised.
I remember studying about variable length instruction sets when I was studying CS back in the '70s. Scared the hell out of me.
"Variable" or "variable length"? There's nothing particularly exotic about instruction sets where not all instructions are the same length, so presumably you meant the former.
the Motorola 68000 series (the 68000 and 68010 had a 24-bit address bus and a 16-bit data bus, and a 16-bit ALU for data operations; the instruction set had 32-bit registers and arithmetic instructions and 24-bit physical addresses, extended to 31-bit physical addresses with the 68012 and 32-bit physical addresses with the 68020 and subsequent processors, which had 32-bit internal data paths),
And the 68008 had an 8-bit data bus, but was internally like a 68010, with 32-bit registers and arithmetic instructions and a 16-bit ALU for data operations.
On the other side, the 32-bit original Pentium had a 64-bit external data bus.
So you have the external bus width, the internal data path width, and the instruction set width(s) (registers, arithmetic instructions, addresses, etc.), which can vary somewhat independently; it might be appropriate use the external bus width as an indicator of the bit width of the processor when designing designing support chips and attaching peripherals, but it's a lot less relevant when discussing programming the processor (especially if you're not writing software for that particular processor but are writing software for processors with that version of the instruction set).
What defines the bit width of an instruction set isn't connected to data bus width, as different implementations of the same instruction can have different data bus widths.
That's news to me. When I doing electronics as a teenager in the 1980's, an 8-bit processor had eight data lines, a 16-bit processor had 16 data lines, and a 32-bit processor had 32 data lines. I recently saw a 64-bit microcontroller that implemented one-half of the data bus (32 bits) as four 8-bit serial ports (four pins). I'm not sure if that's a four-bit or two-bit design.
Again, there's the width of the processor's external bus, the width of the processor's internal signal paths, and the width of the registers and instructions of the instruction set the processor implements. Nothing ties the first two of those to the third of those, as evidenced by various models of the System/360 series (the I/O interface had 8 "bus in" lines, 8 "bus out" lines, and various control lines; the processors had internal signal paths ranging from 8 to 32 bits for integer and address operations; the instruction set had 32-bit general-purpose registers and arithmetic instructions and 24-bit physical addresses), the Motorola 68000 series (the 68000 and 68010 had a 24-bit address bus and a 16-bit data bus, and a 16-bit ALU for data operations; the instruction set had 32-bit registers and arithmetic instructions and 24-bit physical addresses, extended to 31-bit physical addresses with the 68012 and 32-bit physical addresses with the 68020 and subsequent processors, which had 32-bit internal data paths), and the 8086/8088 and 80186/80188 (same processor core in the 86 and 88 variants, just a different external bus; the instruction set had 16-bit registers and arithmetic instructions).
It's about more than just the electronics; it's about the software, and that mainly involves the instruction set, with the external and internal data widths being a performance issue rather than a pure functionality issue.
So, from the 1960's (and maybe earlier) to the present day, you could, for example, have a processor with an 8-bit data bus and 16-bit, 32-bit, or 64-bit registers and arithmetic instructions and 16-bit, 24-bit, 32-bit, and 64-bit physical/virtual addresses.
The 8088 was a processor with an 8-bit data bus and everything else 16-bit; as Intel's manual says, "The 8086 and 8088 are closely related third- generation microprocessors. The 8088 is designed with an 8-bit external data path to memory and I/O, while the 8086 can transfer 16 bits at a time. In almost every other respect the processors are identical; software written for one CPU will execute on the other without alteration." They also note that "The high performance of the 8086 and 8088 is realized by combining a 16-bit internal data path with a pipelined architecture that allows instructions to be prefetched during spare bus cycles.", so both are internally 16-bit implementations of the 16-bit instruction set.
That depends on what you consider to be an 8-bit processor. Based on other comments, the devil is in the details regarding the 8086/8088 processors. I pointed out to another poster that the 80186 had an internal multiplexed 20-bit bus and available with an 8-bit or 16-bit external data bus. Unless someone changed the definition for a processor in the last 40 years, the data bus determines bit-width of a processor.
If so, then it's an 8-bit processor that implemented a 16-bit instruction set, then, just as the IBM System/360 Model 30 was an 8-bit processor that implemented a 32-bit instruction set and the Motorola 68000 was a 16/32-bit processor that implemented a 32-bit instruction set. From the programmer's point of view, the 8088 had 16-bit registers, 16-bit arithmetic instructions, and 16-bit "flat" addresses, just as the 8086 did.
What defines the bit width of an instruction set isn't connected to data bus width, as different implementations of the same instruction can have different data bus widths. "x86" isn't a processor, it's a family of instruction sets, including the original 16-bit 8086/8088 instruction set (with updates in the 80186/80188), the protected-mode 16-bit 80286 instruction set, the 32-bit IA-32 instruction set, and the 64-bit x86-64 instruction set. There was no 8-bit x86 instruction set.
Slashdot Mirror
The DR11-W was not a printer interface, but a computer-to-computer interface for the PDP-11.
And a company that made DR11-W compatible devices didn't shut down until 2016.
Logic families did exist in the late 60's but I don't think the 7400 TTL logic family is that old.
Yeah, it wasn't available in 1964; it came out in 1966.
But, no, the original System/360s didn't use integrated circuits, they used Solid Logic Technology, where a die contained an individual transistor, a few of which were mounted on a wafer.
The 7400 chip family brought medium-scale stuff like the 74181 Arithmetic Logic Unit and 8 bit latches and buffer parts like the 74373 parts
But that was after the first 7400 chips, which were SSI.
Mac OS X does *not* have a walled garden. A user is free to install any app downloaded from the internet. Mac OS X will warn them and ask if they really want to do this and then proceed as the user says.
You say this but I don't think you have actually experienced the "process" that you go through to run a unsigned program that you have downloaded from the net.
I.e., control-click, select Open, and then say "yes, I know it's unsigned, I want to run it anyway" when asked, the first time you launch it?
MSSQL is a rebrand of Sybase.
MSSQL was a rebrand of Sybase -- in the early 90s.
Since then it has been completely rewritten. Here is a timeline
And MSSQL and Sybase SQL split in 1993, at least according to the Wikipedia article on Sybase, so, unless there was a Sybase SQL for Linux 2 years or so after the first version of the Linux kernel was released, Linux didn't have Sybase SQL before "microidiot bought the thing".
they are not bringing sql to linux
No, they're bringing their SQL Server to Linux.
There is no way to permanently change this behavior, to the point where the recommended method of using a third party photo suite was to "sudo rm -rf /Applications/Photos.app" - which you can't do any more.
...unless you turn off System Integrity Protection.
They've already started by making it so that even root is blocked from editing files in locations such as /etc, /usr, and /bin, and blocks root from removing "important system apps" like iTunes and Photos (both of which have third party competitors).
Do they also prevent you from installing those competitors and prevent the competitors from registering to handle the file types handled by default by iTunes and Photos?
They must have a 360 running.
"A 360" in the sense of "an IBM System/360", or "a 360" in the sense of "a machine compatible - except perhaps at the supervisor-mode level - with an IBM System/360"?
Basically, you just described CICS
While I may be wrong or simply out of date, my understanding is that CICS is an application running in what is essentially a virtual IBM/360. The virtualisation meant that CICS didn't have to be rewritten for the IBM.370 to take into account newfangled things like memory protection.
That wasn't newfangled; System/360 had protection even though all models other than the model 67 had no memory mapping, just physical memory access. Oh machines with storage protection (optional in the smaller models, and standard in the larger ones), a 2KB block of memory had a 4-bit "protection key" associated with it, and the processor status word had a "protection key" value giving the key of the current task (process). A block of memory could be stored into only if either the PSW protection key was 0 or was the same as the protection key on the block; with store-and-fetch protection (not available in some models), the block's storage key had an additional "fetch protection" bit which, if set, disallowed fetching from the block, as well as storing into the block, if the PSW protection key is non-zero and doesn't match the block's key.
And even on early versions of DOS/VS and OS/VS for System/370 models with "dynamic address translation" (i.e., an MMU), all tasks ran in the a single common virtual address space, so it wasn't that different from an S/360 in that regard.
CICS might have done its own multitasking of requests and responses within a DOS or OS task, and not protected individual "subtasks" from each other, but that wouldn't require virtualization, even on MVS where OS tasks ran in separate address spaces, so if you're referring to "The entire partition, or Multiple Virtual Storage (MVS) region, operated with the same memory protection key including the CICS kernel code." from the Wikipedia article, that doesn't require virtualization to run on later systems.
What I'm describing is just that the problem-state instruction set of an IBM z13 is, except for anything removed in the original S/360 to S/370 transition (such as ASCII mode), a superset of the original S/360 instruction set.
Back in the 1980s my then-employer shared the cost with the FAA of updating IBM's 1401 emulator to the latest architecture (IIRC whatever was the half generation between 370 and 390), so I wouldn't count on that 360 being the oldest!
Where were 1401's involved? The 9020s were based on 360/50 and 360/65 models, not on 1401s; unless 1401s were used prior to the 9020s (was air traffic control computerized at all before the 9020s), and the 1401 software run in emulator mode or under a simulator (I'm not sure the models 50 and 65 had 1401 emulator microcode - 709x, yes, but not 1401, which may have been used in the smaller models 30 and 40), I don't see how 1401s would have been involved. (As I remember reading, at least some of the 360s had microcode changes to add instructions to the S/360 instruction set to process radar scan lines, suggesting that the code was written in 360 assembler or compiled into 360 machine code, rather than 1401 code.)
They must have a 360 running.
"A 360" in the sense of "an IBM System/360", or "a 360" in the sense of "a machine compatible - except perhaps at the supervisor-mode level - with an IBM System/360"? If the latter, then that's not interesting; my laptop was purchased in 2015, but, as far as I know, its CPU is compatible, even at the ring 0 level, with the CPU from the original IBM Personal Computer (whether I could boot the original version of MS-DOS on it is another matter), and the most recent CPU design capable of running System/360 problem-state code was also announced in 2015.
Despite the FAA claiming security concerns,, it took me 10 minutes to find Lora
Presumably you meant "Loral".
was once bidding on a contract to replace IBM 9020Es,
Yes, in 1995. IBM replaced the 9020A and 9020D machines in the late 1980s, and then replaced the 9020E's in the 1990s.
so they are probably running 360-compatible gear.
What they're running now might well be "360-compatible", but that might be in the same way that the Haswell Core i7 in my laptop is "8088-compatible".
They have Linux partitions on their OS/390 mainframes. It's been a while since I last touched it (must have been 12 years ago or so?), and it was behaving quite odd at the time (not many utilities, strange idea of what root constituted, and that horrible, horrible shell),
Are you thinking of Linux partitions or of UNIX System Services for OS/390 (and z/OS)? The former is Real Live Linux running as an OS; the latter is an add-on environment for MVS and its successors, providing some level of POSIX/Single UNIX Specification compatibility, but with, for example, EBCDIC rather than ASCII as its character set.
translate programs compiled to the various S-languages directly into microcode and execute the microcode.
What could possibly go wrong, in today's connected era. LOL.
That's pretty much what these guys do, although they've stopped calling what it gets translated to is "microcode" (in the current machines, it's Power Architecture code, possibly with a few extensions such as tag bits).
(They used to call the low-level OS and binary-to-binary translator code "vertical microcode", in the days before it was PowerPC/Power Architecture code, but that was for legal reasons; they didn't want to be forced to make the code available to clone makers. "Vertical microcode" ran out of main memory, and the binary-to-binary translator translated compiler output to the "vertical microcode" instruction set and ran it from main memory as well. The original "vertical microcode" instruction set was somewhat S/360-ish.)
Went RISC uOps to Get Perf. Anyone who thinks a PENTIUM was looking for Low Power Is AN IGNORANT SLUT!
(Pentium Pro, but whatever.)
No, but Transmeta did something similar to what it appears Soft Machine are doing, and did so to reduce power consumption; I think that's what "The basic concept of translating established instructions to something more efficient for the specific architecture isn't new; this is what yielded the first low-power x86 processors at the beginning of the century." was referring to.
Transmeta with a hardware morphing layer?
Maybe, maybe not. An article about them on SemiAccurate says "SM can run what it calls personalities in software but they are not implemented in the expected way. Personalities are software and are loaded at boot time, but they are both light and low-level. They don’t emulate code, they just translate it to the native ISA, a 32-bit add is a 32-bit add on both native and emulated hardware, but probably have differing opcodes." and "Personalities are not purely software though, there are hardware hooks to assist in with the job, unfortunately SM did not go into more detail here."
Perhaps there's more hardware assistance than in Transmeta's chips, where I think the instruction set was somewhat oriented towards emulating an x86 and some hardware features helped, but the translation itself was done in software - maybe there's some hardware assistance in the translation process, although that might bias it towards particular instruction sets if done naively.
nikto is the last word. as written, it's a jelly doughnut.
"Gort, I am a jelly doughnut"?
Translating instruction to micro-ops to run on a VLIW-ish backend? I think every high performance architecture does that now (arm and x86)
x86 - and z/Architecture, with the z13 chip - but do any ARM processors (or other RISC processors) do that?
http://www.amazon.com/The-Soft-Machine-William-Burroughs/dp/0802133290
Or Soft Machine, the band.
Yep - the B1700 did this in the 1970s. Been there, done that... (I was a CPU engineer on one of them.)
But they didn't translate programs compiled to the various S-languages directly into microcode and execute the microcode. From this article about them, it sounds as if that's what they're doing:
so this looks more like Transmeta.
I remember studying about variable length instruction sets when I was studying CS back in the '70s. Scared the hell out of me.
"Variable" or "variable length"? There's nothing particularly exotic about instruction sets where not all instructions are the same length, so presumably you meant the former.
Well, 2% of nothing is still not much. I probably spent 2% of Greece's GDP on toast last year...
About 5.7 billion dollars buys a lot of toast.
Or did you mean "2% of Greece's per capita GDP"? That would be about USD 430 or so spent on toast.
Character set looks like this: degrees
Hope that helps...
Unicode is a virus
Language is a virus.
the Motorola 68000 series (the 68000 and 68010 had a 24-bit address bus and a 16-bit data bus, and a 16-bit ALU for data operations; the instruction set had 32-bit registers and arithmetic instructions and 24-bit physical addresses, extended to 31-bit physical addresses with the 68012 and 32-bit physical addresses with the 68020 and subsequent processors, which had 32-bit internal data paths),
And the 68008 had an 8-bit data bus, but was internally like a 68010, with 32-bit registers and arithmetic instructions and a 16-bit ALU for data operations.
On the other side, the 32-bit original Pentium had a 64-bit external data bus.
So you have the external bus width, the internal data path width, and the instruction set width(s) (registers, arithmetic instructions, addresses, etc.), which can vary somewhat independently; it might be appropriate use the external bus width as an indicator of the bit width of the processor when designing designing support chips and attaching peripherals, but it's a lot less relevant when discussing programming the processor (especially if you're not writing software for that particular processor but are writing software for processors with that version of the instruction set).
What defines the bit width of an instruction set isn't connected to data bus width, as different implementations of the same instruction can have different data bus widths.
That's news to me. When I doing electronics as a teenager in the 1980's, an 8-bit processor had eight data lines, a 16-bit processor had 16 data lines, and a 32-bit processor had 32 data lines. I recently saw a 64-bit microcontroller that implemented one-half of the data bus (32 bits) as four 8-bit serial ports (four pins). I'm not sure if that's a four-bit or two-bit design.
Again, there's the width of the processor's external bus, the width of the processor's internal signal paths, and the width of the registers and instructions of the instruction set the processor implements. Nothing ties the first two of those to the third of those, as evidenced by various models of the System/360 series (the I/O interface had 8 "bus in" lines, 8 "bus out" lines, and various control lines; the processors had internal signal paths ranging from 8 to 32 bits for integer and address operations; the instruction set had 32-bit general-purpose registers and arithmetic instructions and 24-bit physical addresses), the Motorola 68000 series (the 68000 and 68010 had a 24-bit address bus and a 16-bit data bus, and a 16-bit ALU for data operations; the instruction set had 32-bit registers and arithmetic instructions and 24-bit physical addresses, extended to 31-bit physical addresses with the 68012 and 32-bit physical addresses with the 68020 and subsequent processors, which had 32-bit internal data paths), and the 8086/8088 and 80186/80188 (same processor core in the 86 and 88 variants, just a different external bus; the instruction set had 16-bit registers and arithmetic instructions).
It's about more than just the electronics; it's about the software, and that mainly involves the instruction set, with the external and internal data widths being a performance issue rather than a pure functionality issue.
So, from the 1960's (and maybe earlier) to the present day, you could, for example, have a processor with an 8-bit data bus and 16-bit, 32-bit, or 64-bit registers and arithmetic instructions and 16-bit, 24-bit, 32-bit, and 64-bit physical/virtual addresses.
The 8088 was a processor with an 8-bit data bus and everything else 16-bit; as Intel's manual says, "The 8086 and 8088 are closely related third- generation microprocessors. The 8088 is designed with an 8-bit external data path to memory and I/O, while the 8086 can transfer 16 bits at a time. In almost every other respect the processors are identical; software written for one CPU will execute on the other without alteration." They also note that "The high performance of the 8086 and 8088 is realized by combining a 16-bit internal data path with a pipelined architecture that allows instructions to be prefetched during spare bus cycles.", so both are internally 16-bit implementations of the 16-bit instruction set.
Which weren't x86 processors.
That depends on what you consider to be an 8-bit processor. Based on other comments, the devil is in the details regarding the 8086/8088 processors. I pointed out to another poster that the 80186 had an internal multiplexed 20-bit bus and available with an 8-bit or 16-bit external data bus. Unless someone changed the definition for a processor in the last 40 years, the data bus determines bit-width of a processor.
If so, then it's an 8-bit processor that implemented a 16-bit instruction set, then, just as the IBM System/360 Model 30 was an 8-bit processor that implemented a 32-bit instruction set and the Motorola 68000 was a 16/32-bit processor that implemented a 32-bit instruction set. From the programmer's point of view, the 8088 had 16-bit registers, 16-bit arithmetic instructions, and 16-bit "flat" addresses, just as the 8086 did.
What defines the bit width of an instruction set isn't connected to data bus width, as different implementations of the same instruction can have different data bus widths. "x86" isn't a processor, it's a family of instruction sets, including the original 16-bit 8086/8088 instruction set (with updates in the 80186/80188), the protected-mode 16-bit 80286 instruction set, the 32-bit IA-32 instruction set, and the 64-bit x86-64 instruction set. There was no 8-bit x86 instruction set.
8088 was 8 bits. 8086 was 16 bits so I assume x86 should mean at least 16 bits.
8088 was 16 bits with an 8-bit external bus, but otherwise code compatible.