Re: 1985 machine spec...

[mjmahon@aol.com (Michael J. Mahon)]

David Empson wrote:

>Earlier versions of the Merlin/Big Mac assembler (Big Mac, Merlin,
>Merlin Pro and Merlin 8) made use of the "Sweet-16" virtual 16-bit
>machine (written by Steve Wozniak and originally included as part of
>Integer BASIC).
>
>The Sweet-16 virtual machine has sixteen 16-bit registers, and code
>written for Sweet-16 is considerably smaller than the corresponding 6502
>code, but will execute quite a lot slower due to the overhead of the
>interpreter.  It is a classic tradeoff between code size and speed - the
>code size is reduced but it takes longer to execute.  (It is also much
>easier to manipulate 16-bit data in Sweet-16, which makes it easier to
>write a complex application like an assembler.)
>
>Merlin 16 replaced the Sweet-16 code with direct use of the 65802/65816
>processor running in native mode (with 16-bit registers).  This probably
>made the code somewhat larger, but there wasn't as much of a space
>constraint any more, because Merlin 16 only works on a 128K or larger
>machine.
>
>The speed benefit was quite significant: Merlin 16 can assemble a
>program about five times faster than Merlin 8.

I've written several assemblers, for various machines, and would not
consider them "complex" applications, as applications go.  The most
complex part of an assembler is recursive macro definition and
expansion, and the complexity there is not 16-bit arithmetic, but
16-bit pointer handling and text subsitiution.

If address arithmetic is a dominant part of the execution of an
assembler, as opposed to text scanning and hashing/table lookup,
then something is awry.  The fact that going to native arithmetic
instead of interpretive arithmetic made a 5:1 speed difference is
remarkable--either the assembler is using Sweet-16 _way_ too
much, or Sweet-16 is 50 times slower than simple, in-line 16-bit
operations.

It would be interesting to know two things:  1) how much faster
Merlin 8 would be if it used straight 6502 code to do its 16-bit
operations, and 2) how much bigger it would be as a result.

-michael

 Email:  mjmahon@aol.com
 Home page:  http://members.aol.com/MJMahon/