Ccsh

vbt

Staff member
I've found on my old archives another SN System compiler. Is it worth to publish it ?


C:\>D:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\~AceTemp\CCSH.EXE

CC for Saturn SH v3.06.0015 (Win32)

(c) SN Systems Software Ltd 1997

Usage: CCSH [options / files]


Main options :

-c compile to object file

-S compile to assembler source

-E pre-process only

-v print executed commands

-o FILE specify output file

-l LIBRARY specify library to link in

-L DIR specify directory to search for libraries

-I DIR specify directory to search for include files

-D NAME define pre-processor macro

-D NAME=DEF define pre-processor macro to string DEF

-U NAME undefine pre-processor macro

-g generate debugging information

-ON set optimisation level N : O0=none, O3=max

-f... compiler option/optimisation - see compiler documentation

-m... machine specific option - see compiler documentation

-ansi check code for ANSI compliance

-Wall enable all warnings

-w disable all warnings

-W... other warning control - see compiler documentation

-Wp,... specify pre-processor option(s)

-Wa,... specify assembler option(s)

-Wl,... specify linker option(s)

-X... specify linker option (same as -Wl,...)

-nostdlib do not link in the standard libraries

-save-temps preserve intermediate temporary files


Associated expected tools:

C preprocessor : cppsh (in INI 'compiler_path' directory)

C compiler : cc1sh (in INI 'compiler_path' directory)

C++ compiler : cc1plsh (in INI 'compiler_path' directory)

Assembler : assh (in INI 'assembler_path' directory)

Linker : psylink (in INI 'linker_path' directory)


See the supplied compiler documentation for further information
 
Of course it's worth to be published, even if it's only for historical purpose. Maybe todays gcc has surpassed that older cc, maybe not.

The thing which would make it interesting for me would be some Saturn specific options. Like the SGL uses a register for a pointer to the SGL data structures (WORKAREA), a register that's not used for other stuff and thus does not need to be saved and restored.
 
The compiler is available in the Psy-Q package on my site (and I assume the package of the same name in the developer tools section here). It might be of interest to archivalists, but is unlikely to be of any practical value.
 
RockinB said:
Like the SGL uses a register for a pointer to the SGL data structures (WORKAREA), a register that's not used for other stuff and thus does not need to be saved and restored.

There's a section in the GCC manual on how to create a global register variable. However AFAIK there is no way to make GCC use GBR-indexed addressing which I guess is what you're really after.


For example, when you compile this:

Code:
typedef struct

{

    int aaa;

    int bbb;

    int ccc;

} Foo_t;


register Foo_t *FooPtr asm("r13");


int Func(void)

{

    FooPtr->aaa = 1;

    FooPtr->bbb = 2;

    FooPtr->ccc = 3;

}
with "cc -Os -fomit-frame-pointer" you get this:

Code:
00000000 <_Func>:

   0:   e1 01           mov     #1,r1

   2:   2d 12           [color=red]mov.l   r1,@r13[/color]

   4:   e1 02           mov     #2,r1

   6:   1d 11           [color=red]mov.l   r1,@(4,r13)[/color]

   8:   e1 03           mov     #3,r1

   a:   00 0b           rts

   c:   1d 12           [color=red]mov.l   r1,@(8,r13)[/color]
 
Thanks for clearing that up antime. So the GBR register is just an address that is commonly used within a program?
 
GBR is an index register that is intended to be used as a pointer to global data (the full name is after all Global Base Register). However it only has a single addressing mode and a limited range which reduces its usefulness. It would however be a pretty good fit for something like a pointer to the SGL workarea, though even that struct may be too large.


Digging a little further, I was incorrect regarding GCC. It can use GBR for thread-local storage, but is still unable to generate GBR-indexed addressing modes. The SuperH TLS spec says that thread-local objects are accessed via address variables generated by the linker, so there may not be much motivation to implement the feature. Here's a modified example:
Code:
typedef struct

{

    int aaa;

    int bbb;

    int ccc;

} Foo_t;


__thread Foo_t *FooPtr;


int Func(void)

{

    FooPtr->aaa = 1;

    FooPtr->bbb = 2;

    FooPtr->ccc = 3;

}
and the generated assembly:
Code:
00000000 <_Func>:

   0:   d1 04           mov.l   14 <_Func+0x14>,r1      ! 0x0 <_Func>

   2:   00 12           stc     gbr,r0

   4:   02 1e           mov.l   @(r0,r1),r2

   6:   e1 01           mov     #1,r1

   8:   22 12           mov.l   r1,@r2

   a:   e1 02           mov     #2,r1

   c:   12 11           mov.l   r1,@(4,r2)

   e:   e1 03           mov     #3,r1

  10:   00 0b           rts

  12:   12 12           mov.l   r1,@(8,r2)

  14:   00 00           .word 0x0000
As you can see, the generated code isn't terribly efficient - address variables that fit within the 8-bit displacement range could be loaded directly.


I don't know if using TLS requires some special support from the runtime if you do want to use the feature.
 
Back
Top