[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Apple II benchmark
In article <393E4267.7FE02C21@inetnebr.com>,
Roy and/or Janet Miller <millers@inetnebr.com> wrote:
> Paul Schlyter wrote:
>
>> And in the real world, one often wants to process data in bigger
>> chunks than 8 bits at a time -- in such cases the 8-bit data bus
>> of the 6502 becomes a real bottleneck.
>
> Unless, of course, one is writing a program that deals almost entirely
> with ASCII code, such as a text editor of some sort. Admittedly, not much
> is being done in that area any more.
Actually you're bringing up an interesting point here. A few decades
ago, computers were often word addressed, and not byte addressed as
almost all computers are today: to fetch memory contents, you'd have to
fetch a whole word at a time. If all you wanted was a partocular
byte, then you'd have to shift and mask that byte out -- much like as
if you want a few bits from a byte-addressed machine.
Some 15 years ago, I worked a lot with a CDC 6600 compatible
mainframe: this was a word addressed machine with 60-bit words and
18-bit addresses. 18 bits can address only 256K, however in this
case it wasn't 256 Kbytes but instead 256 Kwords (which corresponded
to approximately 2 MBytes on a modern computer). On that machine,
characters were stored in 6 bits each, or 10 characters per word:
this left room for little more than digits, uppercase letters, and
some punctuation. They used another mode to store characters too,
where each character occupied 12 bits, i.e. 5 chars/word: this
was often referred to as "ASCII", since it could store the entire
ASCII alphabet.
The DEC-10 used 36-bit words: each char went into 7 bits, i.e. 5
chars per word could be stored. This caused problems when ISO-Latin,
PC-8 and friends appeared, which used the 8'th bit too to store
characters; thus the DEC-10 also had 8-bit text files where 4 chars
per word could be stored (the remaining 4 bits of each 36-bit word
was then unised). This often caused confusion when transferring
files: if a text file was transferred with an incorrect assumption of
the byte length (i.e. an 8-bit-byte file was transferred as if it was
a 7-bit-byte file, or the other way around), the result often became
unintelligible. There were system utilities to convert between 7-bit
and 8-bit text files on the DEC-10. All compilers on the DEC-10
required the source as a 7-bit text file, and would puke if you fed
it an 8-bit text file.
Anyway, my point here was: to run a program which handled single
bytes a lot (such as a text editor) on word addressed machines as the
above, where the hardware didn't allow you to read or write
individual bytes, was S-L-O-W .....
So that's why modern computers are almost always byte addressed.
When computers first appeared, they were almost always word
addressed, however back then computers were intended for computing,
not for text processing: back then CPU time was too expensive to be
wasted on what could be done with a typewriter anyway...
----------------------------------------------------------------------
Side note: on the CP/M operating system, Microsoft defined a format
(the .REL format) for relocatable object files which were based not
on byte streams but on bit streams. The purpose was to save disk space:
common items were made shorter than less common items in the object
files. But the linker then had to read each relocatable object file
as if it was a bit stream, i.e. shift out each bit, one at a time,
and read another byte whenever needed. This too was S-L-O-W.... for
the same reason as above: byte addressed computers does not allow you
to read individual bits directly, instead you have to read whole bytes
and then shift and mask out the bits you want to get at.
--
----------------------------------------------------------------
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch