reset vector on a 68hc11

[Ludis Langens]

Pat Ford wrote:
> 
> > Because if straight assembly just barely fits in the address space you
> > have and just barely runs fast enough, then the C is not going to cut
> > it.
> 
>  I think it was due to a lack of good compilers, I've done alot of X86
> assembly and C (thats what I do at work) wiht the right compiler and
> optimizations C can go almost as small as handwritten asm. This could
> be the start of a holy war.

The 6800/68HC11 architecture is not C compiler friendly.  Compiled code
could easily be 2 to 3 (or more) times as big as handwritten asm.  The
x86 is meant to support compilers, hence you might not have observed
such a diference.

The 'HC11 has no stack relative addressing modes.  This creates problems
accessing function parameters and C style auto variables.  Every access
needs to be preceeded with a TSX (or TSY), or else one of the two index
registers needs to be dedicated to use as a stack frame pointer.  Either
way, this is a big chunk of the available registers.

You might have noticed that GM uses lots of variables at absolute memory
locations.  Many of them have global scope - these would correspond to
the C "static" type.  Many others are used only tempararily from one
function.  A compiler would put these on the stack - with a big code
size/speed penalty.


Years ago, I translated a complex 68000 assembly function into C for
comparison (and portability) purposes.  These were the results:

  Speed: Asm twice as fast as C.
  Size:  C twice as big as Asm.
  Lines of source code: Equal - about 1000 lines.  Of course, many of
    the C lines contained just { and } characters.
  Bytes of source code: Asm twice as big as C (due to a comment on
    each line).

Part of the speed/size difference is that the compiler ran out of
registers and had to spill variables onto the stack.  The assembly code
could use the 68K's stack pointer, frame pointer, eight address
registers, and nine data registers.  ;-)


Charlie Springer wrote:
>
> Besides, it may have been done in c. How could you tell from a disassembly?

Two simple ways:  Look for non-optimal code sequences.  Look for bugs.

A compiler won't doubly load (or store) a register.  (Or else it will
always do that.)  Handwritten code is likely to have a few such
inefficiencies.  Compiled code will have the same flavor throughout. 
Handwritten code will vary, especially if multiple programmers wrote it.

A common GM trick to save code size is to load X with a pointer into the
calibration data.  Then, up to 256 bytes can be accessed using indexed
addressing.  This saves one byte of code per access without any speed
change.  The only penalty is the extra LDX opcode.  This trick was
extensively used first in the '7148.  Since then, it has become standard
GM practise.  However, in _every_ early '90's ECM program I've looked
at, there is at least one bug where the X register gets trashed while it
holds this pointer!  A compiler wouldn't make such an error.

-- 
Ludis Langens                               ludis (at) cruzers (dot) com
Mac, Fiero, & engine controller goodies:  http://www.cruzers.com/~ludis/