[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pcc-list
Subject:    [Pcc] alpha release of riscv32 C backend
From:       Tim Kelly <gtkelly () dialectronics ! com>
Date:       2022-10-27 13:04:21
Message-ID: 635A81D5.7060607 () dialectronics ! com
[Download RAW message or body]

Hello,
I've been working on this off and on for the past two years, and I think
it is mature enough to release it.  It is a mishmash of some early work
from Ragge, parts of the PowerPC backend, and a lot of targeted code for
RISC-V.  The files still have copyright for Ragge, which is fine for me
once they are committed to the tree.

The source code is at

http://www.dialectronics.com/RISCV

You will need to add

1) riscv*) targmach=riscv ;; to the appropriate OS in configure if it is
not already there

2) arch/riscv to pcc/

3) the files to arch/riscv/

In order to configure for cross-compiling, you will need
--target=riscv32-xxx where xxx is the OS you are using.  Your OS may
need other flags.  My cross-compile shell script looks like

old_path=${PATH}
export LIBS='-L/usr/lib/pcc -L/usr/lib/pcc/i386 -ld -lc -lfp -le'
export YACC=/usr/bin/yacc
./configure --with-libdir=/usr/lib --with-linker='ack_linker_shim'
--prefix=/usr \
         --with-libexec=/usr/libexec --with-assembler='as_shim' \
         CC=pcc CPPFLAGS='-DUSE_YASM -DYYERROR_VERBOSE -DEBX_IS_SCRATCH
-D_MINIX -D_POSIX_SOURCE -DPCC_DEBUG' \
         --disable-stripping --target=riscv32-minix
make clean && make && make install
export PATH=${old_path}

Floating point should be fully supported.  I ran some code from Sundials
through it and it seemed to go well.  Passing structs directly, as
allowed by the RISCV ABI, should be full supported.  Temp registers
should be fully supported, and if you get a failure with this, please
let me know with some sample code.

The above link has more specific information about the development
environment I used for this.

Some caveats:

1) This is only tested against -O

2) varargs is not yet working

3) There may be an issue where two consecutive jumps (jal) lead to an 
error in destination labels.  I am working with Ragge on this.

Please do not send me bug reports about code that won't compile without
-O.  I focused on code that emphasized the register-centric
architecture of RISC-V.  Yes, some store and load operations might not
work.  If it also fails with -O, that is a bug.

I have an issue with needing to move the stack pointer at a specific
point to implement varargs, but I have been unable to get the tree to
cooperate.

There are some issues in efficiency that I am hoping is simply because I
have not yet matched the templates with enough granularity.  For example,

        li t0, 0               ; sub for scon tword (right)
        sb t0, 0(fp)           ; assign byte

should be

	sb x0, 0(fp)

but I suspect that when I do some wholesale substitutions of scalar
conversions I am preventing the tree from seeing this.

Additionally,

         mr t0, fp              ; caught3
         addi a0, t0, 256        ; zp

should be

	addi a0, fp, 256

but I am not sure exactly the problem here with the OPLTYPE matching or
if because this is a two-step optimization I am not looking up the tree
as I should be.

Within my own development environment, I do not (yet) have a RISCV
assembler.  Therefore, testing has only gone as far as -S compiling and
manual review of the output.  As time permits I will run some of the
more complex output Assembly through an online emulator.  Early tests of
basic math operation and other algorithms were successful.

There are a lot of comments in the code and the output.  Please do not
alter them when reporting bugs.  To report a bug, please include the
line of code, preferable isolated to a single file, and the tree output
that failed, which should be in the .s file.

The code base I compiled against should be -current, so this should
merge.  However, I have a bit of trouble with cvs in my development
environment (Minix-3.1.6 with a custom-built BSD-licensed toolchain), so
I have not updated DATESTAMP and it is possible I have missed something
with manual updates.

.ident "PCC: Portable C Compiler 1.2.0.DEVEL 20200630 for
riscv32-unknown-minix"

# riscv32-minix-pcc -v
Portable C Compiler 1.2.0.DEVEL 20200630 for riscv32-unknown-minix

# file /usr/bin/riscv32-minix-pcc
/usr/bin/riscv32-minix-pcc: MINIX-PC 32-bit executable, sep I&D not stripped

I do build pcc with pcc:

# pcc -v
Portable C Compiler 1.2.0.DEVEL 20190328 for i686-pc-minix3

Due to ABI differences between ELF and Minix's a.out, the code base for
my build pcc is not really compatible with -current.  During this phase 
of development I would prefer to eliminate variables by changing code trees.

I see that Ragge has recently committed some code for PowerPC to get it
to compile.  My apologies for not submitting the code I have to get that
platform to work.  I often used it as a reference against my riscv code
to figure out what might be going on.  If you are working on PPC
hardware and need some fixes for the PPC code, please let me know and I
will see if I can help.

Testing feedback and bug reports appreciated.

tim

-- 
Love is the only kind of gold that brings peace to anyone's soul
		-- Robert Palmer

_______________________________________________
Pcc mailing list
Pcc@lists.ludd.ltu.se
https://lists.ludd.ltu.se/cgi-bin/mailman/listinfo/pcc
[prev in list] [next in list] [prev in thread] [next in thread]