[Coco] Re: gcc-coco revisited

John E. Malmberg wb8tyw at qsl.net
Fri Oct 31 12:36:00 EST 2003


In article <20031031131351.GA584 at localhost.localdomain>,
David <dbree at duo-county.com> writes:
> I'm thinking about looking back into the gcc-coco project again in an
> effort to get a usable OS9 compiler.

The gnu as assembly language does not match any of the native assembly
language formats for any platform that I have used it on.

It is probably possible to come up with a translater that can covert the
soure to gnu as to a format that other Coco Assemblers can deal with.

That way you can cross compile to assembler on your host, and do the final
assembly and link on the COCO until cross tools can be developed.

> Another question.  Would it be best to have a single gcc09 that will
> compile to RS-Dos or OS9 using a switch, or maybe a define, or just have
> two separate compilers?

There are several issue here actually.

1. PIC or non PIC.  Depending on how GCC structures it's directives to
   the assembler, that setting may affect the assembler or the compiler.

2. Runtime libraries.  The compiler is generally ignorant of the target
   operating system.  That is usually left to the header files, and the
   Linker.

   You would want to have a __RSDOS, __OS9, __FLEX09, __HGBDOS, etc for
   the supported target enviroments.

   If you can specify inline assembly directives in the header files, it
   can make the job easier.  The prototypes in the header files is what
   tells the compiler how to call the routines, or if inline assembly
   is to replace them.  Conditionals in the header files can be used,
   or a different library of header files can be used depending on the
   target.

   Many functions that have higher overhead to call then it takes to
   put them inline can be done that way.

   But beware, the GCC compiler, and RISC compilers will also sometimes
   generate external library calls instead of inline code.

   One example is that I have found GCC compliers initializing arrays
   by call bzero(), even on a platform that had a single machine code
   instruction to so the clearing.

3. Assembler/Object/exe format.

> Although I'm sure gcc-3.1.1 has all the features that would be needed
> for our needs, how about going on to gcc-3.3.1?  I've already checked
> and the patch will work.

It is is usually better to keep current.

[reorder]
> The biggest problem right now is the addition of the "direct" directive
> to gcc.  I'm sure it can be done, but it's going to take some studying
> (for me, if I do it) to learn how to add a directive to gcc.

You will want to implement it as a #pragma, and probably a program section or
segment.  This way your source will be acceptable to all ANSI compilers.

#ifdef __GCC09
#pragma direct_page symbol_name [,section] [,offset] ...
#endif

Direct page is not necessarily for global variables, it is conceivable that
a routine could temporarily move the direct page register to some stack
local storage to speed up access.


Also for the education of those that are used to traditional compilers,
GCC is a bit different.

GCC is a shell that calls/chains the other programs in sequence to produce the
expected results.  The preprocessor program is typically separate from the
complier, followed by an optimizer program, followed by the assember program,
and finally a linker program.

--
-John
wb8tyw#qsl.net
Personal Opinion Only




More information about the Coco mailing list