Gregory T. (tim) Kelly | 16 Jul 21:42 2006

ACK compiles on NetBSD-macppc, sort of...

Hi All,

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.

The first change is to first/get_sys:

Index: first/get_sys
===================================================================
RCS file: /cvsroot/tack/Ack/first/get_sys,v
retrieving revision 1.5
diff -r1.5 get_sys
83a84
> ppc32         32-bit PowerPC running *BSD 

which just adds the ppc32 option to the list of systems.  The second change is to first/get_makepars to
recognize that ppc32 system for word and pointer sizes:

Index: first/get_makepars
===================================================================
RCS file: /cvsroot/tack/Ack/first/get_makepars,v
retrieving revision 1.9
diff -r1.9 get_makepars
3c3
< vax*|i386|sun*|sparc*|m68_sysV_0|m68020|mantra|pmds4|m68k4)
---
> ppc32|vax*|i386|sun*|sparc*|m68_sysV_0|m68020|mantra|pmds4|m68k4)

(Continue reading)

Gregory T. (tim) Kelly | 17 Jul 15:03 2006

Re: ACK compiles on NetBSD-macppc, sort of...

I've made some progress identifying issues with ACK on *BSD.  While the first pass did create executables,
there was limited functionality since almost all of the supporting lib.bin files failed to compiler. 
Using the test.c example posted by David Given
(http://sourceforge.net/mailarchive/forum.php?thread_id=7938530&forum_id=45107) I got

> ../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

em_opt had not compiled.  I traced this down to a problem in util/opt/pop_push.awk.  I believe this to be a
matter of different implementations of awk, rather than an actual bug in the file.  As I mentioned before,
I'm using NetBSD-3.99.3 (macppc), which gives

> awk -V
awk version 20030729

In pop_push.awk, the "'\000'" wasn't creating a null string termination character but instead was
null'ing everything after the '\000'.  I fixed this by explicitly crafting a '\0' string output.  em_opt
now compiles successfully.  

Index: pop_push.awk
===================================================================
RCS file: /cvsroot/tack/Ack/util/opt/pop_push.awk,v
retrieving revision 1.5
diff -r1.5 pop_push.awk
18c18
<         print "'\000',"
---
>         print "'\\""0""',"
25,26c25,26
<               else f_out = f_out "'\000'"
(Continue reading)

David Given | 17 Jul 19:30 2006

Re: ACK compiles on NetBSD-macppc, sort of...

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.
(Continue reading)

Gregory T. (tim) Kelly | 17 Jul 19:44 2006

Re: ACK compiles on NetBSD-macppc, sort of...

Hi David,

Posts are coming through now.  I think the problem was my posting so soon after subscribing.  Is it better to
email the list directly (and not cc you) or to cc it (and direct emails to you)?

I appreciate your responses!

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

I did a follow up post with an additional patch.  I don't know awk specifically, so if the syntax doesn't work
with other awks (nawk, gawk), do what you need to in order to make it work universally :-)

>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.

The reorganized headers would be appreciated indeed.  I traced the lseek problem back to off_t being
defined to be __int64_t in NetBSD (and all BSDs, I believe), while off_t is declared to be "long" in several
types.h headers.  I'm still trying to figure out the most efficient way to fix this.  A centralized
(self-encapsulated,  platform-independent) location for the headers would be great.  

>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.
>
(Continue reading)

Gregory T. (tim) Kelly | 17 Jul 23:24 2006

Re: ACK compiles on NetBSD-macppc, sort of...

Still more progress.

I brute forced arch to compile with:

Index: util/arch/archiver.c
===================================================================
RCS file: /cvsroot/tack/Ack/util/arch/archiver.c,v
retrieving revision 1.29
diff -r1.29 archiver.c
47c47,48
< long  lseek();
---
> 
> extern off_t  lseek();

which just overrides the long lseek to match BSD.  I'm not 100% sure, but this shouldn't break anything on
which off_t is a long.  On BSD, though, off_t is __uint64_t.  This requires adjusting several typedefs.h
files to only define off_t if not already defined by BSD:

Index: include/_tail_cc/sys/types.h
===================================================================
RCS file: /cvsroot/tack/Ack/include/_tail_cc/sys/types.h,v
retrieving revision 1.10
diff -r1.10 types.h
72a73
> #if   !defined(BSD)
73a75
> #endif

Index: include/_tail_mon/sys/types.h
(Continue reading)

Gregory T. (tim) Kelly | 18 Jul 01:26 2006

Re: ACK compiles on NetBSD-macppc, sort of...

>One thing that is still failing in the INSTALL shell is the EM interpreter for C:
>
>Failed for EM interpreter in C, see util/int/Out 
>
>util/int/Out has the following errors (modified for content):
>
>./util/int/m_ioctl.c: In function `do_ioctl':
>./ util/int/m_ioctl.c:63: error: storage size of `tc_buf' isn't known
>./ util/int/m_ioctl.c:94: error: `TIOCSETN' undeclared (first use in this function)
>./ util/int/m_ioctl.c:94: error: (Each undeclared identifier is reported only once
>./ util/int/m_ioctl.c:94: error: for each function it appears in.)
>./ util/int/m_ioctl.c:98: error: `TIOCSETC' undeclared (first use in this function)
>./ util/int/m_ioctl.c:101: error: `TIOCGETC' undeclared (first use in this function)
>*** Error code 1
>
>Stop.
>make: stopped in /home/lapd/ack/obj/util/int
>
>I'm not sure what to make of this one, as the ioctl stuff is actually declared in
/usr/include/sys/ioctl_compat.h with BSD.  Perhaps this header is not getting picked up?  Where should
it have been included?
>

David Given already anticipated this problem in util/int/sysidf.h:

Index: util/int/sysidf.h
===================================================================
RCS file: /cvsroot/tack/Ack/util/int/sysidf.h,v
retrieving revision 2.5
diff -r2.5 sysidf.h
(Continue reading)

Gregory T. (tim) Kelly | 18 Jul 02:02 2006

Re: ACK compiles on NetBSD-macppc, sort of...

At 7:26 PM -0400 7/17/06, Gregory T. (tim) Kelly wrote:
>make: don't know how to make ./trap_msg. Stop
>
>make: stopped in /home/lapd/ack/obj/util/int
>
>There are no trap_msg files.

Ok, I got around this by running make depend.  This led to another error in compiling, in linking moncalls.o. 
On BSD4_2 and later, ftime(2) is deprecated.  This patch uses gettimeofday(2):

Index: util/int/moncalls.c
===================================================================
RCS file: /cvsroot/tack/Ack/util/int/moncalls.c,v
retrieving revision 2.9
diff -r2.9 moncalls.c
59a60,62
> #ifdef BSD4_2
> extern off_t lseek();
> #else
60a64,65
> #endif
> 
741,744c746,758
< #ifdef        BSD_X                           /* from system.h */
<               ftime(&tb_buf);
< #endif        /* BSD_X */
< #ifdef        SYS_V                           /* from system.h */
---
> #ifdef  BSD_X                           /* from system.h */
> #ifndef BSD4_2  
(Continue reading)

David Given | 18 Jul 15:58 2006

Re: ACK compiles on NetBSD-macppc, sort of...

Gregory T. (tim) Kelly wrote:
[...]
> Posts are coming through now.  I think the problem was my posting so soon after subscribing.  Is it better to
email the list directly (and not cc you) or to cc it (and direct emails to you)?

Mail the list, please...

[...]
> Can llgen be extended to dynamic linking?  Or is it already?  Or am I
> identifying the wrong executable as the linker?  I'm also looking at
> replacing ld(1)  (well, the whole toolchain, to be honest).

Well, llgen doesn't know anything about dynamic linking because, er,
it's not the linker --- it's a parser generator like yacc. The tool you
want is led (Link Editor).  Look at util/led/led.6 for more information.

led only produces ack.out files; it took me a while to figure this out
--- if you want any other format, including a straight memory dump, you
need a converter. mach/arm/cv/cv.c is a ack.out to RiscOS converter ---
given that RiscOS binaries are straight memory dumps, you might be able
to use this if you want to generate simple images...

As for dynamic linking --- don't know. Way beyond my knowledge, I'm
afraid. It *ought* to be possible to take a partially linked image and
generate, say, an ELF executable of the right format so ld.so will load
dynamic libraries, but I don't have enough knowledge right now to make
any useful comments as to how.

Incidentally, your comments about magic characters in awk files ring a
bell, and I'm pretty sure I've fixed that; but it may not be in CVS yet.
(Continue reading)

Gregory T. (tim) Kelly | 18 Jul 17:42 2006

Re: ACK compiles on NetBSD-macppc, sort of...

At 9:58 AM -0400 7/18/06, David Given wrote:
>> Can llgen be extended to dynamic linking?  Or is it already?  Or am I
>> identifying the wrong executable as the linker?  I'm also looking at
>> replacing ld(1)  (well, the whole toolchain, to be honest).
>
>Well, llgen doesn't know anything about dynamic linking because, er,
>it's not the linker --- it's a parser generator like yacc. The tool you
>want is led (Link Editor).  Look at util/led/led.6 for more information.

Yes, I'm still getting up to speed on the particular tools, while I wait for builds to complete.  I'll try to
ask more educated questions :-)

>led only produces ack.out files; it took me a while to figure this out
>--- if you want any other format, including a straight memory dump, you
>need a converter. mach/arm/cv/cv.c is a ack.out to RiscOS converter ---
>given that RiscOS binaries are straight memory dumps, you might be able
>to use this if you want to generate simple images...

I will look more closely at the arm compile.  If there is already some logic in place to handle RISC, getting a
working back-end for PowerPC will be that much easier.

>Incidentally, your comments about magic characters in awk files ring a
>bell, and I'm pretty sure I've fixed that; but it may not be in CVS yet.
>(SF's CVS repository seems to have ground to a halt at the moment.)

Ok.  I think the make depend for util/int is failing on rm_deps:

make: don't know how to make ./trap_msg. Stop

make: stopped in ./obj/util/int
(Continue reading)

Gregory T. (tim) Kelly | 18 Jul 18:10 2006

Re: ACK compiles on NetBSD-macppc, sort of...

At 11:42 AM -0400 7/18/06, Gregory T. (tim) Kelly wrote:
>Ok.  I think the make depend for util/int is failing on rm_deps:
>
>make: don't know how to make ./trap_msg. Stop
>
>make: stopped in ./obj/util/int
>> make depend
>./util/int/M.trap_msg ./etc/traps
>./util/int/M.warn_msg ./doc/int/appA
>rm_deps Makefile >Makefile.new
>rm_deps: not found
>*** Error code 127

I am not sure any of the make depends are working.  I was able to fix this problem by adding a path to rm_deps:

depend: ./warn.h trap_msg warn_msg
        $(UTIL_HOME)/bin/rm_deps Makefile >Makefile.new

This executes but yields lots of error messages.  I ran make depend on util/ack and it initially gives the
same error (rm_deps not found) but about the same kind of errors after I add the path:

SUF: not found
SUF: not found
SUF: not found
SUF: not found
SUF: not found
"/usr/include/sys/cdefs.h", line 245: error: unknown control

The line in cdefs.h that is failing is

(Continue reading)


Gmane