Re: The Apple II is crap

["M. Pender" <mpender@hotmail.com>]

Michael J. Mahon <mjmahon@aol.com> wrote in message
20030815134636.11710.00000052@mb-m11.aol.com">news:20030815134636.11710.00000052@mb-m11.aol.com...
> M. Pender wrote:
>
> >Changing the time required to perform instructions as a function of the
> >machine architecture *inherently* changes how code works.  Timing
critical
> >code had to be written so it would take the same time whether the first
word
> >of a pair of parameters was on an odd word boundary or an even word
boundary
> >when a 16-bit data bus was used, vis the 8-bit data bus of the 8088.
That's
> >a HUGE difference.
>
> That code runs without change is a first-order fact.
> The speed at which it runs is second-order.

IMHO the speed at which code runs is a primary consideration.  In the
situation I mentioned the same instruction would take different periods of
time to complete as a function of the addresses being accessed in memory, as
compared to a function of the instruction being executed, the clock speed of
the system, or the bus architecture.

> Consider that later, wider implementations are always significantly
> faster than their predecessors.  As a result, even old code which is
> decidedly non-optimal for the new implementation usually runs at
> least as fast as it did on its narrower-implementation predecessor.

That statement requires a HUGE assumption set.

Wider implementations can be significantly *slower* than their predecessors
when running legacy software due to the overhead of additional fetch cycles,
context switching and management of system resources such as stacks.

> Timing-critical code is a different thing entirely, and the IBM PC
> always had hardware that could be used to create, or at least
> calibrate, a real-time delay, independent of processor speed.

Not really; the PC hardware can only be used to calibrate predictable
delays.  Constant timing delays can be calibrated in terms of ## usec per
instruction, but I was talking about a timing delay that varies based on
which addresses are accessed.

Unless the software was specifically written to force program and data
segments/instructions to start on even word boundaries, all bets are off.

Consider, for example, the difficulty of estimating the execution time of
code for the Apple IIgs that accesses memory from different pages that
supports different access speeds.

You can't just assume it all away by calibrating a timing loop -- the
programmer has to *understand* the way the timing works and deal with it in
the code.

- Mike