Re: A92: Plus C suggestion

[Prev][Next][Index][Thread]

Re: A92: Plus C suggestion


HonorIam2@aol.com wrote:
> 
>         First of all, I want to congradulate you guys for starting to write this
> compiler.
>         As far as the compiler goes you should provide a documentation on your
> implementation of the routines (i.e. explain that the for(,,,){...} command
> uses such and such register for it's increments. This way when you preprocess
> your files us programmers can use an asm{...}  block for our own code.  You
> should keep as many of the defined functions in a header file so that
> programmers like us will be able to expand on your routines as easily as
> possible and be more versatile with putting asm blocks next to C language
> blocks.
> I am also interested, I know C and the 68k well and might be able to help you
> on any syntaxing conventions for register assignination.
> Here to help
> -Tim Adkisson
> <a href="honorIam2@aol.com">honorIam2@aol.com</a>


Any C compiler worth its weight will not produce "predictable" register usage.
That is, when you declare or define a variable in C the compiler may assign it
to a memory location or to a register.  An optimizing compiler will always look
for the best way to represent its variables using registers, but there may not
always be enough room (ie- too many variables and too few registers).

Let's take a dumb delay function as an example:

void DumbDelay( void )
{
   unsigned short outerCount;
   register unsigned short innerCount;

   for( outerCount = 0; outerCount < 1000; ++outerCount )
   {
      for( innterCount = 0; innerCount < 500; ++innerCount )
      {
         ;
      }
   }
}

This might compile to something like the following:

_outerCount   equ      -2
_innerCount   equ      D7

_DumbDelay:   link     A6,#-2
              clr.w    #0,_outerCount(A6)
_dumb_01      moveq.l  #0,_innerCount
_dumb_02      addq.w   #1,_innerCount
              cmpi.w   #500,_innerCount
              ble.s    _dumb_02
              addq.w   #1,_outerCount(A6)
              move.w   _outerCount(A6),D0
              cmpi.w   #1000,D0
              ble.s    _dumb_01
              unlk     A6
              rts

The automatic variable "outerCount" is declared locally by the function and
might therefore be assigned memory in a local stack frame (also allocated by
the function using the link command).  With a lot of variables it would be
very difficult to determine where it might be in memory.

The automatic variable "innerCount" was declared with in our example using
the "register" qualifier.  The compiler then allocates a register that is
not already in use (some compilers start with D7 and work backwards).  With
a more compilicated function, it again becomes very difficult to determine
which register holds the variable you're wishing to access.

It would be best to make the compiler do all of the work...why in the world
would anyone want to work harder than their compiler?  If you want to have
inline assembly in your C code then you should be provided a standard way
of accessing variables by their name.  Our mythical compiler above produced
an underscore in front of each variable name (a great way to keep C and ASM
variable names from conflicting).  Thus, if you had some inline assembly
where our function does nothing { ; } then you could access a variable or
register simply with its name (eg- _innerCount).

If inline assembly is not a desirable feature for PlusC, then there ought
to be a way of linking object modules together once compilation and assembly
once the compilation and assembly steps are complete (this is best for a
truly ANSI compiler).  Let the comipler compile the C code, and let an
assembler assemble the assembly code...then let a linker combine them by
resolving references to functions, variables and the like.  Also let the
linker worry about libraries...that's why linkers are often referred to
as linker-librarians.

This is getting too long so I'll stop here...
Keith Kirton / kkirton@acex.com
References: