Goddammitsomuch I hate how Google Groups displays dates on mobile. To save anyone else the pain of trying to view the desktop version of the page, on which zooming is plain broken, this conversation is contemporary and not historical. Given the subject it could have easily been a historical conversation.
This is only true when there is some context establishing recency. If I mail you a letter, that is recent and may be assumed to be in the current year. If I find a letter in my grandparents’ attic, I should not assume that it is from the current year. It may have just been moved to the attic yesterday, or it may have been decades before.
For a post about processors from the 70s, there is no default assumption of recency. This post is on Google Groups, which has existed since 2001, and which is a gateway server to Usenet groups that predate it. Absolutely nothing about it gives a shared context in which the absence of a year can be reasonably assumed to be the current year.
Only the Groups discussion is contemporary and the actual content is a decade old. Making assumptions about dates is really fucking stupid. Mind bogglingly so. Even an abbreviated year like "'23" is better than nothing.
>Quick, without doing any research: What early 1980s computer was faster, the IBM PC or the Commodore 64?
ok, now slowly, do the calculation again... the IBM PC and 8088 was the beginning of the future. the Commodore 64 and 6502 was the tail end of the past. The 6502 caught on because it was a bargain price, but at that price it was severely hobbled in what it could do, space- and time-wise
could you write a small program for the commodore 64 that was faster? who cares, because you couldn't write a large program that was faster.
But you could do a heck of a lot with a small program on those machines.
I still find it amazing that we have a lot more processing performance, RAM and disk space these days, and yet every new commercial Operating System version that comes out requires more resources than the last and yet delivers essentially the same results...
Shudder from awesomeness? Windows 2k is still peak Windows UI (the aesthetics might be subject to fashion cycles - still better than the lollipop look that was prelevant on Mac and WinXP shortly after, but the UX has gone into a slow downward spiral since then). Same is true for macOS, only that it reached its peak and following slow regression about a decade later).
Boots into Windows 7 (a 2009 OS) ... No shudder
Boots into Windows XP (a 2001 OS) ... No shudder
Boots into Windows 98 (a 1998 OS) ... No shudder
Boots into Windows 95 (a 1995 OS) ... No shudder
Fires up the old Amiga 1200 and boots into Workbench 3.0 (a 1992 OS) ... No shudder
Fires up the even older Amiga 500 and boots into Workbench 1.3 (a 1988 OS) ... No shudder
Ok, that last one might have triggered a shudder if I'd left the original color settings in place :D
I would continue but I've just found my old Syndicate floppy disks for the A500, so I might be sometime...
From a user experience point of view, Windows 2000 was absolutely awesome. An operating system should not get in your way and distract you from what you need to do the way Win 10 and 11 do.
Has anything changed since 2013? 2003? Windows XP/ME/etc/.../95 was basically the same as modern windows just with boxier window decorations, no windows-phone-tile thing and less spyware.
For most people the opposite was true. They couldn't write a large fast program on a PC because they couldn't afford to buy one.
The "genius" of IBM was to reinvent an updated version of S-100, stick an IBM badge and a "business" price tag on a backward and underspecified machine, and spend millions on marketing.
16-bit hardware and operating systems were already available in the S-100 space.
Between them IBM and MS traded performance for forced standardisation. This likely held back access to much better features - like higher reliability and multitasking - for a decade or so.
"Between them IBM and MS traded performance for forced standardisation"
Maybe I misunderstand, but for me it is a strange statement:
* IBM fought standardization: they initially released a PC compatible with nothing, even in their own product lines, and fought hard against any kind of clones - those that transformed the IBM-PC in a de-facto standard. They even tried with the PS/2 line to break compatibility for all third-party hardware extensions (the MCA bus that could be used only by paying royalties to IBM).
* Microsoft cared neither for performance (obviously) nor for standardization. They just fought to own the market. Their products became de-facto standards because MS worked hard to kill competition and real standards. They even theorized and practiced the "embrace extend extinguish" process to kill competing products by breaking standards.
In what way does those arguments change the calculation of which machine is faster to perform a specified operation?
It sounds more like you try to state that the results have no real world meaning, and that is very correct. But nobody have claimed otherwise. This is about historical computers. We all know which architecture won. Despite being slower performing a ROR.
The original IBM XT (edit: corrected from 'IBM PC' which was an earlier model with even less RAM) only had 128 KByte RAM, that's not different from a C128, CPC128 or Speccy, and some 8-bit home computers could be upgraded to around 1 MByte too (which would have been prohibitively expensive in the early 80's, but technically possible).
And performance wise, bank switching on an 8-bit machine wasn't much more expensive than updating the segment register on an x86
The main advantage of "proper" 16 bit CPUs was the wider databus and ALU. But a wider ALU doesn't help all that much when it is held back by an 8-bit data bus (like the 8088).
> the IBM PC and 8088 was the beginning of the future.
The entry level IBM PC was 16KB, and the top-of-the-line model was 128KB.
> at that price it was severely hobbled in what it could do, space- and time-wise
Again, Commodore 64 had 64KB of RAM, more than the cheapest PC. It also had dedicated sound (SID) and video (VIC-II) chips which made it more performant when it comes to entertainment (i.e. video games).
Even though the C64 (1982-08-01) hit the market about a year after the IBM PC (1981-08-12), it outsold the IBM PC series in 1983 and 1984. At the end of 1985, the IBM PC series was only slightly ahead in total unit sales. Of course, the IBM PC XT came out in 1983 and the IBM PC AT in 1984 so they were higher end models while the C64 was the same model.
I think there's an error in [1] though. On the 6502 the minimal instruction cycle count is two clock cycles, not one. It's correct though that a 6502 can do (and indeed always does) a memory access in each clock cycle, most of those are redundant "junk reads" though.
The 8088 has a external 8 bits bus. The performance improvement hardware 16 bits ALU is neglected by the slower memory access.
And that memory access was also the reason a 6502 carefully programmed will have better performance than a 8088 with 5x the clock speed. The first 256 bytes (0 pages) had better access performance.
This comment is misleading. Z80 also has an 8-bit external bus. And, FWIW, so does the 6502. The reason zero page is fast on the 6502 is because of more concise encoding, not because that memory is somehow faster.
I'm broadly skeptical that a 6502 outperforms an 8088 at 5x clock speed in practice. Would love to see benchmarks. Certainly I'd expect it to be highly task dependent.
I've programmed in 6502 Assembly for decades and your skepticism is right on.
These comparisons have so many variables that they are extremely hard to make accurately.
FTA - I would have guessed that the 8088 is much faster at about
the same clock speed, because it has more 16-bit operations
and does multiplication and division in hardware.
Does the compiler of the compiler make use of these extra 16-bit operations? How many layers of abstraction does it go through for each of the environments? Does it use DOS interrupts when running on DOS and optimized machine code on CP/M?
These comparisons are strange thought experiments.
The compiler uses the same level of optimization on both DOS and CP/M. It is self-compiled on both platforms. It uses DOS interrupts on DOS and BDOS functions on CP/M, but I/O is really not a big issue here. The DOS compiler does make use of the extra 16-bit operations.
Is it still an inaccurate comparison? Sure. But I expected something dramatically different, so I asked.
There are also some very questionable statements in the articlle like saying that 6502 instructions only need one cycle. It's 2 to 7 in reality.
Over the years the comparison between 6502 vs Z80 tend to show that you have to clock the Z80 at about twice the frequency of the 6502 to get the same performance. 8088 having a slight edge over the Z80 it is clear that a 5 MHz will be quite faster than a 1 MHz 6502 (C64 was even under 1MHz as the VIC chip would steal some cycles every 8th display line)
A C benchmark on the 6502 seems suspect to me given that the 6502's architecture tends to make writing stack-based language compilers for it more complicated than other platforms. Some of the difference may be just because the object code generated for the 6502 isn't efficient.
That said, any 16-bit optimizations the 8088's compiler could take advantage of, well, that's fair game.
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.
One 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) 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 :)
The 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.
I 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.
Heh, 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.
I 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.
Getting 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.
I 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.
Funny how all the "PC = newer = better" comments get refuted here.
Let's be honest: early 80's homecomputers were more bang/$ than the earliest PC's. Graphics & sound, BASIC built in, fast-expanding software libraries, etc. They were however more suited for games than business applications.
80 columns were also important. Some 8-bitters couldn't even produce 40 columns. The Beeb could handle 80 columns and so was used in all sorts of areas.
But I'd argue that PCs had unequivocal advantage when 386s came out.
80 columns were pretty much a requirement for CP/M though, which was basically the MS-DOS of the 8-bit era (for instance the Amstrad CPC had an 80 column mode and supported CP/M as optional operating system, and the Commodore 128 also added 80 column support because the whole point of the additional Z80 CPU in the C128 was proper CP/M support).
I think it's interesting to think about the biggest outliers in performance in the past. I was lucky enough to experience the Apple 2 and then later Amiga 1000 in their respective eras. Each of these were ~5 years earlier than similarly capable machines.
I had color games on my Apple 2 (Woz and his incredible NTSC/PAL coloring hacks) long before i had color video games on any other system, including the much later IBM PC era where CGA/EGA/VGA was an add-on feature. When the much later C64 came out the Apple 2 still played pretty much the same games, just without the audio.
The Amiga had hardware acceleration for graphics and sound as standard, long before other systems did the same thing and again was way ahead of contemporaries. Less Woz style cleverness in hardware and more "throw in every feature from the start" architecture. Still there's a reason this system is so popular in the demoscene today. This used to wow people with the graphics even in the Windows 95 era and i used to explain to people "we've had this computer since 1985" to much disbeleif.
I looked at 8088 instruction timing, and add register to register instruction seems to use 2 bytes and requires 3 clocks to execute. Why didn't they make addition while fetching next instruction byte and get a 33% speedup?
The 8088 has a four-byte instruction queue, and at times when the data bus would otherwise be idle the bus interface unit will prefetch the next instruction byte. So fetch and decode/execute are already overlapped.
What really slows down the 8088 is that each 8-bit transfer on the data bus requires four clock cycles. That means simply fetching the two-byte instruction requires eight clocks! Instruction fetch is so slow on the 8088 that it's virtually impossible to achieve the published instruction timing.
Interesting, if I remember correctly, 8080 also required 4 clock cycles to fetch and execute a single-byte instruction. Did 8088 inherit some schematics from 8080? And 6502 uses 1 clock cycle for one memory access.
In reality, most software that time created with C or hand crafted in asm, and effectively use much larger register file of 8088 and its really 16bit arithmetic.
I remember, how much time people spent, to ensure maximum usage of registers, and avoid memory operations at all costs.
Unfortunately, this also leads to decline of alternative technologies, like virtual machines, which that time was mostly stack machines, depend on memory speed.
Sometimes I think it is this feature of the 8088 that creates the famous C power, and not something else.
And I must admit, PC before approx 386, was extremely weak (slow and low colors) on graphics and nearly no sound, so looks like was not accidental, that on PC game culture was totally other than on 8-bits.
Unfortunately, I was not in good position, to see difference myself, but my friends early see consoles and home computers, like MSX, and tell me about their much better graphics and sound. Sure I have not possibility to measure memory speed of consoles.
62 comments
[ 0.21 ms ] story [ 36.6 ms ] threadFor a post about processors from the 70s, there is no default assumption of recency. This post is on Google Groups, which has existed since 2001, and which is a gateway server to Usenet groups that predate it. Absolutely nothing about it gives a shared context in which the absence of a year can be reasonably assumed to be the current year.
It is an odd post though, it really is like just a couple comments, and then the real content is in a link in one of the comments
https://trixter.oldskool.org/2011/06/04/at-a-disadvantage/
So the actual content is a 2011 article talking about historical processors.
[1] https://retrocomputing.stackexchange.com/questions/5748/comp...
ok, now slowly, do the calculation again... the IBM PC and 8088 was the beginning of the future. the Commodore 64 and 6502 was the tail end of the past. The 6502 caught on because it was a bargain price, but at that price it was severely hobbled in what it could do, space- and time-wise
could you write a small program for the commodore 64 that was faster? who cares, because you couldn't write a large program that was faster.
I still find it amazing that we have a lot more processing performance, RAM and disk space these days, and yet every new commercial Operating System version that comes out requires more resources than the last and yet delivers essentially the same results...
Then boot into a 2003 one and try not to shudder even harder.
Bonus points for Windows 95.
Fires up the old Amiga 1200 and boots into Workbench 3.0 (a 1992 OS) ... No shudder
Fires up the even older Amiga 500 and boots into Workbench 1.3 (a 1988 OS) ... No shudder
Ok, that last one might have triggered a shudder if I'd left the original color settings in place :D
I would continue but I've just found my old Syndicate floppy disks for the A500, so I might be sometime...
The "genius" of IBM was to reinvent an updated version of S-100, stick an IBM badge and a "business" price tag on a backward and underspecified machine, and spend millions on marketing.
16-bit hardware and operating systems were already available in the S-100 space.
Between them IBM and MS traded performance for forced standardisation. This likely held back access to much better features - like higher reliability and multitasking - for a decade or so.
Maybe I misunderstand, but for me it is a strange statement:
* IBM fought standardization: they initially released a PC compatible with nothing, even in their own product lines, and fought hard against any kind of clones - those that transformed the IBM-PC in a de-facto standard. They even tried with the PS/2 line to break compatibility for all third-party hardware extensions (the MCA bus that could be used only by paying royalties to IBM).
* Microsoft cared neither for performance (obviously) nor for standardization. They just fought to own the market. Their products became de-facto standards because MS worked hard to kill competition and real standards. They even theorized and practiced the "embrace extend extinguish" process to kill competing products by breaking standards.
It sounds more like you try to state that the results have no real world meaning, and that is very correct. But nobody have claimed otherwise. This is about historical computers. We all know which architecture won. Despite being slower performing a ROR.
And performance wise, bank switching on an 8-bit machine wasn't much more expensive than updating the segment register on an x86
The main advantage of "proper" 16 bit CPUs was the wider databus and ALU. But a wider ALU doesn't help all that much when it is held back by an 8-bit data bus (like the 8088).
Also obligatory: Amiga forever! :D
The entry level IBM PC was 16KB, and the top-of-the-line model was 128KB.
> at that price it was severely hobbled in what it could do, space- and time-wise
Again, Commodore 64 had 64KB of RAM, more than the cheapest PC. It also had dedicated sound (SID) and video (VIC-II) chips which made it more performant when it comes to entertainment (i.e. video games).
[0] https://news.ycombinator.com/item?id=38345672
[1] https://trixter.oldskool.org/2011/06/04/at-a-disadvantage/
And that memory access was also the reason a 6502 carefully programmed will have better performance than a 8088 with 5x the clock speed. The first 256 bytes (0 pages) had better access performance.
I'm broadly skeptical that a 6502 outperforms an 8088 at 5x clock speed in practice. Would love to see benchmarks. Certainly I'd expect it to be highly task dependent.
These comparisons have so many variables that they are extremely hard to make accurately.
FTA - I would have guessed that the 8088 is much faster at about the same clock speed, because it has more 16-bit operations and does multiplication and division in hardware.
Does the compiler of the compiler make use of these extra 16-bit operations? How many layers of abstraction does it go through for each of the environments? Does it use DOS interrupts when running on DOS and optimized machine code on CP/M?
These comparisons are strange thought experiments.
Is it still an inaccurate comparison? Sure. But I expected something dramatically different, so I asked.
Not that it matters much, but strictly speaking this is true only for the PAL version.
On the Dhrystone 1.0 micro-benchmark, a C64 is ~36/s, whereas the PC/XT models tested (basically same as the original PC) are more like 300+/s.
That said, any 16-bit optimizations the 8088's compiler could take advantage of, well, that's fair game.
no, I think some people are rebuilding Z80 and 6502 chips and the like, to get away from Intel spycrap and other reasons
There was no premise. I ported my T3X compiler (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 :)
I did not "upgrade" my home computer until the 386(SX) could emulate the Z80 faster than the Z80 silicon could run.
(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 :-)
Let's be honest: early 80's homecomputers were more bang/$ than the earliest PC's. Graphics & sound, BASIC built in, fast-expanding software libraries, etc. They were however more suited for games than business applications.
But I'd argue that PCs had unequivocal advantage when 386s came out.
I had color games on my Apple 2 (Woz and his incredible NTSC/PAL coloring hacks) long before i had color video games on any other system, including the much later IBM PC era where CGA/EGA/VGA was an add-on feature. When the much later C64 came out the Apple 2 still played pretty much the same games, just without the audio.
The Amiga had hardware acceleration for graphics and sound as standard, long before other systems did the same thing and again was way ahead of contemporaries. Less Woz style cleverness in hardware and more "throw in every feature from the start" architecture. Still there's a reason this system is so popular in the demoscene today. This used to wow people with the graphics even in the Windows 95 era and i used to explain to people "we've had this computer since 1985" to much disbeleif.
(You can tell it's usenet because the "group" comp.os.cpm in the URL is a newsgroup, and Google Groups can be a a HTTP bridge to Usenet)
You can take part in those, too :)
What really slows down the 8088 is that each 8-bit transfer on the data bus requires four clock cycles. That means simply fetching the two-byte instruction requires eight clocks! Instruction fetch is so slow on the 8088 that it's virtually impossible to achieve the published instruction timing.
In reality, most software that time created with C or hand crafted in asm, and effectively use much larger register file of 8088 and its really 16bit arithmetic.
I remember, how much time people spent, to ensure maximum usage of registers, and avoid memory operations at all costs.
Unfortunately, this also leads to decline of alternative technologies, like virtual machines, which that time was mostly stack machines, depend on memory speed.
Sometimes I think it is this feature of the 8088 that creates the famous C power, and not something else.
And I must admit, PC before approx 386, was extremely weak (slow and low colors) on graphics and nearly no sound, so looks like was not accidental, that on PC game culture was totally other than on 8-bits.
Unfortunately, I was not in good position, to see difference myself, but my friends early see consoles and home computers, like MSX, and tell me about their much better graphics and sound. Sure I have not possibility to measure memory speed of consoles.