The best guess is to look at the available RAM (for loadable programs) or the amount of RAM and ROM. If you have less than 64 KiB total or less than 64 KiB+64 KiB, the answer would be pretty obvious :-)
One of the (pre-release) selling point was that the 8086 was 8080 compatible. When 8086 details finally released, this appeared to be some degree of assembler mnemonics similarity.
The 80286 was some kind of stop gap between the 8080 and the iAPX432, which proved to be disastrous.
A world full of Sinclair QL clones :-)
No - it was intentionally made similar to the boot-up mode of a 80286. There would not be any segment registers in any sensible 16+ bit processor. A bank switcher would have been much simpler.
A segmented processor architecture was well known decades before the 80(2)86, so the registers were originally intended to point to segment descriptors a la -286+.
I was at an invitational Intel meeting in 1980 (PC is from -81) and had some interesting discussions with the designers. They already had some of -386 planned, so that -286 would not become incompatible with it.
-- -TV
This was (and is) an architectural limitation of the segment descriptor system: there are 13 bits for local descriptor table indices.
The 32 bit system can have larger segments, but not more of them.
-- -TV
Only if you used DRAMs.
Apart from some early (1702) EPROMs, most EPROMs were single supply as well as small SRAMs.
The first 6800 demo system was single supply.
You seem to think that the "computer" was invented by the semiconductor industry, in fact there was a quarter of a century computers before that.
With higher levels of integration possible, more and more functionality could be integrated into a "single" chip. First you might have needed a few hundred TTL chips, then the key functionality could be put into a few LSI chips and finally you could announce the world first 4/8/16/32 bit chip, but still needing a large amount of auxiliary chips.
There had been various minicomputer busses before the first microcomputers, so it should have been possible to pick the best features.
There are some flaws with the _32_ bit _signed_ representation. If you intend to interpret it as a signed value, the problem is that it only extends back to year 1902, so you could not the register the birth date of a lot people living in the 1970's.
At least for real time control system, interpreting the 32 bit second counter would allow the use to year 2106.
Some other problems with Unix time is the handling of leap seconds.
What is the problem with 64 KiB program address space with much larger total system memory ?
In a previous company, my department used machines with 64 KiB or 128 KiB (I+D) and we never had problems with the program address space limits. Just split the functionality into a sufficient number of tasks.
Of course if you need to access a huge data base, this was problematic.
Some of the 8080 support chip had some exotic outputs that you could determine what type of access was intended, but did also include data/stack access and not just instruction/RWdata access ?
(snip, I wrote)
Most 8080 instructions translate to a single 8086 instruction, but some need two or three. The number of bytes might be a little more, so it won't fit into 64K anymore.
Someone might still have the program that Intel sent out to do the conversion.
The four protection levels, as I understand, are from Multics and its host. But yes, the 432 was way too complicated for what was needed at the time.
-- glen
(snip, I wrote)
When debugging with OS/2 1.x, I would allocate each array to its own segment, calling the OS/2 allocate routine.
Calling malloc() allocates 64K segments, and then parcels them out.
The limit of 8K segments (minus the code segments) could have been a problem, but usually wasn't. Allocating one segment per array allows for a hardware trap going outside the array, fetch or store.
Compilers at the time didn't do array bounds checking, and it is still not so common for C.
-- glen
It was usually pretty easy to also convert the program to small model, allowing 64KB of both code and data. Also, on a system like MS-DOS, the OS no longer took any of your 64KB address space for a tiny/com format program (well, except for the 256 byte PSP).
As to the conversion program, I haven't seen a copy in decades, but I do have a hardcopy of the instruction equivalences, that I've been meaning to put online for years...
Most of the 8080 instruction that needed two 8086 instructions were the conditional branches (if the range didn't fit in the 8086s 8 bit relative offset), and the (rarely used) conditional calls and returns (which 8086, of course, doesn't have, needing to be turned into a reversed sense conditional branch around the actual call or return). In addition LDAX/STAX and PUSH/POP PSW needed two instruction sequences.
There were four* 8080 instructions that needed more than two 8086 instructions to emulate (DAD, INX, DCX and XTHL), none more than five instructions, although the first three** could be replaced with a single 8086 instruction if you didn't care about exact flag behavior, leaving a three instruction replacement for XTHL.
*In the past I've posted that it was five instructions, but now that I'm actually looking at the doc, it appears to be only four... **Which are the three instructions that operate on 16 bit registers, and on 8080 don't set the flags the same way as the 8-bit instructions.Am Sat, 18 Oct 2014 09:06:45 +0000 (UTC) schrieb glen herrmannsfeldt:
CONV86. I used it to port a 8080 program to the then new PC. It really worked but the generated code sometimes was ugly in order to prevent compatibility issues. Don't thave CONV86 anymore, though...
-gerd
cf. 1702, 2708, TI's 2716 (I've been designing embedded systems for a LONG time -- long before they were called such! Starting at i4004)
SRAM's were *really* small. E.g. 2114's.
Where do I make that claim? I cut my teeth on a small IBM mainframe, a Nova 1 and a PDP 8e (or i... can't recall, now). Then, 10's, 11's/VAXen, Eclipse, etc.
But, putting something that existed "in a large box with a large power supply" onto a single, commercially viable DIP doesn't mean you can just pick whatever architecture you want, turn the crank and start spitting out chips!
E.g., the i4004 was a DOG in comparison to the 8080 (or even 8008). Instruction execution times were ~10-20us -- almost "audio frequency". And, you're just dealing with nybbles! Despite the fact that "big iron" coexisted (gee, why couldn't they pick some of those features???)
Before the i4004, most bigger machines were massive amounts of MSI. In the late 70's, we were shipping Reading Machines (an "embedded system" the CPU the size of a washing machine) with *core*. A 4KW "semiconductor" memory was a 16"x16" (?) PCB.
(This is contemporary with i4004 "embedded systems")
The Market OFTEN doesn't pick the "best qualified" solution.
Given a CLEAN SLATE, there's no problem with *anything*! :> The "problem" lies in living within existing constraints AND writing portable code. E.g., no "near"/"far" nonsense. Take the machine the way it existed when your code was invoked, "do your thing" -- and leave the machine in the state that you found it (or, explore ALL of the consequences of ANY changes you may have introduced to its state)
Sure, and I've written UNIX-like OS's to run on Z80's (bankswitching instead of swapping). No reason the terminal handler needs to co-reside in the same address space as the OS; no reason for the OS to share an address space with the application, either!
But, that sort of code is anything BUT "portable". The next host architecture may have an entirely different set of constraints imposed by its hardware.
That is a big one with 1024x4 bits :-)
The original 6800 sample system was 6830 ROM with 1024 bytes ROM and
6810 with 128 bytes of RAM.
The i4004 was just a repurposed handhold calculator chip, A handhold four banger calculator doesn't need high speed due to the slow human entry speed.
It was the real 68000 that the engineers wanted - one of the main reasons for the PHB's moving to the 8088 was to get an 8-bit bus and therefore "half" the cost of the memory and bus. And as the PHB's viewed the machine as merely a marketing exercise to see what people wanted, and it was thus a throw-away design, the technical deficiencies of the Intel chip didn't matter.
Everything is relative. At the time, we were shipping product with
8155's (?) (not sure I remember the P/N correctly... 256x8 RAM, counter and PIO's in a DIP40? Maybe DIP28??I.e., 512 total bytes of RAM in a (commercial product) system (8085-based successor to the i4004 product described below). When you think how "big" lat-lons are and the math required to convert hyperbolic coordinates on an oblate sphere to a cartesian projection, you can see how quickly you start counting *bits*!
We used it in the "first" commercial LORAN-C position plotter (take hyperbolic LORAN-C coordinates and convert them to a cartesian map projection in real time to drive a pen plotter).
(snip, I wrote)
I believe all three. You can have separate address spaces for code, stack, and data.
Among others, Intel claimed a 64K entry call stack, though as it is two bytes each it should only be 32K. Maybe with extra logic you can make it 64K. But only if it is a separate address space from code and data.
-- glen
Buttlicks actually *intended* 64 rings, IIRC. 0-31 for "system" use and 32-63 for "user". But, actually, only
*8* rings were implemented (not 4!).Effectively, a "program" only executes in two rings -- a "user" ring ("4") and the "system" ring ("0").
As with many technical issues, coming up with the "right number" is hard. Too few and you lose the value they present. Too many and a "program" spends too much time crossing protection domains ("for little value")
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.