[Coco] GCC: DFLOAT / DIRECT_PAGE

[David]

On Fri, Nov 14, 2003 at 11:31:41AM -0600, John E. Malmberg wrote:
> I found some references to how to build the .md file in an .info file
> in the GCC distribution that may help.
> 
> It looks like I need to define some instructions to operate on a double
> float for the compiler to be happy.  I have to look up in the ANSI C
> specifications to see what the minimum size for a double is, and review
> the 6809 instruction set to see how it could be implemented.
> 
> The simplest case would be if I can alias it to be the same as a float.
> I do not think I will be that lucky.

I'd go for it for the time being.  Later, after everything else is
worked out, then this could be fine-tuned.
 
> The .info file also may provide how to implement a "direct page" type
> modifier.
> 
> The main thing seems to be to put instruction templates to operate on
> that type in the .md file.
> 
> 
> If I can do it, this is what I will do for direct_page:
> 
> 1. The compiler will treat it like a hint, just as register is a hint.
>    This means that the compiler will prefer to use direct page addressing
>    mode for the designated variable, but since it also has the absolute
>    address for the variable, or a stack/register relative address for
>    the variable, it can decide to use that instead.
> 
> 2. The compiler will default to treating the direct page pointer as
>    what other platforms refer to as a frame pointer for stack variables
>    that are in range.

Yes, but how to get the directive "direct" installed.  Won't this need
to be installed as a reserved word?  Check out the files c-parse* and
also c-common.h, all in the gcc directory.  I really believe that this
word will need to be added to all(?) these places.

Also, as for using hints.  I believe that the usage of "direct" will
need to be absolute.  If it's defined, use direct referencing else use
16-bit.  At least, if we're dealing with linkable modules.  Let's look
at the process of compiling a program.  If the compiler decides which
mode to use in the assembler output, although it realizes the relative
addresses for the variables in _this_ module, it cannot know the
ultimate address in the final program.  However, this is where the
program code is generated.  Suppose we're doing "cc p1.c p2.c p3.c".
Now, after the assembler source files are generated and the object
modules are created, the linker will go through and first allocate all
the direct-page variables (beginning with whatever might be in the
lead-in module, then place the d-p variables of p1 above those.. dp of
p2 above those.. then p3. Now, it goes back and, beginning at the next
address above p3's last dp variables, it begins the same process with
the non-dp variables.

For this reason, it would be impossible for the compiler to
automatically determine what would be DP at compile time.

If we do provide our own assembler/linker, one thing would be needed.  I
believe it was Mike Knudsen who mentioned that the MW linker did not
warn you if you had more than 256 DP bytes.  The linker should
check and warn you if more than this max was reached.  It shouldn't be a
problem to implement, and would be a very good addition.

>    A direct page reference, depending on the internals of the CPU may take
>    one less clock cycle than an 8 bit stack or register offset.  I would need
>    to look at the 6809 specs to see if this is the case.  The difference
>    is that a register offset has to do an 8 bit fetch and 16 bit add, and
>    a direct page reference just has to do an 8 bit fetch.
> 
> 3. The direct_page attribute for a variable name will be able to take
>    a value indicating the program section that the variable will be in.
>    The attributes of the program section will determine the real address
>    of the program section.  GCC already knows how to do the program section
>    part.

I'm not sure I understand what you're saying here.  And another thought
just occurred to me.  I've been thinking in terms of all variables from
all modules to be stored consecutively in one area.  This would be the
case for OS9, but for RS-BASIC programs, this would not be necessary.
The only reason for this would be to utilize the DP function.
Otherwise, it would not hurt for the variables to simply be stored at
the end of the code for the module.  I don't know about FLEX and other
systems.

Actually, it just occurred to me that it might be difficult to use
DP-referencing in BASIC.  For it to work, wouldn't we have to insure
that the variables began on an even page boundary?  Or at least, by some
means, determine an even page reference point for the variables.  At
this point, I'm beginning to doubt that there is much way to implement
DP referencing for BASIC.

But we _do_ need it for OS9.  I'm still struggling with how to determine
if an operator is data in the program.  This needs to be done in order
to determine whether the operand should be referenced by pc or y
(assuming we keep y as the data pointer)..  I had hoped that SYMBOL_REF
would be a data pointer, but apparently not.  Can someone tell me what
gcc interprets SYMBOL_REF, LABEL_REF and PROG_REF (or maybe PROGRAM_REF)
to be?