Timeline for What prevents faster versions of old architectures from being created?
Current License: CC BY-SA 3.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 26, 2020 at 11:39 | comment | added | Patrick Schlüter | @davidbak no, only visible in priviledged mode. | |
| Aug 14, 2020 at 17:02 | comment | added | supercat |
@PatrickSchlüter: For example, it would be helpful if chip vendors would distinguish between register bits which at present will read zero, and in future will always be safely writable as zero, and those which in future might read non-zero and for safety need to be written with the value read. If all unused bits are of the former type, reg = 23; may be safer and more efficient than reg = (reg & ~0x3FFF) | 23;, but if some might be of the latter type, the former construct or an atomically-interlocked variant thereof may be needed.
|
|
| Aug 14, 2020 at 16:58 | comment | added | supercat | @PatrickSchlüter: One aspect of design which is often given way too little attention is striking a documented balance between aspects of behavior that the chip vendor will attempt to retain through future chips, those that are stable for the present design but may be different in successors to the current chip, and those which may change arbitrarily with different die revs. Putting things are in the first category will increase the usefulness of the present chips, but may degrade the usefulness of future ones. | |
| Aug 14, 2020 at 16:02 | comment | added | davidbak | @PatrickSchlüter - that business about spilling the whole state to the stack: is that something a userland program would be involved with (and thus require exact compatibility if it were to run) or was knowledge of that sort of thing limited to operating system code? | |
| Jul 23, 2020 at 12:01 | comment | added | Patrick Schlüter | One other technical aspect of m68k that made further development extremely difficult was that it exposed the whole internal instruction format to the user/programmer. When a exception occurred, the whole state machine was spilled to the stack allowing for restart of the instruction. This scheme became more and more a liability, the complexer the execution units became. | |
| Jul 23, 2020 at 12:01 | comment | added | Patrick Schlüter | What killed the m68k was not the instruction set itself, but its overcomplicated addressing modes, especially the ones introduced with 68020. These were really difficult to implement fast with a mmu. Theoretically a 68020 instruction could trigger up to 16 page faults. The addressing modes of 386 are in that regard much saner (max 2 page faults). | |
| Jul 21, 2020 at 13:09 | comment | added | user1937198 | One thing about modern CPUs is the cache would contain more storage space than main memory on most retro pcs. | |
| Jul 5, 2016 at 21:39 | comment | added | Rico Pajarola | Once you got a mul instruction in the pictures, all these calculations don't matter anymore, it takes 70+ cycles to execute. But it's still missing the point, what I'm saying is that the memory subsystem in the PC was quite adequate for that CPU... it was neither too fast nor too slow in the general case. | |
| Jul 4, 2016 at 18:20 | comment | added | supercat |
The prefetch and execute can happen simultaneously, so the execution time for a sequence of add reg,reg instructions would be eight cycles each. If one were to use an alternating sequence of mul bx and add cx,ax instructions, then the prefetch queue would get filled during each mul bx instruction, so the add cx,ax would delay the next multiply by three cycles rather than eight, but in most programs the CPU will spend most of its time waiting on prefetch queue.
|
|
| Jul 3, 2016 at 11:10 | comment | added | Rico Pajarola | True, but we're not discussing whether the 8088 was a good CPU. What you're describing is a limitation of the CPUs interface, not the system that was built around it. With a perfect memory subsystem, an 8088 can execute an "add reg, reg" in 11 cycles (8 to fetch the instruction, 3 to execute it). With the actual memory subsystem it had, it could execute it in maybe 13. I would argue that this is quite balanced. A 486 with a perfect memory subsystem can execute that instruction in 1 cycle, but with the 8088's memory interface, it would take hundreds of cycles, making it extremely unbalanced. | |
| Jul 1, 2016 at 22:52 | comment | added | supercat | ...and IIRC the CPU never gets access on the first such clock but must await the second. | |
| Jul 1, 2016 at 22:51 | comment | added | supercat | The 8086 is much better balanced than the 8088 since the latter ends up spending most of its time awaiting code fetches (a typical two-byte instruction will take 2-3 cycles to execute if the prefetch buffer is full, but the CPU can only fetch one byte every four cycles (so fetching the instruction takes 8). The 8086 fetches two bytes every four cycles. Also, the CGA card is surprisingly slow to access; the "snow" might be tolerable if it allowed fast access, but accesses need to be synchronized to a character-output clock which is active once every 2.67 CPU cycles... | |
| Jun 28, 2016 at 8:46 | history | answered | Rico Pajarola | CC BY-SA 3.0 |