[Coco] GCC: DFLOAT / DIRECT_PAGE

[Gene Heskett]

On Friday 14 November 2003 20:36, David wrote:
>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 C trig library as published in the Rainbow and put into the public 
domain by the author, does all its work in double format.  You may 
want to dig that issue out and study it.

>> 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?

-- 
Cheers, Gene
AMD K6-III at 500mhz 320M
Athlon1600XP at 1400mhz  512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.