[Raion]

I've added pre-eliminary support for PCC on IRIX using the latest CVS versions. it is however, nonfunctional and I'm not sure why. In any case, I wanted to document how easy it was to add it.

pcc, if your arch is supported, requires patching in configure/configure.ac, and a file in os/<osname>/ccconfig.h that contains definitions for things: 

https://github.com/IanHarvey/pcc/blob/ma...ccconfig.h

For now, I can't get MIPSPro to work with it. But I did get it working using GCC 4.8.5, just don't use Bison, it broke on me. Many times. IRIX yacc or byacc should work. 

It builds valid MIPSIV executables:

% file /usr/local/bin/pcc

/usr/local/bin/pcc:    ELF N32 MSB mips-4 dynamic executable MIPS - version 1

However, the compiler itself does not like IRIX's headers:

% /usr/local/bin/pcc -o gettext gettext.c
/usr/include//internal/string_core.h, line 61: Syntax error
/usr/include//internal/string_core.h, line 61: invalid function definition

for example, or:

/usr/local/bin/pcc -c util.c -std=c99
#error This header file is to be used only for c99 mode compilations
error: /usr/local/libexec/cpp terminated with status 1

Additionally, compiling hw.c didn't work... (hello world)

Code:

root@murasaki /tmp % /usr/local/bin/pcc -c hw.c
ld32: FATAL   11 : Object file format error (/tmp/ctm.a42098): unrecognizable format
error: as terminated with status 2
root@murasaki /tmp % /usr/local/bin/pcc -S hw.c
root@murasaki /tmp % ls
hw.c  hw.s
root@murasaki /tmp % more hw.s
        .section .mdebug.abi32
        .previous
        .file "hw.c"
        .text
        .p2align 2
        .align 2
        .globl main
        .ent main
main:
        .frame $fp,16,$ra
        .set noreorder
        .cpload $25     # pseudo-op to load GOT ptr into $25
        .set reorder
        subu $sp,$sp,16
        sw $ra,4($sp)
        sw $fp,($sp)
        move $fp,$sp
        subu $sp,$sp,8
L249:
L253:
        la $a0,L257     # load constant address to reg
        subu $sp,$sp,16 # call (args, result in v0) to scon/sname
        jal printf
        nop
        addiu $sp,$sp,16
        sw $v0,-4($fp)          # store (u)int/(u)long
        nop
        move $v0,$zero  # load 0 to reg
        sw $v0,-8($fp)          # store (u)int/(u)long
        nop
        j L251          # goto label
        nop
        nop
L251:
        lw $v0,-8($fp)  # load (u)int/(u)long to reg
        nop
        addiu $sp,$fp,16
        lw $ra,-12($sp)
        lw $fp,-16($sp)
        jr $ra
        nop
        .section .rodata
        .p2align 0
L257:
        .ascii "Hello World!\0"

My guess, without being an ASM expert, is that it either is not producing correct 32-bit MIPS code for our OS (which is possible, as it may have been designed for embedded MIPS), it's not using valid ASM for the IRIX as. If I feed it into the GCC as:

Code:

root@murasaki /tmp % file a.out
a.out:          ELF N32 MSB mips-4 relocatable MIPS - version 1
root@murasaki /tmp % ./a.out
./a.out: Permission denied.
root@murasaki /tmp % chmod +x a.out
root@murasaki /tmp % ./a.out
./a.out: Exec format error. Binary file not executable.

I suspect that even if that is correct for our dialect of MIPS, we have ABI issues. PCC is a simple compiler, but I'm a novice to stuff like this. 

I've mentioned to Anders Magnusson and the PCC lists to see if I can drum any interest up. It's worth nothing it only uses soft floats for MIPS, however. It'd be nice to get hard float support. 

Clearly, this took me less than 20 mins to port and get this far, so hopefully we can get even further?

Edit: pcc-libs compiles without a hitch - patch the configure and it works.

[jpstewart]

Preface:  I'm not an expert on compiler internals and I haven't been able to find much documentation about the contents of ccconfig.h so take the following with a grain of salt.  (Perhaps a whole salt shaker is in order....)

I think that the definition of DYNLINKLIB in your provided ccconfig.h is wrong.  You've set it to /lib/ld but that file doesn't exist on any of my IRIX boxes.  I think it should be /lib/rld instead, based on the fact that the Linux configuration points to /lib/ld-linux.so.2.  Those two programs fulfill the same purposes on their respective platforms, I believe.

However, the compiler itself does not like IRIX's headers:

% /usr/local/bin/pcc -o gettext gettext.c
/usr/include//internal/string_core.h, line 61: Syntax error
/usr/include//internal/string_core.h, line 61: invalid function definition

That one is worrisome, since line 61 of string_core.h isn't a function definition but a declaration (aka prototype).  The parser isn't properly distinguishing between declaration and definition.

/usr/local/bin/pcc -c util.c -std=c99
#error This header file is to be used only for c99 mode compilations
error: /usr/local/libexec/cpp terminated with status 1

This is a simpler problem.  The IRIX compiler defines __c99 when in C99 mode and the headers check for that and bail out if it is not set.  Brute force approach:  put -D__c99 on the command line in conjunction with -std=c99.  If that works, figure out how to get pcc to add it automatically.  As a first guess, I'd add it to c99defs on line 1668 of cc/cc/cc.c in the pcc source, after the definition of __STDC_VERSION__.  There should be a way to do that through ccconfig.h, but I haven't found it yet.

Those are my initial thoughts. Good luck!

[Raion]

It's likely boneheaded on ccconfig.h -- I had /lib/ld on my system but I'll try /lib/rld. We're nowhere near the link phase, though, so it isn't going to matter until I get the codegen fixed.

Thank you for those hints. I'll probably trawl through it and try and see if I can get ragge (the guy maintaining PCC) to help.

[Raion]

Code:

/* common cpp predefines */
#define    CPPADD    { "-Dunix", "-Dsgi", "-D__SVR4", "-D__unix", "-D__sgi", "-D__ELF__", NULL }

/* host-dependent */
#define CRT0        "crt1.o"
#define CRTBEGIN    0
#define CRTEND        0
#define CRTI        0
#define    GCRT0       0
#define    RCRT0       0

/* host-independent */
#define    DYNLINKARG    "-Bdynamic"
#define    DYNLINKLIB    "/lib/rld"

#if defined(mach_mips)
#define    CPPMDADD { "-D__mips__", NULL, }
#else
#error defines for arch missing
#endif

Updated ccconfig.h for pcc for IRIX. This is probably still not 100% correct, but it's my best guess/work thus far. I will start looking into fixing the parser and codegen soonish, but there's other stuff on my plate and I may need to involve others.

[Raion]

I've narrowed down the issue with the parsing to a lexer issue in PCC. I have been taking the time to learn lex and try patting this down.

[Raion]

Still working on parser/lexer and preprocessor issues, but I enlisted the help of someone and we're working on fixing codegen. Currently, hello world can compile if it's linked with GCC. PCC isn't linking it correctly with either setup, so rld can't make heads or tails of it.

The preprocessor is still stumbling over many parts of the headers. That will be resolved, likely, once I get more of an understanding of how the preprocessor works for PCC.

Just to explain the goals here, PCC is a simple compiler, one that's easily malleable and changeable compared to something like GCC. I have a lot of ideas for this.

[Raion]

Ok, so for those who haven't found it, we've setup a gitea for this:

https://gitea.irixce.org/Raion/portable-c-compiler-irix

Some things I've discovered since, and will update for this:

/lib32/rld is what it needs currently, as pcc has no proper multilib support, for DYNLINKLIB.

It currently outputs PIC code when it shouldn't.

The preprocessor appears to be the source of these parse issues, period. Both GCC and MIPSPro's preprocessors produce valid preprocessed code for PCC.

% /usr/local/bin/pcc -o grep grep.i
/usr/include/regex.h, line 208: compiler error: Cannot generate code, node 1009fdd0 op FUNARG
error: /usr/local/libexec/ccom terminated with status 1

This is an example of how the errors change when you feed it preprocessed code.

So you're probably thinking to yourself "Raion why are you messing with this?"

It's because PCC is simple. It's simple, it's hackable, and I think in some ways it's more suitable to my development needs. I am not going to hoist it up as better than any other compiler, but I'd like to get it into shape. A small, extensible compiler written in C and under 100k lines of code for the C frontend, middle end, and backend (once you take into account platform-specific code, even less!) that has no existing port to IRIX is an opportunity.

As it stands, it's not of any use for serious dev. But if I can get it into somewhat of a proper shape, then it could be a target in the future. It's simpler than GCC, though I may use GCC documentation to try and fix it and make it better.

[jpstewart]

Thanks for posting the updates, and even more for the hard work that makes them possible. I'm looking forward to seeing what comes out of the project.

[Raion]

I wish we had people with more brains than me! I'm learning, but I feel utterly and completely out of depth!

[jpstewart]

I'm learning, but I feel utterly and completely out of depth!

Welcome to the club.  I've been using C compilers for the last 28 years.  (I can't believe that's right...since 1993.)  But my knowledge of compiler internals and how to write them is still absolutely zero!  I guess it's like a car:  I can drive one, but I couldn't build or fix one of those either.