chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] [4.7.0.3-st] Compiling on Solaris 10


From: Nicolas Pelletier
Subject: Re: [Chicken-users] [4.7.0.3-st] Compiling on Solaris 10
Date: Thu, 10 Nov 2011 20:10:10 +0900

Hello John,

Thank you for your suggestions. Here is the next episode of my sparc
adventures...

On Thu, Nov 10, 2011 at 00:36, John Cowan <address@hidden> wrote:
>
> Currently, sparc is not a supported CPU.  The first thing is to add it
> to the list of known CPU architectures.  Add the line
>
>        sparc) echo "sparc";;

I added the line as:

    sun4u) echo "sparc";;

since this is what uname -m says.

> 1) Try copying apply-hack.sparc64.S to apply-hack.sparc.S and hope
> it works.  If it does build, be sure to run the tests.

This does not work. The assembler complains about setx, ldx... saying
instructions from a set more recent than sparcv8 are unsupported. Fair
enough. Looking at what the code does, it seems it expects the number
of arguments, and a base address for a function, treats the first 6
arguments as passed through registers and loads the rest from the
stack. Hmm... Now, looking a little at the output of objects with
objdump and dbx, here is how things look like on this machine:

the object format is elf32-sparc. I am unsure about the C ABI.
the addresses are 32-bit
the global and output registers seem to be 64 bits wide, the local and
input registers 32 bits wide (weird, maybe wrong).

There are some magic constants in the apply-hack.sparc64.S file which
I do not understand. What is the 2047? And the 176? The code just
before these looks as if it already reserved a "window" for the
registers on the stack, so what is this?

In the case of sparc, if it is possible to use the same general scheme
(no pun intended), I would have to replace ldx, sllx and co with
shorter instructions, saving the higher, then the lower part of the %g
and %o registers I suppose... And of course, modify the various other
constants (8, -2, 3) to accomodate for the different register width.
Does this make any kind of sense?

> 2) If that fails, try disabling APPLY_HACK by adding the following patch
> to Makefile.solaris after the comment line "# options":
>
> ifeq ($(ARCH),sparc)
>        APPLY_HACK=
> endif
>
> As far as I know, nobody has tried to build Chicken without an apply-hack
> in a long time.

This was a simple thing to do, but did not work. As the first part of
installilng chicken, I must first bootstrap it, with:

  gmake PLATFORM=solaris CHICKEN=/bin/true PREFIX=$HOME boot-chicken

and after compiling for a few moments, the build fails with:

gcc -fno-strict-aliasing -fwrapv -DHAVE_CHICKEN_CONFIG_H
-DC_ENABLE_PTABLES -c c-backend.c -o c-backend-static.o -I. -I./
gmake[2]: *** No rule to make target `apply-hack.sparc.S', needed by
`apply-hack.sparc.o'. Stop.

Note on the /bin/true part: README is lying ;-) There is no bootstrap
compiler included in the stable releases (1st lie), and there is no
pre-compiled bootstrap compiler to be downloaded from the Chicken site
(2nd lie). But thankfully the .c files are already there, so the
vicious circle of having chicken to bootstrap chicken does not happen.

Advice, comments, directions are most welcome.

-- 
Nicolas



reply via email to

[Prev in Thread] Current Thread [Next in Thread]