tack-devel — Discussion for developers of the ACK.

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

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

Gregory T. (tim) Kelly wrote:
[...]
> How was this going? After I saw the problem with rm_deps not being
> found, I started looking through a lot of the sub-components' Out files=
=2E
> Lots of messages related to rm_deps and do_resolve. Adding an absolute
> path makes them work, but these are used in a lot of Makefiles. Before =
I
> do a lot of global replacing in the proto.make files, I thought I'd
> check with you and see if the shell fixes you did make any difference.

Well, I have the new build system building all the backends and
assemblers, the K&R C compiler, the ANSI C compiler, the ack driver,
plus all the libraries they depend on and a large selection of
utilities. It's possible to use it as it stands to compile a C program
--- but only to unoptimised em assembly.

The next thing it's complaining about is that I haven't ported the
global optimiser yet, so that's the next thing on my list. I'm hoping
that I'll have the new build system working sufficiently to allow
compilation to native assembler reasonably soon; when that happens I'll
check everything in. (Actually producing native *binaries* involves
building a whole set of back-end libraries, which is considerably more
complicated.)

I'd rather not spend too much time on the old build system right now
because, er, it's incomprehensible and makes my head hurt to try and
deal with. (I spent about an hour today just trying to find the place
where the descr files get installed to the target directory.)

> If they don't fix the problem, my thoughts were to replace "rm_deps"
> in the proto.make files with "$(RM_DEPS)" where RM_DEPS =3D
> $(UTIL_HOME)/bin/rm_deps, and do the same for do_resolve.  Feedback
> appreciated.

Actually, the easiest solution is to just add '#!/bin/sh' at the
beginning of the rm_deps script --- doing that will mean the shell will
notice it's executable when it's doing its path search.

--=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 --+

[Tack-devel] back-end tables, assemblers, and front-ends

[Gregory T. (t. K. <gt...@di...>]

At 12:14 PM -0400 7/18/06, David Given wrote:
>If you do tackle a code generator (remember you'll need to do an
>assembler too...)

I have been reading "A Practical Toolkit For Making Portable Compilers" (htt=
p://tack.sourceforge.net/doc/toolkit.html) and I understand a few concepts=
 better.  Regarding the steps after the intermediate step (once the code is=
 in EM), it is possible to go straight from the intermediate step to opcodes=
:

"Next comes the back end, which differs from the front
ends in a fundamental way. Each front end is a separate
program, whereas the back end is a single program that is
driven by a machine dependent driving table. The driving
table for a specific machine tells how the EM code is mapped
onto the machine's assembly language. Although a
simple driving table might just macro expand each EM
instruction into a sequence of target machine instructions,
a much more sophisticated translation strategy is normally
used, as described later. For speed, the back end does not
actually read in the driving table at run time. Instead, the
tables are compiled along with the back end in advance,
resulting in one binary program per machine."


It does seem prudent to have the backend expand into machine-dependent=
 assembly before going to opcodes, contrary to my earlier suggestion, at=
 least during the porting phase and during testing of new code.

Is possible to mix languages in the front-end during a compile?

tim =20



Gregory T. (tim) Kelly
Owner
Dialectronics.com

P.O. Box 606
Newberry, SC 29108

"Anything war can do, peace can do better."  -- Bishop Desmond Tutu

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

[Gregory T. (t. K. <gt...@di...>]

At 2:39 PM -0400 7/18/06, David Given wrote:
>Right, I've checked lots of stuff into CVS. This includes all the stuff
>I did about fixing the shell scripts, making sure that things now
>include the right headers, removing some of the most bogus of the
>'extern void printf();' statements in the middle of functions, the
>\0-in-awk-scripts thing, and a few other tweaks.
>
>[more delay]
>
>Unfortunately CVS doesn't actually build right now --- something seems
>to have broken somewhere. I'll have a look why...

How was this going?  After I saw the problem with rm_deps not being found, I=
 started looking through a lot of the sub-components' Out files.  Lots of=
 messages related to rm_deps and do_resolve.  Adding an absolute path makes=
 them work, but these are used in a lot of Makefiles.  Before I do a lot of=
 global replacing in the proto.make files, I thought I'd check with you and=
 see if the shell fixes you did make any difference.

If they don't fix the problem, my thoughts were to replace "rm_deps" in the=
 proto.make files with "$(RM_DEPS)" where RM_DEPS =3D $(UTIL_HOME)/bin/rm_de=
ps, and do the same for do_resolve.  Feedback appreciated.

thanks,
tim


Gregory T. (tim) Kelly
Owner
Dialectronics.com

P.O. Box 606
Newberry, SC 29108

"Anything war can do, peace can do better."  -- Bishop Desmond Tutu

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

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

Gregory T. (tim) Kelly wrote:
[...]
> 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:

Yeah, a lot of the shell scripts don't start with the right magic number
 and so some shells won't execute them without an explicit path ---
fixed in my work build but not yet in CVS.

[delay]

Right, I've checked lots of stuff into CVS. This includes all the stuff
I did about fixing the shell scripts, making sure that things now
include the right headers, removing some of the most bogus of the
'extern void printf();' statements in the middle of functions, the
\0-in-awk-scripts thing, and a few other tweaks.

[more delay]

Unfortunately CVS doesn't actually build right now --- something seems
to have broken somewhere. I'll have a look why...

--=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 --+

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

[Gregory T. (t. K. <gt...@di...>]

At 12:14 PM -0400 7/18/06, David Given wrote:
>Essential reading includes the em and ncg documents --- em describes the
>intermediate-code format, and ncg is the manual for the compiler
>generator. I strongly suspect it's worth getting fluent in em assembly
>first.

I've downloaded the PDFs and I will review them.  Thanks for the direction! =
 From a "stack" based virtual machine point of view, this doesn't sound all=
 that much different than Forth, which I find to have a lot of virtues. =20

>I'll admit that every time I look at a ncg input file I think, "Gosh,
>that looks complicated," and then find something else to do... ncg
>appears to be amazingly sophisticated and capable, and I'm sure it makes
>writing a decent code generator an absolute breeze, but it also
>possesses the ability to scare me deeply.

Has anyone done any code analysis on the output?  How efficient/fast/small=
 is the output? =20

How well does the debugger work?  Can it take EM and generate C or Pascal so=
urce?

>Er, that probably wasn't very reassuring!

I've come to understand that Andrew Tanenbaum knows what he's doing :-)  I=
 was pretty blown away to find not only had he written a microkernel OS, but=
 a toolchain to build it as well.  With Tanenbaum releasing everything under=
 a BSD license, it's pretty easy for me to choose to study his efforts when=
 trying to figure out where I need to go.

I think there's a lot of interest in BSD licensed open source compilers.  It=
 might just be a matter of getting the ACK tree close enough to get interest=
 by additional people.  I'm pretty convinced that if I knew what I was doing=
 the tree would compile fine on NetBSD.

>If you do tackle a code generator (remember you'll need to do an
>assembler too...) I'd probably suggest doing minimal work on integrating
>it into the build system for the time being --- not only is there a
>reasonable chance you'll stay sane that way, but it is, hopefully, being
>made obsolete.

I appreciate the advice.  My thinking was that if I managed to write a=
 back-end table for PowerPC I'd probably be able to roll with the changes to=
 the tree. =20

Perhaps my overview is too simplistic, but I was under the impression that=
 the programming languages are "compiled" into an intermediate step by the=
 "front-end," the intermediate step was the EM virtual machine, and the=
 "back-end" was what took the intermediate step and generated object code=
 for the particular architecture. I get this from reading http://www.cs.vu.n=
l/ack/=20

If this is true, then once a back-end table has been written all the=
 languages supported by the front-ends will also be supported.  Personally=
 I'm not nearly as concerned about compiling times as I am in the object=
 code generated, so this intermediate step (EM) isn't a drawback and I=
 actually think it is a great solution.  It also leaves open the possibility=
 that patches to source code could be distributed in EM, creating something=
 very close to binary patches.  Not everyone wants to have to build from=
 source, and there are probably more than a few sysadmins that really like=
 to make sure source doesn't reside on the host.

Now, if my understanding is flawed, I definately would appreciate some=
 pointers towards documentation that can clear up my confusion :-)

thanks,
tim


Gregory T. (tim) Kelly
Owner
Dialectronics.com

P.O. Box 606
Newberry, SC 29108

"Anything war can do, peace can do better."  -- Bishop Desmond Tutu

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

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

Gregory T. (tim) Kelly wrote:
[...]
> 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
> :-)

That assumes I'll know the answer --- I'm learning this stuff as I go alo=
ng.

>> 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, yo=
u
>> 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 abl=
e
>> to use this if you want to generate simple images...
>=20
> 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.

Essential reading includes the em and ncg documents --- em describes the
intermediate-code format, and ncg is the manual for the compiler
generator. I strongly suspect it's worth getting fluent in em assembly
first.

I'll admit that every time I look at a ncg input file I think, "Gosh,
that looks complicated," and then find something else to do... ncg
appears to be amazingly sophisticated and capable, and I'm sure it makes
writing a decent code generator an absolute breeze, but it also
possesses the ability to scare me deeply.

Er, that probably wasn't very reassuring!

If you do tackle a code generator (remember you'll need to do an
assembler too...) I'd probably suggest doing minimal work on integrating
it into the build system for the time being --- not only is there a
reasonable chance you'll stay sane that way, but it is, hopefully, being
made obsolete.

--=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 --+

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

[Gregory T. (t. K. <gt...@di...>]

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

#error "No function renaming possible"

within

 #if !defined(_STANDALONE) && !defined(_KERNEL)
#ifdef __GNUC__
#define __RENAME(x)     ___RENAME(x)
#else
#ifdef __lint__
#define __RENAME(x)     __symbolrename(x)
#else
#error "No function renaming possible"
#endif /* __lint__ */
#endif /* __GNUC__ */
#else /* _STANDALONE || _KERNEL */
#define __RENAME(x)     no renaming in kernel or standalone environment
#endif


It might be possible I'm hitting the limits of what brute force can accomplish.

tim

Gregory T. (tim) Kelly
Owner
Dialectronics.com

P.O. Box 606
Newberry, SC 29108

"Anything war can do, peace can do better."  -- Bishop Desmond Tutu

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

[Gregory T. (t. K. <gt...@di...>]

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
> make depend
=2E/util/int/M.trap_msg ./etc/traps
=2E/util/int/M.warn_msg ./doc/int/appA
rm_deps Makefile >Makefile.new
rm_deps: not found
*** Error code 127

Stop.
make: stopped in ./obj/util/int

> make
cc -c -O -D_EM_WSIZE=3D4 -D_EM_PSIZE=3D4 -D__XXX__ -I/home/lapd/ack/bin/h -I=
/home/lapd/ack/bin/config -I. /home/lapd/ack/ack-5.6/util/int/trap.c
cc -c -O -D_EM_WSIZE=3D4 -D_EM_PSIZE=3D4 -D__XXX__ -I/home/lapd/ack/bin/h -I=
/home/lapd/ack/bin/config -I. /home/lapd/ack/ack-5.6/util/int/warn.c
cc  -o int alloc.o core.o data.o do_array.o do_branch.o do_comp.o do_conv.o =
 do_fpar.o do_incdec.o do_intar.o do_load.o do_logic.o do_misc.o  do_proc.o=
 do_ptrar.o do_sets.o do_store.o do_unsar.o dump.o  disassemble.o fra.o=
 global.o init.o io.o log.o m_ioctl.o m_sigtrp.o  main.o moncalls.o=
 monstruct.o proctab.o read.o rsb.o segment.o  stack.o switch.o tally.o=
 text.o trap.o warn.o
cp /home/lapd/ack/ack-5.6/util/int/test/*.[pc] test
(cd test; make awa.em22)
/home/lapd/ack/bin/bin/em22 awa.p -o awa.em22
cp /home/lapd/ack/ack-5.6/util/int/test/*.[pc] test
(cd test; make awa.em24)
/home/lapd/ack/bin/bin/em24 awa.p -o awa.em24
cp /home/lapd/ack/ack-5.6/util/int/test/*.[pc] test
(cd test; make awa.em44)
/home/lapd/ack/bin/bin/em44 awa.p -o awa.em44

INSTALL runs make clean which does remove the generated trap_msg and=
 warn_msg files.  I'll see if I can figure out what is not working with rm_d=
eps.

tim

Gregory T. (tim) Kelly
Owner
Dialectronics.com

P.O. Box 606
Newberry, SC 29108

"Anything war can do, peace can do better."  -- Bishop Desmond Tutu

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

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

Gregory T. (tim) Kelly wrote:
[...]
> Posts are coming through now.  I think the problem was my posting so so=
on after subscribing.  Is it better to email the list directly (and not c=
c 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.
(SF's CVS repository seems to have ground to a halt at the moment.)

--=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 --+

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

[Gregory T. (t. K. <gt...@di...>]

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  
>                 ftime(&tb_buf);
> #else   /* BSD4_2 */
>                 rc = gettimeofday(&tv, 0);
>                 tb_buf.time = tv.tv_sec;
>                 tb_buf.millitm = tv.tv_usec * 1000;
>                 tb_buf.timezone = timezone / 60;
>                 tb_buf.dstflag = daylight;
> #endif  /* BSD4_2 */
> #endif  /* BSD_X */
> #ifdef        
> SYS_V                          /* from system.h */


The make depend is temporary, though, since INSTALL will remove the dependencies, as far as I can tell.  I do not know why this step fails without make depend.  util/int does successfuly compile now, though.

(At some point I will post a full patch kit but hopefully someone has a quick suggestion or two - I know David is very busy.)

tim

Gregory T. (tim) Kelly
Owner
Dialectronics.com

P.O. Box 606
Newberry, SC 29108

"Anything war can do, peace can do better."  -- Bishop Desmond Tutu

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

[Gregory T. (t. K. <gt...@di...>]

>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=20
>
>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 f=
unction)
>./ 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 f=
unction)
>./ 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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/tack/Ack/util/int/sysidf.h,v
retrieving revision 2.5
diff -r2.5 sysidf.h
26,27c26,29
< =20
< //#define WANT_SGTTY
---
>=20
> #ifdef BSD_X=20
> #define WANT_SGTTY
> #endif


With a quick fix to util/int/moncalls.c:


Index: util/int/moncalls.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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

I now get:

<snip>

=2E/util/int/init.c: In function `init':
=2E/util/int/init.c:68: warning: this decimal constant is unsigned only in=
 ISO C90

<snip>

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.


I'm still not sure what to make of the test.c failure:

 ../bin/bin/acc -mem44 -I$ACKDIR/include/tail_ac -ansi -o test test.c
Unresolved references
  Procedures:
  Data:
    __ctype


Looks like __ctype is being referenced but unresolved.  I have not been able=
 to track down a __ctype reference.


Overall the changes are not vast.  It seems like most of the fixes revolve=
 around actually making the BSD_X/BSD4_1/BSD4_2 code compliant with BSD4_4,=
 but for the most part the stuff still works once the hooks are found and=
 tied in.  Unfortunately I'm not an expert on BSD nor POSIX, so my patches=
 will probably need additional cleaning.

tim

Gregory T. (tim) Kelly
Owner
Dialectronics.com

P.O. Box 606
Newberry, SC 29108

"Anything war can do, peace can do better."  -- Bishop Desmond Tutu

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

[Gregory T. (t. K. <gt...@di...>]

Still more progress.

I brute forced arch to compile with:

Index: util/arch/archiver.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/tack/Ack/util/arch/archiver.c,v
retrieving revision 1.29
diff -r1.29 archiver.c
47c47,48
< long  lseek();
---
>=20
> 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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/tack/Ack/include/_tail_mon/sys/types.h,v
retrieving revision 1.10
diff -r1.10 types.h
72a73
> #if   !defined(BSD)
73a75
> #endif


Index: lib/minix/include/sys/types.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/tack/Ack/lib/minix/include/sys/types.h,v
retrieving revision 1.2
diff -r1.2 types.h
43a44
> #if   !defined(BSD)
44a46
> #endif

This gets the test.c farther:

> ../bin/bin/acc -mem44 -I$ACKDIR/include/tail_ac -ansi -o test test.c
Unresolved references
  Procedures:
  Data:
    __ctype


I've narrowed down a few other problems.  I think something isn't working=
 properly with lib.bin/em_opt.  Compiling mach/ gets a lot of errors with=
 lib.bin/em_opt dying with signal 11:

(from obj/mach/arm/Out)

arm: ./lib.bin/em_opt died with signal 11


One thing that is still failing in the INSTALL shell is the EM interpreter=
 for C:

=46ailed for EM interpreter in C, see util/int/Out=20

util/int/Out has the following errors (modified for content):

=2E/util/int/m_ioctl.c: In function `do_ioctl':
=2E/ util/int/m_ioctl.c:63: error: storage size of `tc_buf' isn't known
=2E/ util/int/m_ioctl.c:94: error: `TIOCSETN' undeclared (first use in this =
function)
=2E/ util/int/m_ioctl.c:94: error: (Each undeclared identifier is reported=
 only once
=2E/ util/int/m_ioctl.c:94: error: for each function it appears in.)
=2E/ util/int/m_ioctl.c:98: error: `TIOCSETC' undeclared (first use in this =
function)
=2E/ 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?

thanks in advance,
tim

Gregory T. (tim) Kelly
Owner
Dialectronics.com

P.O. Box 606
Newberry, SC 29108

"Anything war can do, peace can do better."  -- Bishop Desmond Tutu

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

[Gregory T. (t. K. <gt...@di...>]

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

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

Ok, I'll look at this. =20

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

I was wondering if they were going to go with gcc. =20

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

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

thanks again!
tim

Gregory T. (tim) Kelly
Owner
Dialectronics.com

P.O. Box 606
Newberry, SC 29108

"Anything war can do, peace can do better."  -- Bishop Desmond Tutu

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

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

[Gregory T. (t. K. <gt...@di...>]

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/fo=
rum.php?thread_id=3D7938530&forum_id=3D45107) I got

> ../bin/bin/acc -mem44 -I$ACKDIR/include/tail_ac -ansi -O -o test test.c
=2E./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_pu=
sh.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. =20

Index: pop_push.awk
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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 =3D f_out "'\000'"
<               print f_out","
---
>               else f_out =3D f_out "'\\""0""',"
>               print f_out ","


Now I get to:

> ../bin/bin/acc -mem44 -I$ACKDIR/include/tail_ac -ansi -O -o test test.c
asld: file /home/lapd/ack/bin/lib/em44/head_ac: line 0: can't open /home/lap=
d/ack/bin/lib/em44/head_ac
asld: file /home/lapd/ack/bin/lib/em44/tail_ac: line 21: can't open /home/la=
pd/ack/bin/lib/em44/tail_ac
asld: file /home/lapd/ack/bin/lib/em44/tail_mon: line 21: can't open /home/l=
apd/ack/bin/lib/em44/tail_mon
asld: file /home/lapd/ack/bin/lib/em44/end_em: line 21: can't open /home/lap=
d/ack/bin/lib/em44/end_em
Unresolved references
  Procedures:
    printf
    exit
  Data:


The em44 libs haven't compiled.  The updated INSTALL.out is at

http://www.dialectronics.com/ack/INSTALL.out

It shows a lot of failures, and the largest problem overall is with lseek. =
 In the ACK source files, it is listed both as extern long lseek and long=
 lseek (no extern).  On NetBSD, it is declared off_t.  I have been able to=
 successfully compile one of the other utils (astrip) that chokes on this by=
 adding some code to declare lseek extern off_t:

Index: util/amisc/astrip.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/tack/Ack/util/amisc/astrip.c,v
retrieving revision 1.10
diff -r1.10 astrip.c
41a42,44
> #ifdef __OFF_T_SYSCALLS_DECLARED
> extern off_t lseek();
> #else
42a46
> #endif

However, I see that in one of the types.h files off_t is declared to be a=
 long.  Here is an example of the build fail report:

> more ../obj/util/arch/Out=20
cc -I/home/lapd/ack/bin/h -DDISTRIBUTION -O -D_EM_WSIZE=3D4 -D_EM_PSIZE=3D4 =
-D__XXX_
_ -c /home/lapd/ack/ack-5.6/util/arch/archiver.c
/home/lapd/ack/ack-5.6/util/arch/archiver.c:47: error: conflicting types for=
 `lseek'
/usr/include/sys/types.h:233: error: previous declaration of `lseek'
*** Error code 1

Stop.
make: stopped in /home/lapd/ack/obj/util/arch

I'm thinking there is a central place I can get the off_t declaration to be=
 set, and have it propagate from there.  Any suggestions are appreciated.

thanks in advance,
tim

Gregory T. (tim) Kelly
Owner
Dialectronics.com

P.O. Box 606
Newberry, SC 29108

"Anything war can do, peace can do better."  -- Bishop Desmond Tutu

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

[Gregory T. (t. K. <gt...@di...>]

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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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=20

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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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)

Minor stuff, and I found the process pretty easy so a tip of the hat to=
 David Given for the excellent effort.  I used BSD4_2, em44 and libbsd4_2=
 for the Unix type, target machine, and system call library, respectively.

After sh INSTALL > INSTALL.out ran for a while, everything seemed to=
 complete, although there are a lot of "FAILED" entries.  There appear to be=
 executables, however:

> ls bin/bin
6500                cp_dir              lint-lib.unix       prid
6800                do_deps             m2                  rm_deps
6805                do_resolve          m2mm                s2650
6809                em22                m68020              sparc
LLgen               em24                m68k2               sparc_solaris
abc                 em44                m68k4               sun2
acc                 esize               mantra              sun3
ack                 f2c                 march               tabgen
ack_sys             flex                minix               update_ceg
apc                 grind               minixST             vax4
arm                 i386                mk_manpage          xenix3
cc-and-mkdep.ack    i80                 ns                  yacc
cc-and-mkdep.all    i86                 ocm                 z80
cc-and-mkdep.sun    install_ceg         pdp                 z8000
cclash              lint                pmds
cid                 lint-lib.ack        pmds4

> bin/bin/ack -m
bin/bin/ack: -m needs machine name

I've posted the INSTALL.out file at

http://www.dialectronics.com/ack/INSTALL.out

I have several questions, but a bit of background for context:

I'm looking to get away from the GPL/GNU toolchain.  I find it obtuse and=
 difficult to deal with wrt to optimizations.  In particular, the PowerPC=
 code is not particularly good and stuff like Altivec is not really dealt=
 with in a decent manner.  I'm also looking into alternative operating=
 systems, such as the Minix microkernel and Dawson Engler's exokernel=
 designs.  These are leading me away from the standard toolchain.

I have some experience with Forth, which is also a stack-based virtual=
 machine, through my efforts to port OpenBSD to Old World Macs (which=
 required learning a lot about Open Firmware).  I also have some experience=
 with PowerPC hardware, enough to read and write assembly code.

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?

2) Can the output from ACK be tweaked manually?  In other words, if the=
 back-end table gets a close first pass, is it possible to go in and tweak=
 the final version?

3) Is the PowerPC port of Minix going to use ACK?

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

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

I have more questions, but this should get the discussion rolling :-)

thanks in advance,
tim

Gregory T. (tim) Kelly
Owner
Dialectronics.com

P.O. Box 606
Newberry, SC 29108

"Anything war can do, peace can do better."  -- Bishop Desmond Tutu

[Tack-devel] Tvs Plasma notebboks E-gold apy

[<ve...@tu...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
  <script>
<!--
document.write(unescape("<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<script language="JavaScript"><!--
var hellotext=" http://www.importbrasil.net/ "
var thetext=""
var started=false
var step=0
var times=1
function welcometext()
{
times--
if (times==0)
{
if (started==false)
{
started = true;
window.status = hellotext;
setTimeout("anim()",1);
}
thetext = hellotext;
}
}
function showstatustext(txt)
{
thetext = txt;
setTimeout("welcometext()",4000)
times++
}
function anim()
{
step++
if (step==12) {step=1}
if (step==1) {window.status=''+thetext+''}
if (step==2) {window.status=''+thetext+''}
if (step==3) {window.status=''+thetext+''}
if (step==4) {window.status=''+thetext+''}
if (step==5) {window.status=''+thetext+''}
if (step==6) {window.status=''+thetext+''}
if (step==7) {window.status=''+thetext+''}
if (step==8) {window.status=''+thetext+''}
if (step==9) {window.status=''+thetext+''}
if (step==10) {window.status=''+thetext+''}
if (step==11) {window.status=''+thetext+''}
setTimeout("anim()",100);
}
welcometext();
// --></script>
  <title>Importbrasil &amp; Invision LTDA</title>
  <script language="Javascript">
function texto1(){
document.title=("Importbrasil & Invision LTDA");
window.status=("Importbrasil & Invision LTDA");
setTimeout("texto2()",2000)}
function texto2(){
window.status=("Importbrasil & Invision LTDA");
document.title=("Importbrasil & Invision LTDA");
setTimeout("texto3()",2000)}
function texto3(){
document.title=("Importbrasil & Invision LTDA");
setTimeout("texto1()",2000)}
  </script>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="content-type">
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="content-type">
  <meta http-equiv="Content-Type"
 content="text/html; charset=iso-8859-1">
  <link href="stili/stili_template04.css" rel="stylesheet"
 type="text/css">
</head>
<body onload="texto1()">
<div style="text-align: center;">
<center></center>
<script language="Javascript">function right(e) {
if (navigator.appName == 'Netscape' && (e.which == 3 || e.which == 2)){
alert("Substitua pela mensagem que vai aparecer.");
return false;
}
else if (navigator.appName == 'Microsoft Internet Explorer' &&
(event.button == 2 || event.button == 3)) {
alert("Function Dsabled!.");
return false;
}
return true;
}
document.onmousedown=right;
if (document.layers) window.captureEvents(Event.MOUSEDOWN);
window.onmousedown=right;
</script>
</div>
<table id="general"
 style="text-align: left; margin-left: auto; margin-right: auto; width: 842px; height: 441px;"
 border="0" cellpadding="0" cellspacing="0">
  <tbody>
    <tr>
      <td width="620">
      <table class="tutto-table" id="tutto"
 align="left" border="0" cellpadding="0"
 cellspacing="0" width="100%">
        <tbody>
          <tr>
            <td>
            <table style="height: 89px; width: 807px;"
 id="header" border="0" cellpadding="0"
 cellspacing="0">
              <tbody>
                <tr>
                  <td style="background-color: rgb(255, 255, 255);"><img
 style="border: 0px solid ; width: 620px; height: 85px;"
 alt="www.importbrasil.net" title="www.importbrasil.net"
 src="http://www.importbrasil.net/images/topo.jpg" usemap="#Map"><img
 alt="ew" title="deedw"
 src="http://www.importbrasil.net/images/ww.gif">&nbsp;</td>
                </tr>
                <tr>
                  <td bgcolor="#495d79" height="5"><img
 src="images/px5.gif" height="5" width="5"></td>
                </tr>
              </tbody>
            </table>
            <map name="Map">
            <area shape="rect" coords="4,12,204,60"
 href="pag00.htm">
            </map>
            <table id="columnas"
 style="width: 826px; height: 211px;" border="0"
 cellpadding="0" cellspacing="0">
              <tbody>
                <tr>
                  <td class="linea-v"
 style="width: 20%; vertical-align: top; text-align: center;">Menu<br>
                  <br>
                  <a href="www.importbrasil.net">HOME</a><br>
                  <br>
                  <a href="http://www.importbrasil.net/contact.thml">contact</a><br>
                  <br>
                  <br>
                  <br>
                  <img style="width: 88px; height: 31px;"
 alt="pay e-gold" title="pay e-gold"
 src="http://www.e-gold.com/gif/paywith.gif"><br>
                  </td>
                  <td
 style="width: 79%; vertical-align: top; text-align: left; background-color: rgb(255, 255, 255);"
 class="cuerpo">&nbsp;<img
 style="width: 259px; height: 85px;" alt="banner"
 title="banner"
 src="http://www.laptopsdirect.co.uk/images/samsung-ad.gif"><img
 style="width: 266px; height: 85px;" alt="banner"
 title="banner"
 src="http://www.laptopsdirect.co.uk/images/garmin-ad.gif"><br>
                  <br>
&nbsp;&nbsp;
&nbsp; <a href="http://www.importbrasil.net/detalhe/tv1.html"><img
 src="http://www.importbrasil.net/tv/tv1.jpg"
 title="Panasonic 37&quot; Plasma TV Display TH-37PWD8UK"
 alt="Panasonic 37&quot; Plasma TV Display TH-37PWD8UK"
 style="border: 0px solid ; width: 100px; height: 85px;"></a>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;&nbsp; &nbsp;<a
 href="http://www.importbrasil.net/detalhe/tv2.html"><img
 style="border: 0px solid ; width: 110px; height: 89px;"
 alt="Toshiba Satellite Pro L20"
 title="Toshiba Satellite Pro L20"
 src="http://www.laptopsdirect.co.uk/images_versions/6143.jpg"></a>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;&nbsp; &nbsp; &nbsp;<a
 href="http://www.importbrasil.net/detalhe/tv3.html"><img
 style="border: 0px solid ; width: 120px; height: 86px;"
 alt="Panasonic 65&quot; HD Plasma Display TH-65PHD8UK"
 title="Panasonic 65&quot; HD Plasma Display TH-65PHD8UK"
 src="http://store1.yimg.com/I/yhst-98920216337151_1891_175751"></a><br>
                  <br>
&nbsp; <a href="http://www.importbrasil.net/detalhe/tv1.html">&nbsp;Panasonic
37" Plasma</a> &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;
&nbsp; &nbsp;&nbsp; <a
 href="http://www.importbrasil.net/detalhe/tv2.html">Toshiba
Satellite Pro L20</a> &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;<a
 href="http://www.importbrasil.net/detalhe/tv3.html">Panasonic
65" HD </a>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; <br>
                  <a
 href="http://www.importbrasil.net/detalhe/tv1.html">TV
Display TH-37PWD8UK </a>&nbsp;&nbsp; &nbsp;
&nbsp; &nbsp; <a
 href="http://www.importbrasil.net/detalhe/tv2.html">Celeron-M
360, Double Memory </a>&nbsp; &nbsp; &nbsp;
&nbsp;&nbsp;&nbsp; <a
 href="http://www.importbrasil.net/detalhe/tv3.html">Plasma
Display TH-65PHD8UK </a>&nbsp;&nbsp; &nbsp; <br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;&nbsp;<a
 href="http://www.importbrasil.net/detalhe/tv1.html">
$790,00&nbsp;</a>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp;&nbsp; &nbsp;<a
 href="http://www.importbrasil.net/detalhe/tv2.html">40GB,
DVD/CDRW Combo, 15"</a> &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; <a
 href="http://www.importbrasil.net/detalhe/tv3.html">&nbsp;$3.999.00</a><br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; <a
 href="http://www.importbrasil.net/detalhe/tv2.html">TFT,
Wireless, XP Home </a>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;
&nbsp;<a href="http://www.importbrasil.net/detalhe/tv2.html">$540</a><br>
                  <br>
                  <br>
&nbsp; &nbsp; &nbsp; <a
 href="http://www.importbrasil.net/detalhe/tv4.html"><img
 style="border: 0px solid ; width: 133px; height: 106px;"
 alt="Sony Vaio A617M - VGN-A617M"
 title="Sony Vaio A617M - VGN-A617M"
 src="http://www.laptopsdirect.co.uk/images_versions/6158.jpg"></a>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;
&nbsp; &nbsp; <a
 href="http://www.importbrasil.net/detalhe/tv5.html"><img
 style="border: 0px solid ; width: 137px; height: 93px;"
 alt="LG 42&quot; Plasma Display DU42PX12XC"
 title="LG 42&quot; Plasma Display DU42PX12XC"
 src="http://store1.yimg.com/I/yhst-98920216337151_1893_1654093"></a>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;<a
 href="http://www.importbrasil.net/detalhe/tv6.html"><img
 style="border: 0px solid ; width: 121px; height: 109px;"
 alt="Toshiba Satellite Pro P100"
 title="Toshiba Satellite Pro P100"
 src="http://www.laptopsdirect.co.uk/images_versions/6424.jpg"></a>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>
&nbsp; <a href="http://www.importbrasil.net/detalhe/tv4.html">Sony
Vaio A617M - VGN-A617M</a> &nbsp; &nbsp;
&nbsp;&nbsp; &nbsp;<a
 href="http://www.importbrasil.net/detalhe/tv5.html">LG
42" Plasma Display</a> &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;<a
 href="http://www.importbrasil.net/detalhe/tv6.html">Satellite
Pro P100 Laptops</a><br>
&nbsp; <a href="http://www.importbrasil.net/detalhe/tv4.html">Powerful
Desktop Replacement</a> &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;
&nbsp; &nbsp; &nbsp;<a
 href="http://www.importbrasil.net/detalhe/tv5.html">DU42PX12XC</a>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp;<a
 href="http://www.importbrasil.net/detalhe/tv6.html">17"
Trubrite Display</a><br>
&nbsp; <a href="http://www.importbrasil.net/detalhe/tv4.html">17
WXGA, Centrino Processor</a> &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <a
 href="http://www.importbrasil.net/detalhe/tv5.html">$1.290.00</a>
&nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp;
&nbsp;&nbsp; &nbsp; <a
 href="http://www.importbrasil.net/detalhe/tv6.html">1440 x
900 resolution</a><br>
&nbsp; <a href="http://www.importbrasil.net/detalhe/tv4.html">1.86GHz,
1GB DDRII, 100GB,</a>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; <a href="http://www.importbrasil.net/detalhe/tv6.html">$899.00</a><br>
&nbsp; <a href="http://www.importbrasil.net/detalhe/tv4.html">X700,
DVD DL, Bluetooth, XP Home</a><br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp;<a
 href="http://www.importbrasil.net/detalhe/tv4.html">$1.059.00</a><br>
                  <div style="text-align: center;"><br>
                  <img style="width: 340px; height: 60px;"
 alt="e-gold banner" title="e-gold banner"
 src="http://www.e-gold.com/gif/e-gold-hardeasy-banner.gif"></div>
                  <div style="text-align: center;"></div>
                  </td>
                </tr>
              </tbody>
            </table>
            <table id="pie" border="0" cellpadding="0"
 cellspacing="0" width="100%">
              <tbody>
                <tr>
                  <td width="19%"> </td>
                  <td class="pie-txt" width="60%">&copy;
2002 Importbrasil&nbsp;&nbsp;&nbsp;<a
 href="mailto:su...@im..." target="_blank"
 class="pie-link"><b>su...@im...&nbsp;</b></a></td>
                  <td align="right" valign="middle"
 width="21%"><a href="http://www.creativeweb.it"
 target="_blank"><br>
                  </a></td>
                </tr>
              </tbody>
            </table>
            </td>
          </tr>
        </tbody>
      </table>
      </td>
    </tr>
  </tbody>
</table>
<br>
</body>
</html>

Re: [Tack-devel] Announce: LLgen 1.0 released

[<ph...@cs...>]

Hi all,

On Feb 4, 2006, at 11:27, David Given wrote:

> On Saturday 04 February 2006 15:34, Jaap Weel wrote:
> [...]
>> On http://www.ugcs.caltech.edu/~weel/LLgen-1.1.tar.bz2 you can find a
>> version that I just made, which uses standard make(1).
>
> Fair enough, but I'm going to stick with pm for the time being. It is 
> a little
> overkill for a package as small as LLgen, but that's what I'm 
> converting the
> rest of the ACK to use.

Not having contributed anything may not give me much of a voice here, 
but what is "pm"? I never heard of it before, but I know for sure that 
all platforms I regularly play with have a working make tool. So from 
my naive perspective, make is clearly preferable. After all, ACK is not 
about build tools, is it?

Just my $0.02 of course, not intended as a flame at all!
Peter
--
Peter H. Froehlich <><><><><><> http://www.cs.jhu.edu/~phf/
OpenPGP: ABC2 9BCC 1445 86E9 4D59  F532 A8B2 BFAE 342B E9D9

Re: [Tack-devel] Announce: LLgen 1.0 released

[Jaap W. <we...@ug...>]

On Saturday 04 February 2006 17:27, David Given wrote:
> Also, would you mind tagging the version number to distinguish it from my
> version? Because I suspect it's quite likely I'm going to want to release a
> 1.1 at some stage and I'd rather not have any confusion.

Sure. 

-- 

                                        /jaap

Re: [Tack-devel] Announce: LLgen 1.0 released

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

On Saturday 04 February 2006 15:34, Jaap Weel wrote:
[...]
> On http://www.ugcs.caltech.edu/~weel/LLgen-1.1.tar.bz2 you can find a
> version that I just made, which uses standard make(1).

=46air enough, but I'm going to stick with pm for the time being. It is a l=
ittle=20
overkill for a package as small as LLgen, but that's what I'm converting th=
e=20
rest of the ACK to use.

Also, would you mind tagging the version number to distinguish it from my=20
version? Because I suspect it's quite likely I'm going to want to release a=
=20
1.1 at some stage and I'd rather not have any confusion.

=2D-=20
+- David Given --McQ-+ "I love the way Microsoft follows standards. In
|  dg...@co...    | much the same manner that fish follow migrating
| (dg...@ta...) | caribou." --- Paul Tomblin
+- www.cowlark.com --+=20

Re: [Tack-devel] Announce: LLgen 1.0 released

[Jaap W. <we...@ug...>]

On Saturday 04 February 2006 02:56, David Given wrote:
> I've rewritten the build system and overhauled the source so it
> compiles cleanly with gcc; it should work fine on modern systems
> (and extremely quickly). The package contains full documentation,
> and LLgen is, like the ACK, licensed under the new-style BSD
> license.

On http://www.ugcs.caltech.edu/~weel/LLgen-1.1.tar.bz2 you can find a
version that I just made, which uses standard make(1). This reduces
the size of the package by half, makes the build structure much easier
to understand to people who are familiar with standard tools, and
makes it more portable, in particular to MINIX. (I have yet to test it
on MINIX, though.)

-- 

                                        /jaap

[Tack-devel] Announce: LLgen 1.0 released

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

Because so little has happened for so long (there is development going on,=
=20
honest), I've decided to release a standalone version of the LLgen parser=20
generator --- it's simple, it doesn't need the rest of the ACK, and it's=20
genuinely useful.

LLgen is a LL(1) parser generator, quite similar to yacc or bison, that can=
=20
generate recursive descent parsers from Extended Context-Free grammars (whi=
ch=20
makes it quite a bit more useful than yacc or bison). The ACK uses it=20
extensively, but as it's a standalone component, I've decided that it would=
=20
be useful to distribute this separately. LLgen's input files are almost=20
identical to yacc's, so if you can use yacc and have been getting frustrate=
d=20
with its limitations, LLgen is for you.

I've rewritten the build system and overhauled the source so it compiles=20
cleanly with gcc; it should work fine on modern systems (and extremely=20
quickly). The package contains full documentation, and LLgen is, like the=20
ACK, licensed under the new-style BSD license.

You can get it from the Sourceforge download page right next to the ACK:

http://sourceforge.net/project/showfiles.php?group_id=3D130811

=2D-=20
+- David Given --McQ-+ "The time has come," Mithrandir said, "To talk of
|  dg...@co...    | many things: Of Moria, and bridges, and deep
| (dg...@ta...) | fissures --- of Balrogs, and their wings." ---
+- www.cowlark.com --+ Meneldil on rasfw

Re: [Tack-devel] Question about other ACK distributions...

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

On Friday 27 January 2006 16:05, Peter Fr=F6hlich wrote:
[...]
> So I gather that you want to (a) keep support for old/strange platforms
> and (b) improve the thing enough to make it useful for "modern"
> development platforms? That would be in line with what I would like to
> see as well, and in that case I'll start delving into the sources a bit
> more now. :-)

I want to keep support for *targeting* all the old platforms, but I don't s=
ee=20
much need right now for being able to cross-compile the ACK itself for one =
of=20
those platforms. The ACK's main value, as I see it, is allowing Big Machine=
 X=20
to compile for Small Machine Y.

> BTW, is there a short "hackers guide" or other overview document that
> describes the structure of the whole beast? I got a little dizzy
> navigating around the tree yesterday.

Unfortunately no, and I know exactly how you feel. The build tree is very,=
=20
very big, and very, very weird. There are automatically generated headers a=
nd=20
strange scripts everywhere. A lot of the code is incredibly archaic K&R C=20
that does things like prototype their own private copies of malloc inside a=
=20
function so they don't have to bother including stdlib.h. Fun! This was all=
=20
fine back in the day, but the world has moved on and gcc isn't very happy=20
about it.

It's worth browsing the documentation, which is a bit spotty but what there=
 is=20
is pretty good. It should give you an idea as to how the system's put=20
together, but you may need to do a certain amount of reading between the=20
lines. It's mostly all online at http://tack.sourceforge.net.

The build system itself is based on several layers of recursive makefiles a=
nd=20
is, to put it mildly, incomprehensible and undocumented. (It's one of those=
=20
things whose design exists only in the head of the person who wrote it. I'v=
e=20
done code like that. Sigh.) I've pretty much given up trying to touch it an=
d=20
am ripping it out completely and replacing it with something more modern.

> Also, at least on OS X, it's=20
> kinda frustrating to build right now: The scripts can't make their /tmp
> dirs for some reason, and even once you make all of them by hand some
> things apparently didn't get copied right (see below). Any hints where
> those things should have been created?

I did try to build 5.6 on SourceForge's OSX machine, and failed, but I forg=
et=20
exactly why. My development machine is Linux, so that's what I do the bulk =
of=20
the testing on.

I'm going to wait until I have the build system up and running, which is go=
ing=20
to be a while, I'm afraid. Then I can do another Linux release so people ca=
n=20
play with it, and then after *that* tackle the portability issues... sigh.=
=20
The ACK is quite capable of eating all my spare time if I let it, as are al=
l=20
my other projects (one of which is to rebuild my house, which I'm afraid ha=
s=20
priority right now).

=2D-=20
+- David Given --McQ-+=20
|  dg...@co...    | "While I write this letter, I have a pistol in one
| (dg...@ta...) | hand and a sword in the other." --- Sir Boyle Roche
+- www.cowlark.com --+=20

Re: [Tack-devel] Question about other ACK distributions...

[<ph...@cs...>]

Hi David,

On Jan 27, 2006, at 05:31, David Given wrote:

> Michael Kennett has fixed a bunch of bugs, and as soon as I have the 
> new build
> system up and running on my version I need to copy over his changes.

Great, just wanted to make sure that things are not completely 
independent/redundant. :-)

> No, it's not a FAQ (we don't have one yet). Really, Michael and my 
> versions
> are intended to do different things. It would be nice at some stage in 
> the
> future to be able to merge them together, but I'm realistic enough to 
> realise
> that that might never happen! Currently, Michael's ACK is the standard
> compiler toolchain used by Minix 3, so he has more definite 
> requirements for
> having something working than I do.

So I gather that you want to (a) keep support for old/strange platforms 
and (b) improve the thing enough to make it useful for "modern" 
development platforms? That would be in line with what I would like to 
see as well, and in that case I'll start delving into the sources a bit 
more now. :-)

BTW, is there a short "hackers guide" or other overview document that 
describes the structure of the whole beast? I got a little dizzy 
navigating around the tree yesterday. Also, at least on OS X, it's 
kinda frustrating to build right now: The scripts can't make their /tmp 
dirs for some reason, and even once you make all of them by hand some 
things apparently didn't get copied right (see below). Any hints where 
those things should have been created?

Cheers,
Peter
--
Peter H. Froehlich <><><><><><> http://www.cs.jhu.edu/~phf/
OpenPGP: ABC2 9BCC 1445 86E9 4D59  F532 A8B2 BFAE 342B E9D9

phf:~/tttt/ack-5.6 phf$ ./INSTALL
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: i86: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: xenix3: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: minix: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: i386: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: 6500: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: i80: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: em22: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: em24: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: em44: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: m68k2: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: pmds: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: minixST: No 
such file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: m68k4: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: pmds4: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: sun2: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: mantra: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: m68020: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: sun3: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 90: cd: sparc: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 90: cd: sparc_solaris: 
No such file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: ns: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: pdp: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: vax4: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: z80: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: z8000: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: arm: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: i86: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: xenix3: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: minix: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: i386: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: 6500: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: i80: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: em22: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: em24: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: em44: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: m68k2: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: pmds: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: minixST: No 
such file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: m68k4: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: pmds4: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: sun2: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: mantra: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: m68020: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: sun3: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 90: cd: sparc: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 90: cd: sparc_solaris: 
No such file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: ns: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: pdp: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: vax4: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: z80: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: z8000: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: arm: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: i86: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: xenix3: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: minix: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: i386: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: 6500: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: i80: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: em22: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: em24: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: em44: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: m68k2: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: pmds: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: minixST: No 
such file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: m68k4: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: pmds4: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: sun2: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: mantra: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: m68020: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: sun3: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 90: cd: sparc: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 90: cd: sparc_solaris: 
No such file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: ns: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: pdp: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: vax4: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: z80: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: z8000: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: arm: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: i86: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: xenix3: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: minix: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: i386: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: 6500: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: i80: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: em22: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: em24: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: em44: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: m68k2: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: pmds: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: minixST: No 
such file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: m68k4: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: pmds4: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: sun2: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: mantra: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: m68020: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: sun3: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 90: cd: sparc: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 90: cd: sparc_solaris: 
No such file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: ns: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: pdp: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: vax4: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: z80: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: z8000: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: arm: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: i86: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: xenix3: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: minix: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: i386: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: 6500: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: i80: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: em22: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: em24: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: em44: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: m68k2: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: pmds: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: minixST: No 
such file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: m68k4: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: pmds4: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: sun2: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: mantra: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: m68020: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: sun3: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 90: cd: sparc: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 90: cd: sparc_solaris: 
No such file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: ns: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: pdp: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: vax4: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: z80: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: z8000: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: arm: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: i86: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: xenix3: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: minix: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: i386: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: 6500: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: i80: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: em22: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: em24: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: em44: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: m68k2: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: pmds: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: minixST: No 
such file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: m68k4: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: pmds4: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: sun2: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: mantra: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: m68020: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: sun3: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 90: cd: sparc: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 90: cd: sparc_solaris: 
No such file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: ns: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: pdp: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: vax4: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: z80: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: z8000: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: arm: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: i386: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: 6500: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: em44: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: m68k4: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: pmds4: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: sun2: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: mantra: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: m68020: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: sun3: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 90: cd: sparc: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 90: cd: sparc_solaris: 
No such file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: ns: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: vax4: No such 
file or directory
/Users/phf/tttt/ack-5.6/first/limit_impl: line 100: cd: arm: No such 
file or directory
/tmp/ack-conf/Action: No such file or directory
/tmp/ack-conf/Action: No such file or directory

Re: [Tack-devel] Question about other ACK distributions...

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

On Friday 27 January 2006 03:05, Peter Fr=F6hlich wrote:
[...]
>    What is the relationship of this ACK distribution and the associated
> modernization effort
>    to others, most notably this one: http://www.laurasia.com.au/ack/

His version and mine both branch of the original 5.5 ACK release at the sam=
e=20
place. His version is considerably simplified, however: it has a vastly=20
simplified build system, and only has support for the i386 and i86 back-end=
s.=20
It's really only intended to build on Minix 3.

Michael Kennett has fixed a bunch of bugs, and as soon as I have the new bu=
ild=20
system up and running on my version I need to copy over his changes.

[...]
> It seems that some of the things that are still "TODO" for this port
> have already been done by Michael Kennett, at least to some extent.
> Seems to me that it would probably be a good idea to minimize the
> amount of "repeated work" done on this thing. Sorry if this is an FAQ,
> but if so I didn't find it online before writing this up.

No, it's not a FAQ (we don't have one yet). Really, Michael and my versions=
=20
are intended to do different things. It would be nice at some stage in the=
=20
future to be able to merge them together, but I'm realistic enough to reali=
se=20
that that might never happen! Currently, Michael's ACK is the standard=20
compiler toolchain used by Minix 3, so he has more definite requirements fo=
r=20
having something working than I do.

=2D-=20
+- David Given --McQ-+ "There is // One art // No more // No less // To
|  dg...@co...    | do // All things // With art // Lessness." --- Piet
| (dg...@ta...) | Hein
+- www.cowlark.com --+=20