[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