4 ms·
Obviously this is just some people talking nonsense on an obscure news group, but the premise is wrong: 808x didn't need to be faster than an 8-bit CPU. The rea
by dboreham 3y ago
Obviously this is just some people talking nonsense on an obscure news group, but the premise is wrong: 808x didn't need to be faster than an 8-bit CPU. The reason someone bought an 8088 computer was to run 8086 software. That software wouldn't run on an 8-bit machine. E.g. it was close to impossible to run a C compiler on an 8-bit system. The talk of bus width and 16-bit multiply is irrelevant. The feature people wanted is the ability to address more than 64K memory.
- mistrial9 3y ago> just some people talking nonsense no, I think some people are rebuilding Z80 and 6502 chips and the like, to get away from Intel spycrap and other reasons
- deleted 3y ago[deleted]
- nils-m-holm 3y agoOne of the guys "talking nonsense on an obscure newsgroup" here. :) There was no premise. I ported my T3X compiler (http://t3x.org/t3x/t3x0.html http://t3x.org/t3x/t3x0.html) to DOS and CP/M, self-compiled it on both, and was surprised to see pretty much no difference between the lines compiled per MHz on both systems. It is just a friendly discussion to explore some technical details of ancient architectures. No attempt to question IBM's business model. That would be a bit late to the party anyway :)
- pacha-- 3y agoThe Z80 and 8088 are CPUs from when I was a kid. I clearly remember how 8088 was considered a much more advanced one back then. Nice to see this comparison. Thanks a lot for sharing.
- anonymousiam 3y agoI was actually surprised by the results, but maybe not in the way that most people would think. I avoided the 4.77MHz PCs because my (self built) 4MHz Z80 machine consistently outperformed them. I used IBM PCs at work and they were fine. The extra memory was awesome, but the speed of running applications was never in question. My Z80 was always faster. The 16-bit instructions of the 8088 required two bus cycles to fetch, while the 8-bit instructions of the Z80 required only one. Memory bandwidth was comparable (4116 dynamic RAM) and caches did not yet exist, so the Z80 always won. I did not "upgrade" my home computer until the 386(SX) could emulate the Z80 faster than the Z80 silicon could run.
- eichin 3y agoHeh, where were you in 1983 when I needed a decent Z80 Compiler :-) (edit: oh this isn't C. Still, any compiler would have been a step up from asm) (I was at a small company doing mailing list processing for non-profit fundraising campaigns, on an IMSAI (upgraded to a Z80 and 24M hard drive) (no that's not a typo, it was huge by which I mean * it was split in to 3x 8M pseudo disks so it fit the CP/M filesystem limits * it was about the size of a pair of tower PCs tipped over and laid side-by-side ) and we were looking askance at IBM PCs in particular - not enough I/O, not faster - in observable ways, like WordStar had noticeable latency compared to the Z80 version - it was pretty easy to believe the gossip that "these were only moving in quantity because IBM was forcing their big customers to buy them", which was a popular theory it at the time. We were, with hindsight, entirely wrong :-)
- zybftjmvs 3y agoI am interested in reading your book on Raja Yoga, but I am a student experiencing financial difficult at the moment. I just thought I would ask you if there is a free digital copy available.
- flohofwoe 3y agoGetting an 8086 or 8088 to address more than 64 KByte of memory was just as much a PITA as on 8-bit computers though, on the 8086 you had to wrestle with 64 KByte segments (selected via segment registers), and on 8-bitters one had to wrestle with bank switching - in the end both are pretty much the same thing except that 8086 systems moved the address decoding into the CPU.
- caf 3y agoI don't think this is right. The segment registers are significantly more ergonomic than bank switching: the separate CS and DS registers means it's very easy to work with an independent 64k of code and 64k of data (if you're working in assembler, you can have a separate stack too); the segment override prefixes make working with multiple segments simpler; and the built-in far call / return and far jump give you a nice hardware facility for making code seamlessly relocatable.