On Wed, 3 Oct 2007, Chuck Guzis wrote:
Date: Wed, 03 Oct 2007 11:17:06 -0700
From: Chuck Guzis <cclist at sydex.com>
Reply-To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at
classiccmp.org>
Subject: Re: TI 990 architecture / was Re: TI-99/4A Floppies
On 3 Oct 2007 at 10:13, Peter C. Wallace wrote:
I think I chose the 9900 based on the Osborne
book, it had the shortest
benchmark program...
Those benchmarks weren't very comparable! Some had artificial
restrictions placed on them because a "move any number of bytes
anywhere" sample of code would likely take more than a single page of
print. And for many of them, the *size* of the benchmark code wasn't
taken into consideration.
For example, the Z80 benchmark is really shorter than that of the
TMS9900; the 9900 benchmark makes the assumption that the workspace
has been "preloaded" with the operands and that a BLWP was used to
change context--and that words, not bytes, are to be moved. If the
registers used are explicitly loaded and stored, the TMS9900
benchmark would have been much longer.
This overly-simple benchmark with varying assumptions is one of the
biggest weaknesses of Volume II of the Osborne books. Perhaps a
better benchmark might have been searching a character string for a
matching substring.
But even with its weaknesses, the "Introduction to Microcomputers"
set was a valuable resource when there was little software and no MPU
was yet dominant.
Cheers,
Chuck
It was mainly the source code size of the assembly language and the
minicomputer elegance that I liked (since at that time assembler was all I
knew), In comparison the Z80 instruction set is anything but minicomputer like
or elegant, just a bag on the side of a bag on the side of an 8008.
The registers-in-memory architecture might be suitable for a FPGA CPU where
BlockRAM (as system memory) is almost as fast as registers. Why not have
registers in memory instead of simulatiing it badly (and expensively power
wise) via caching, that is, why move data if you dont have to?
Peter Wallace