Re: [Tack-devel] ACK compiles on NetBSD-macppc, sort of...

[David G. <dg...@co...>]

Gregory T. (tim) Kelly wrote:
> Since ACK is BSD-licensed, seems like it'd be a good thing to have it
> compile on a *BSD OS :-)  I have downloaded the package and made a
> pass at getting ack-5.6 to compile on NetBSD 3.99.3 running on a
> PowerPC (macppc).  With only a couple changes to the first/get_*
> files, it does generate an INSTALL file which appears to successfully
> execute.

Excellent --- ta. I'll merge your changes in.

Apologies for the long silence. I've been rather slowly working on
reworking the entire build mechanism to make it actually comprehensible
--- as it stands, there are big chunks of the build mechanism that I
simply cannot make head nor tail of. While redoing the build system is
not particularly difficult, it is rather time consuming and will eat all
my spare time if I let it; and real world commitments tend to leave me
very little of that right now.

But it is progressing, and I'm planning a pre-beta release at some stage
that should contain a minimal system based around the new build
mechanism that people can play with. This will also contain a vastly
rationalised set of headers --- I can't believe some of the stuff I've
been finding, that were apparently considered acceptable practice back
in the K&R days.

> 1) RISC/PowerPC CPUs are anything but stack based.  There are 32
> general purpose registers and typical 32 floating point registers as
> well as 32 SIMD registers.  Everything is done in registers, even
> reading from and writing to memory.  EM/ACK seem focused on x86 type
> approaches, in the sense of gearing towards stack-based operations.
> Is this going to present additional obstacles to writing a back-end
> table for RISC/PowerPC?

Yes, the ACK likes stacks. There is an ARM backend, but in my
experimentation it appears to generate rather bad code --- however, this
could well be simply because it's immature. The 68k backends are much
more mature, but I don't know enough about the architecture to know what
the code's like.

Certainly, ncg does *appear* to contain a lot of mechanisms for register
management.

> 4) Is this a bootstrap situation, where the PowerPC back-end table
> needs to be written before PowerPC Minix can occur?

Don't think so; the Minix people seem to be talking about using gcc for
the various exotic ports. The ACK appears to be largely unmaintained
these days. I think people *would* use it if there were a port; as you
say, it's BSD licensed, and is a fraction of the size of gcc.

(It's worth noting that there are three separate ACK trees currently in
existence; Minix has one, Michael Kenett has one, and I have the third.
Mine is the most complete but, er, not in particularly good condition!)

> 5) Are there plans to extend the object file formats ACK/LLgen are
> capable of producing? Would this be a good time to propose a PowerPC
> file format alternative to a.out/xcoff? (My personal preference would
> be the Motorola PEF format, as opposed to ELF.)

The ACK only produces ack.out files --- but it does provide a set of
converters for turning linked ack.out files into target executables.
(The idea is that you do all your compilation in the ack.out world, and
only convert into your target platform as a final stage.) Look in
mach/foo/cv.

It shouldn't be hard to write a tool to turn unlinked ack.out files into
something else, and then back again.

>> ../bin/bin/acc -mem44 -I$ACKDIR/include/tail_ac -ansi -O -o test test.=
c
> ../bin/bin/acc: Cannot execute /home/lapd/ack/bin/lib.bin/em_opt

Various platforms have the optimiser in various degrees of workingness
--- if -O doesn't work, try -O0 (and be prepared for bad code). FWIW,
only i86 and i386 support the higher levels of optimisation (but this is
from memory).

--=20
+- David Given --McQ-+ "You cannot truly appreciate _Atlas Shrugged_
|  dg...@co...    | until you have read it in the original Klingon."
| (dg...@ta...) | --- Sea Wasp on r.a.sf.w
+- www.cowlark.com --+