tack-devel — Discussion for developers of the ACK.

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

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

At 9:52 AM -0400 7/21/06, Perry E. Metzger wrote:
>> Ok, I understood the chain of events to be GNUC was not defined and
>> neither was __lint__, thereby coming to "No function renaming
>> possible." 
>
>Correct. We're not running something GCC compatible, and we're not
>running lint, so there is no implemented version of the symbol
>renaming macros. If you implemented enough of the GCC stuff to do
>symbol renaming, you could lie and define __GNUC__. Really, though,
>that is only safe if you define all the gcc extensions. However, if
>ACK handled renaming, it would be fine to edit the include file to say
>__GNUC__ or __ACK__ or something similar.

Now, is this occuring because at this point (when the compiler messages occur), ACK has taken over and is starting to build the toolchain (bootstrapped)?  If so, then I understand the need for ELF output at this point.

If the answer is yes, and ACK take over so soon, my next question would be to David Given, asking how was this handled in the Linux port?

thanks for your patience,
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...

[Perry E. M. <pe...@pi...>]

"Gregory T. (tim) Kelly" <gt...@di...> writes:
> At 9:07 AM -0400 7/21/06, Perry E. Metzger wrote:
>>> And it might well be an interesting part of the code.  The
>>> conditional failing is #ifdef __lint__.
>>
>>I don't think you understood what your read.
>
> Ok, I understood the chain of events to be GNUC was not defined and
> neither was __lint__, thereby coming to "No function renaming
> possible." 

Correct. We're not running something GCC compatible, and we're not
running lint, so there is no implemented version of the symbol
renaming macros. If you implemented enough of the GCC stuff to do
symbol renaming, you could lie and define __GNUC__. Really, though,
that is only safe if you define all the gcc extensions. However, if
ACK handled renaming, it would be fine to edit the include file to say
__GNUC__ or __ACK__ or something similar.

The core of the problem here is that you need to do what GCC does,
which is allow assembly of directives that alter the underlying
symbols. You also need ELF and other things, of course.

> However, upon further review, you quite correct.  I misunderstood the compiler message:
>
> 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
>
> apparently it is not the path that is the problem but the control
> "#error" that is the problem.

Well, the #error is there to tell you that you're trying to use a
compiler that won't work because there is no symbol renaming macro
defined. The fact that ACK doesn't implement #error as "print error
and exit" is kind of a secondary issue, since #error will do the right
thing even when it isn't correctly implemented. :)

Perry

[Tack-devel] CVS & the new build system

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

Good news, everyone! Head of CVS builds with the new build system! On
NetBSD, too.

The build system uses a seperate tool wot I wrote called Prime Mover,
which is a kind of make replacement designed for very complex dependency
trees. It has its own SVN repository on pm.sf.net, but is deployed in
the ACK and LLgen as a single shell script executable called pm; when
deployed, it has no dependencies other than a C compiler called cc.

This should in no way be considered a release, but it should be
sufficiently complete to be useful for playing with. You get: C (ANSI &
K&R), the full set of code generators and assemblers, opt, and the ack
driver, and a few utilities. You can use it to compile code for the
various targets, but there are no libraries or linkers yet.

Prerequisites: you will first need to download and install LLgen 1.0.2
from the ACK website.

To build the ACK: check out head-of-CVS of the ACK module. Look at and
edit config.pm, although it shouldn't be necessary. Then do:

=2E/pm configure
=2E/pm

(The configure stage should go away eventually.) (On the BSDs, I found I
had to do 'ulimit -n 128' first, or else the build process would run out
of file descriptors.) This will build everything that's done so far and
put it all into a staging area, which by default is
/tmp/ack-temp/staging; eventually this will be tarred up and copied to
the destination installation directory, but for now it should be set up
to run directly from there. (Repeating that last ./pm will do an
incremental build.)

To test:

cd /tmp/ack-temp/staging
cat >test.c <<EOF
int foo(int i) {
return i+1;
}
EOF
bin/ack -v -O -ansi test.c -c.s -marm

(Replace the -marm with -mi386, or -m6500, or -mm68020...)

The build tool is currently still under development and so is rough
around the edges and very undocumented --- it should smooth down
eventually. Incidentally, NetBSD appears not to have an 'arch' command
--- what's the portable equivalent? Its absence causes warnings to be
generated by pm, although it still seems to work...

--=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 9:07 AM -0400 7/21/06, Perry E. Metzger wrote:
>> And it might well be an interesting part of the code.  The
>> conditional failing is #ifdef __lint__.
>
>I don't think you understood what your read.

Ok, I understood the chain of events to be GNUC was not defined and neither=
 was __lint__, thereby coming to "No function renaming possible." =20

   #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 environm=
ent
    #endif

However, upon further review, you quite correct.  I misunderstood the=
 compiler message:

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

apparently it is not the path that is the problem but the control "#error"=
 that is the problem.  Or am I mistaken here as well?  (Quite possible, as=
 dealing with the compiling aspect of software always gives me fits, as the=
 tools always seem to get in the way instead of working and letting me focus=
 on the code.)

I'm in the middle of something and wanted to post/ask this, instead of=
 delaying until I had responded to the rest of the email.

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

[Perry E. M. <pe...@pi...>]

"Gregory T. (tim) Kelly" <gt...@di...> writes:
>>This isn't the interesting part of the code. Look, as I said, at the
>>ELF implementation of the macro (for example). You have to read the
>>code and understand how it works, where it is used and why it is used.
>
> I did look at it.  And then I went to find it on OpenBSD and it
> isn't in sys/cdefs.h, which means that symbol renaming is somewhere
> else on OpenBSD (looks like <machine/cdefs.h> and <machine/asm.h>),
> and probably a third place on FreeBSD.  That made me come back and
> say perhaps there are BSD-independent solutions available that
> should be explored, instead of building to NetBSD's version of the
> gcc extensions.  I'm not wanting to use ELF in the output from ACK.

You have no choice. If you don't generate ELF, there is no possibility
at all of using the compiler in the future. The object format on every
platform you deal with is ELF. You won't be able to run non-ELF
userland binaries, since the kernel's loader expects ELF. You won't be
able to build kernels, since the boot loaders expect ELF. You won't be
able to generate shared objects or build kernels or link to dynamic
binaries etc. without ELF. That is true on *BSD, Linux and a dozen
other platforms.

As for the specifics of symbol renaming, you don't need to implement
symbol renaming itself -- you need to make sure that things like the
asm syntax will support it.

> I only want ACK to run on a BSD.  I certainly don't want to build
> ACK output to gcc syntax or anything more than needed to get
> bootstrapped.

You'll have a hard time without producing ELF. How do you plan to load
a non-ELF binary when the kernel expects ELF? :)

> And it might well be an interesting part of the code.  The
> conditional failing is #ifdef __lint__.

I don't think you understood what your read.

>  As far as I can tell, all of the Makefiles use ACK's lint rather
>  than the host-provided (Unix) lint.  Additionally, the path to the
>  failed conditional indicates _GNUC_ is _not_ defined.

Well, of course it isn't defined if you're running ACK, is it?

>>> Is this specific to NetBSD?
>>
>>This specific set of macros are, but almost all modern OSes have some
>>form of symbol versioning. The specifics tend to be fairly OS
>>specific, but they almost all make use of GCC's extended assembler
>>syntax and/or the ability of the assembler to provide things like ELF
>>section directives.
>
> If I have to implement a particular set of extensions to make this
> work on a BSD, I am likely to choose the xcoff/a.out format,

I don't think that's a smart move. :)

Really, what you want is to do what the GNU tools do and have a set of
back ends that are capable of handling multiple formats, but these
days, ELF is just about the only thing that matters.

> since it more closely resembles ack.out, making it one step closer
> to self-hosting (ACK building ACK).  My purpose is to get away from
> the gnu/gcc toolchain, not do it like they do.

ELF is not a gccism. It is a very widely used standard. The only two
formats that are of interest these days are ELF (on Unix) and PECOFF
(on Windows).

How do you plan on loading binaries if you don't use ELF? I don't have
COMPAT_AOUT in my NetBSD kernel, and most people don't. (There would
be no point in having COMPAT_AOUT since I have no a.out shared
libraries to make an a.out program run in the first place.)

>>> Is there a POSIX-like standard that could be applied to the
>>> solution, short of defining _STANDALONE?
>>
>>I have no idea what _STANDALONE has to do with this. You're not
>>writing a boot loader.
>
> According to the Design and Implementation of the 4.4BSD Operating
> System, a standalone program is one that can operate without the
> assistance of the BSD kernel, of which a bootloader is one example.
> According to the same book, there should be a standalone I/O
> library.  Wouldn't this provide a path to avoiding symbol renaming
> specifics?

Sure, if you are trying to run on the raw hardware without an
operating system present at all. The only example of such a program
that anyone cares about is the boot loader. Are you sure you
understand this?

>>Bear in mind, without this sort of thing, you don't have any hope of
>>generating system calls on *any* modern platform. I think there are
>>similar hacks in Solaris but (I think) they use a different set of
>>compiler facilities. Windows does this sort of thing with a vengeance,
>>too.
>
> Well, I'm somewhat at a loss to understand why a userland programmer
> needs to know the specifics of the symbol renaming mechanism of the
> particular OS an application (ACK) is being built for.

The ordinary programmer does not. The COMPILER author does. A compiler
is not an ordinary userland program. A compiler has to deal with all
sorts of things that are not considered by the ordinary programmer,
like the local object format.

>  Now, if the particular implementation of lint

This has nothing to do with lint. Lint is fully machine independent.

> or some other part of the ACK toolchain needs to know these
> specifics, I can accept this, to a point.  Earlier I had asked if
> there was a POSIX-like standard that could be applied, so that
> adherence to that standard would be sufficient and operating system
> particulars were not relevant.  I renew my inquiry.

I am not sure you understand the issue.

Perry

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

[Perry E. M. <pe...@pi...>]

"Gregory T. (tim) Kelly" <gt...@di...> writes:
> At 10:53 PM -0400 7/19/06, Perry E. Metzger wrote:
>>I'm happy to interpret error messages and/or help make things build
>>under NetBSD. It should be fairly straightforward -- I would guess
>>most issues are caused by the fact that the current NetBSD compilers
>>are fairly strict.
>
> This is greatly appreciated.  What I am finding is the primary
> reasons ACK isn't compiling is due to changes from BSD 4.2 to BSD
> 4.4 (outside of the cdefs.h issue).  So far it's been a difference
> in off_t (from a long to uint64_t)

You should structure things so that ACK doesn't know what the type of
off_t is -- different platforms have it different lengths. This is
pretty straightforward to do, and POSIX conforming code does not need
to know what length it is in general.

> and a deprecated function call (ftime, replaced by gettimeofday),

It is in libcompat, but in general, you should make things stick to
the lowest common denominator of modern POSIX. getttimeofday is
available on just about everything.

>>BTW, the right thing medium term is to make ACK into a pkgsrc package.
>
> This is probably reasonable, since as far as I know pkgsrc has been
> ported to all of the BSDs.

And Linux, and Solaris, and Irix, and Interix (aka "Services for Unix"
on Windows) and everything else you can imagine.

> I'm still trying to put the pieces together, but I think one step
> that will initially prevent usability on BSD is going to be the
> lack of an ack.out -> elf linker/converter.  It took me a day or
> two to realize ack.out is not a.out, but then again I'm a little
> slow on the uptake.

Well, this is an assembler issue, right? It should be straightforward
to generate ELF instead of other formats. You pretty much *need* ELF
on all modern platforms -- Linux and all the rest use ELF too. You
probably also need to be able to properly embed debugging symbols...

Perry

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

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

I had a chance to review the em assembly code stuff.  Sort of like Forth,=
 possibly easier to read, keeping track of stack contents always makes my=
 head hurt.  I always had Open Firmware to show the stack contents after=
 each step.  Like I said, I'm slow on the uptake.


Partially optimised em assembler:

---snip---

use word size 4 bytes and pointer size 4 bytes

 mes 2,4,4

function name:

 exp $count

function name, eight bytes of local variables:

 pro $count,8

two 4 byte variables directly referenced, looks like parameters:

 mes 3,4,4,0,1
 mes 3,0,4,0,1

two 4 byte local variables:

 mes 3,-8,4,0,5
 mes 3,-4,4,0,4

and something that isn't correctly formed, it appears:

 mes 3 (missing non-optional parameters? end of variables information?)

eight bytes of parameters are accessed:

 mes 9,8

<snip>

Conceptually the rest isn't that different from Forth, so I can work on the=
 particulars offline.  Seems to me the em code indicates two parameters, two=
 local variables, almost certainly gets the general loop correct, and=
 returns the total.  I don't see any problems with this portion of the code =
generation.

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] back-end tables, assemblers, and front-ends

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

At 8:28 AM -0400 7/20/06, David Given wrote:
>This is with opt (the global peephole optimiser), but without ego (the
>really heavyweight global optimisers) or top (the target peephole
>optimiser), so the generated code is pretty awful. Also, I suspect that
>the ARM code generator is rather poor. It appears to want to pass all
>parameters on the stack, which disturbs me a little.

I think there is something wrong with the ARM code generator.  I'm guessing=
 you got non-sensical answers when you ran this.  I can't figure out how the=
 passed arguments make it into the machine registers for calculation.

David's straightforward C code, which sums the numbers from min to max:

int count(int min, int max)
{
        int total =3D 0;
        int i;

        for (i=3Dmin; i<=3Dmax; i++)
                total +=3D i;

        return total;
}

Unoptimised ARM assembler:

---snip---
=2Esect .text
=2Esect .rom
=2Esect .data
=2Esect .bss
=2Eextern _count
=2Esect .text
_count:
STMFD R12<,{R13,R14}
MOV R13,R12
SUB R12,R12,#8
STMFD R12<,{R7,R6}
MOV R6,#0
LDR R7,[R13,#8]
I0016:
LDR R11,[R13,#12]
RSB.S R11,R11,R7
BLE I0015
BAL I0013
I0015:
ADD R6,R7,R6
ADD R7,R7,#1
BAL I0016
I0013:
MOV R0,R6
LDMFD R12<,{R7,R6}
MOV R12,R13
LDMFD R12<,{R13,R15}

I'm not fluent in ARM, so I am going to put some notes in the ARM assembler=
 output code; please correct me if I have mistakenly identified parts.

=46ile format information:

=2Esect .text
=2Esect .rom
=2Esect .data
=2Esect .bss

function name:

=2Eextern _count
=2Esect .text
_count:


set up local (machine) stack:

save off link register and stack register to r12 (decrements r12):

STMFD R12<,{R13,R14}=20

move the new stack pointer value into r13 (the stack pointer register):

MOV R13,R12=20

make room on the original stack:

SUB R12,R12,#8

save off non-volatile registers to original stack (decrements r12):

STMFD R12<,{R7,R6}

initialize total (and total is in r6)

MOV R6,#0

in theory, retrieve min from the stack and put it in r7, for i:

LDR R7,[R13,#8]



Except there's a piece missing - where are the arguments from r0-r4? =
 Shouldn't min be in r0 and max be in r1 (or vice-versa, I don't know the=
 specific calling convention)?  Looks to me like this code would pull in the=
 values in memory in the stack hole from the SUB R12, R12, #8 instruction=
 although I don't see anything stored to that location.



label the start of the loop:

I0016:

retrieve max from the stack and put it in r11:

LDR R11,[R13,#12]

compare r7 (i) to r11 (max):

RSB.S R11,R11,R7

branch ahead two instructions if r7 less than r11:

BLE I0015

break out of loop if r7 not less than r11:

BAL I0013

label the branch:

I0015:

add the current value of i (r7) to total (r6):

ADD R6,R7,R6

increment r7 (the growing value of i)

ADD R7,R7,#1

branch back to start of loop:

BAL I0016

label break out point:

I0013:

move total to the return register r0:

MOV R0,R6

restore the non-volatile registers:

LDMFD R12<,{R7,R6}

restore the stack:

MOV R12,R13
LDMFD R12<,{R13,R15}


Partially optimised em assembler:

Yeah, well, I'm not there yet. :-)  I can't tell if the mes instructions are=
 clear about the passed parameters.  If they are, then I'd guess the problem=
 was in the ARM assembler not properly locating the passed values from the=
 registers.  I think the assembler should have something like


STMFD R12<,{R13,R14}
STMFD R12<,{R0,R1}
MOV R13,R12
STMFD R12<,{R7,R6}
MOV R6,#0
LDR R7,[R13,#8]

since r13 is r12+8.  The whole stack reference isn't clean.  I don't know=
 why the assembler would save off the original stack to a register, create=
 space for a new stack frame, but then reference variables relative to the=
 original stack frame location.  That's why there's [r13,#8] and [r13,#12]=
 to refer to the min and max values as passed in.  The location of the=
 instruction I put in for saving r0 and r1 to the original stack should=
 preserve the rest of the stack offsets in the code and I also dropped the=
 instruction to subtract eight bytes from the original stack location.  I=
 think the additional STMFD will handle that.  All the same, I'm not fluent=
 in ARM and I might have some stack addition mistakes.  I just don't see=
 where the function call arguments are properly stored on any stack.  It's=
 possible the SUB instruction is incorrect and that's where the arguments=
 saving instruction is supposed to go.

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:
[...]
> And it might well be an interesting part of the code.  The conditional
> failing is #ifdef __lint__.  As far as I can tell, all of the Makefiles=
 use
> ACK's lint rather than the host-provided (Unix) lint.  Additionally, th=
e
> path to the failed conditional indicates _GNUC_ is _not_ defined.

I strongly suspect that the ACK lint is picking up the NetBSD include fil=
es
(which are gcc specific), and not the ACK include files (which aren't)...=
 you
may want to have a look at first/lint_params, which contains the lint
parameters (personally, I'd suggest turning it off completely).

[...]
> (Fully noting that David Given is in charge of the project and I don't =
mean
> to imply any insertion of myself in the decision-making process.  I'm
> looking at ACK for its stated purpose - a portable compiler kit.)

Well, 'in charge' is possibly a bit strong...

(PS. Incidentally, Tim, is there any chance you could persuade your email=
 app
to line-wrap your messages, please? It's making you rather hard to quote!=
)

--=20
+- David Given --McQ-+ "Gaping from its single obling socket was
|  dg...@co...    | scintillating, many fauceted scarlet emerald..."
| (dg...@ta...) | --- Jim Theis, _The Eye of Argon_ (spelling
+- www.cowlark.com --+ original)

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

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

At 1:06 PM -0400 7/20/06, Perry E. Metzger wrote:
>>    #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 envir=
onment
>>     #endif
>
>This isn't the interesting part of the code. Look, as I said, at the
>ELF implementation of the macro (for example). You have to read the
>code and understand how it works, where it is used and why it is used.

I did look at it.  And then I went to find it on OpenBSD and it isn't in=
 sys/cdefs.h, which means that symbol renaming is somewhere else on OpenBSD=
 (looks like <machine/cdefs.h> and <machine/asm.h>), and probably a third=
 place on FreeBSD.  That made me come back and say perhaps there are=
 BSD-independent solutions available that should be explored, instead of=
 building to NetBSD's version of the gcc extensions.  I'm not wanting to use=
 ELF in the output from ACK.  I only want ACK to run on a BSD.  I certainly=
 don't want to build ACK output to gcc syntax or anything more than needed=
 to get bootstrapped.

And it might well be an interesting part of the code.  The conditional=
 failing is #ifdef __lint__.  As far as I can tell, all of the Makefiles use=
 ACK's lint rather than the host-provided (Unix) lint.  Additionally, the=
 path to the failed conditional indicates _GNUC_ is _not_ defined.

>> Is this specific to NetBSD?
>
>This specific set of macros are, but almost all modern OSes have some
>form of symbol versioning. The specifics tend to be fairly OS
>specific, but they almost all make use of GCC's extended assembler
>syntax and/or the ability of the assembler to provide things like ELF
>section directives.

If I have to implement a particular set of extensions to make this work on a=
 BSD, I am likely to choose the xcoff/a.out format, since it more closely=
 resembles ack.out, making it one step closer to self-hosting (ACK building=
 ACK).  My purpose is to get away from the gnu/gcc toolchain, not do it like=
 they do. =20

(Fully noting that David Given is in charge of the project and I don't mean=
 to imply any insertion of myself in the decision-making process.  I'm=
 looking at ACK for its stated purpose - a portable compiler kit.)

>> Is there a POSIX-like standard that could be applied to the
>> solution, short of defining _STANDALONE?
>
>I have no idea what _STANDALONE has to do with this. You're not
>writing a boot loader.

According to the Design and Implementation of the 4.4BSD Operating System, a=
 standalone program is one that can operate without the assistance of the=
 BSD kernel, of which a bootloader is one example.  According to the same=
 book, there should be a standalone I/O library.  Wouldn't this provide a=
 path to avoiding symbol renaming specifics?

=46rom what I can tell, Tanenbaum's approach is to adhere to POSIX as much=
 as possible and provide implementations of anything extra needed, rather=
 than rely on a specific operating system's version of that functionality. =
 If anyone knows differently, please let me know because I agree with that=
 philosophy (having come from a radically different OS background and=
 routinely found myself excluded from working tools).

>Bear in mind, without this sort of thing, you don't have any hope of
>generating system calls on *any* modern platform. I think there are
>similar hacks in Solaris but (I think) they use a different set of
>compiler facilities. Windows does this sort of thing with a vengeance,
>too.

Well, I'm somewhat at a loss to understand why a userland programmer needs=
 to know the specifics of the symbol renaming mechanism of the particular OS=
 an application (ACK) is being built for.  Now, if the particular=
 implementation of lint or some other part of the ACK toolchain needs to=
 know these specifics, I can accept this, to a point.  Earlier I had asked=
 if there was a POSIX-like standard that could be applied, so that adherence=
 to that standard would be sufficient and operating system particulars were=
 not relevant.  I renew my inquiry.

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

[Perry E. M. <pe...@pi...>]

"Gregory T. (tim) Kelly" <gt...@di...> writes:
> Hi Perry,
> I definately appreciate your feedback and help.  
>
>    #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

This isn't the interesting part of the code. Look, as I said, at the
ELF implementation of the macro (for example). You have to read the
code and understand how it works, where it is used and why it is used.

>
> At 10:57 PM -0400 7/19/06, Perry E. Metzger wrote:
>>Congratulations. You've hit NetBSD's symbol renaming stuff.
>>
>>Unfortunately, in order to handle API versioning, it is kind of
>>necessary for whatever compiler one uses under NetBSD to be able to
>>deal with symbol renaming in order to select the appropriate version
>>of the C library call in question -- no versioning support means you
>>have no hope at all of linking against our C library.
>
> Is this specific to NetBSD?

This specific set of macros are, but almost all modern OSes have some
form of symbol versioning. The specifics tend to be fairly OS
specific, but they almost all make use of GCC's extended assembler
syntax and/or the ability of the assembler to provide things like ELF
section directives.

> Is there a POSIX-like standard that could be applied to the
> solution, short of defining _STANDALONE?

I have no idea what _STANDALONE has to do with this. You're not
writing a boot loader.

> I would like to avoid implementing any *BSD specific code,

You have to look at how the renaming stuff is implemented.  It is not
a question of NetBSD specific code. You need to implement the sorts of
GCC extensions that the various BSDs and Linux use to do the symbol
renaming. You do not need to implement symbol renaming itself.

Bear in mind, without this sort of thing, you don't have any hope of
generating system calls on *any* modern platform. I think there are
similar hacks in Solaris but (I think) they use a different set of
compiler facilities. Windows does this sort of thing with a vengeance,
too.

> exclusion of the other BSDs (or additional work for them).  I'm also
> surmising that anything that breaks ACK (TACK?) on Linux isn't going
> to get into the tree.

You can't run on Linux without this sort of thing either.


Perry

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

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

At 8:28 AM -0400 7/20/06, David Given wrote:
>Long-term? I've been going at this for a year and a half, now, so I
>suspect that simply producing a usable release counts as long term...

So after your two years of hard work (granting that perhaps another six=
 months of work is ahead), and ten (twenty?) years of existence, ACK'll be=
 an overnight sensation :-)

>But I don't really have anything in the way of specific long-term
>planning. I just want to get it usable enough to gain users. In its
>current state, the 5.6 release is simply too hard to set up, and I'm
>hoping to improve that. With luck, there'll be enough users to develop a
>certain amount of maintenance momentum --- although I doubt the ACK will
>topple gcc, I do think that it can fill a very valuable niche in the
>compiler ecosystem.

I am convinced that an end-to-end BSD-licensed toolchain will be adopted by=
 at least one BSD based OS.  It might not be one of the big three, but it=
 will be adopted.  I think there has to be very careful monitoring of "let's=
 see how gcc/gas/ld does it" comments down the road. =20

>Plus, it's an amazingly elegant design, and it would be a terrible shame
>if all that work died due to bit rot.

Agreed.

>[...]
>> Ok. It occurs to me that ACK was written before there was extensive
>> pipelining in CPUs. It also seems to me that a stack-based virtual
>> machine isn't going to be aware of pipelining.
>
>*nods*
>
>There seems to be exactly one usage of the word 'pipeline' in the entire
>source tree in the CPU sense, and it's the bit in the ARM assembler that
>calculates branch offsets...

On PowerPC, some operations that set conditional register values (for=
 branching) can take four cycles and at least one of them (which escapes me=
 at the moment) takes seven (and my apologies if I have the specifics=
 incorrect).  Most, if not all, of the algebraic operations have variants=
 that can set the conditional registers at the same time as the operation. =
 This helps optimize some of the pipelining by recognizing that a=
 subtraction, for example, might later need to compare if the result was=
 less than zero.  Both POWER and PowerPC chips benefit greatly from having=
 something constantly going on, so grinding to a halt waiting for the=
 results of a comparison really hurts performance.  Having good=
 communication between the peephole optimizer (or the appropriate component=
 that transmits the messages about register usage) and the assembler=
 regarding looking ahead is going to be critical.

Then there are the floating point registers, which have to be aligned on 8=
 byte boundaries or else the processor generates a floating point exception.=
  And Altivec needs 16 byte alignment or it just chops the data (and can=
 overwrite existing data with garbage).=20

Oh - does endian-ness affect ACK?  PPC is big-endian, with a little-endian=
 mode that is generally avoided whenever possible.=20

>The good news is I now have my work tree in sufficient state that I can
>compile a C program into ARM assembler!

Excellent!

>The bad news is that when I tell it to compile for i386, it still
>generates ARM assembler... there's a bug in pm that's causing it to pick
>the wrong file when installing each stage. So, everything *compiles*,
>but it doesn't get put together correctly. I'm looking into this.
>Hopefully once I've tracked that down I can declare the new build system
>to be sufficiently working to be useful.

Is there a target arch flag?

Pardon my ignorance, but what is pm?

>This is with opt (the global peephole optimiser), but without ego (the
>really heavyweight global optimisers) or top (the target peephole
>optimiser), so the generated code is pretty awful. Also, I suspect that
>the ARM code generator is rather poor. It appears to want to pass all
>parameters on the stack, which disturbs me a little.

Which of course introduces the question of ABIs.  What ABIs and file formats=
 are already available in ACK?

>Unoptimised i386 assembler (after manual hacking to get the code
>generator in place):

<snip>

>There's something very odd going on in that loop.

I'm afraid I can't help you with the x86 code, nor the ARM code (which at=
 least looks something like PPC).  I am still working up to grasping the=
 components to ACK and I haven't had a chance to look at the em document. =
 It is high on the list of to-do.

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 7:56 AM -0400 7/20/06, Gregory T. (tim) Kelly wrote:
>Tanenbaum uses pretty strict C in his stuff, as far as I can tell, and so=
 far I have not found a single compile error related to the code itself.

I don't mean to take away from David Given's efforts with the above comment.=
  I have found the TACK package as a whole to be pretty smooth (in that=
 compiling errors seem to be minor as opposed to insurmountable), and I do=
 not have enough information to know exactly who is responsible for what so=
 my apologies if I have diminished anyone's contributions.

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] back-end tables, assemblers, and front-ends

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

Gregory T. (tim) Kelly wrote:
> At 2:43 PM -0400 7/19/06, David Given wrote:
>> As for whether the optimiser's sufficiently smart to be able to cope w=
ith
>> complex pipelines --- beats me. I haven't gone into that part of the s=
ystem
>> yet, and am not terribly knowledgeable about the whole topic.
>=20
> What (if any) are your long term plans with ACK?

Long-term? I've been going at this for a year and a half, now, so I
suspect that simply producing a usable release counts as long term...

But I don't really have anything in the way of specific long-term
planning. I just want to get it usable enough to gain users. In its
current state, the 5.6 release is simply too hard to set up, and I'm
hoping to improve that. With luck, there'll be enough users to develop a
certain amount of maintenance momentum --- although I doubt the ACK will
topple gcc, I do think that it can fill a very valuable niche in the
compiler ecosystem.

Plus, it's an amazingly elegant design, and it would be a terrible shame
if all that work died due to bit rot.

[...]
> Ok. It occurs to me that ACK was written before there was extensive
> pipelining in CPUs. It also seems to me that a stack-based virtual
> machine isn't going to be aware of pipelining.

*nods*

There seems to be exactly one usage of the word 'pipeline' in the entire
source tree in the CPU sense, and it's the bit in the ARM assembler that
calculates branch offsets...

[...]
> Sounds good. I look forward to working with the new stuff, just to
> have a common base to work from.

The good news is I now have my work tree in sufficient state that I can
compile a C program into ARM assembler!

The bad news is that when I tell it to compile for i386, it still
generates ARM assembler... there's a bug in pm that's causing it to pick
the wrong file when installing each stage. So, everything *compiles*,
but it doesn't get put together correctly. I'm looking into this.
Hopefully once I've tracked that down I can declare the new build system
to be sufficiently working to be useful.

This is with opt (the global peephole optimiser), but without ego (the
really heavyweight global optimisers) or top (the target peephole
optimiser), so the generated code is pretty awful. Also, I suspect that
the ARM code generator is rather poor. It appears to want to pass all
parameters on the stack, which disturbs me a little.

Source code:

---snip---
int count(int min, int max)
{
        int total =3D 0;
        int i;

        for (i=3Dmin; i<=3Dmax; i++)
                total +=3D i;

        return total;
}
---snip---

Partially optimised em assembler:

---snip---
 mes 2,4,4
 exp $count
 pro $count,8
 mes 3,4,4,0,1
 mes 3,0,4,0,1
 mes 3,-8,4,0,5
 mes 3,-4,4,0,4
 mes 3
 mes 9,8
 loc 0
 stl -4
 lol 0
 stl -8
6
 lol -8
 lol 4
 cmi 4
 zle *5
 bra *3
5
 lol -8
 lol -4
 adi 4
 stl -4
 lol -8
 loc 1
 adi 4
 stl -8
 bra *6
3
 lol -4
 ret 4
 end 8
 mes 4,10,'test.c\000'
---snip---

Unoptimised ARM assembler:

---snip---
=2Esect .text
=2Esect .rom
=2Esect .data
=2Esect .bss
=2Eextern _count
=2Esect .text
_count:
STMFD R12<,{R13,R14}
MOV R13,R12
SUB R12,R12,#8
STMFD R12<,{R7,R6}
MOV R6,#0
LDR R7,[R13,#8]
I0016:
LDR R11,[R13,#12]
RSB.S R11,R11,R7
BLE I0015
BAL I0013
I0015:
ADD R6,R7,R6
ADD R7,R7,#1
BAL I0016
I0013:
MOV R0,R6
LDMFD R12<,{R7,R6}
MOV R12,R13
LDMFD R12<,{R13,R15}
---snip---

Unoptimised i386 assembler (after manual hacking to get the code
generator in place):

---snip---
=2Esect .text; .sect .rom; .sect .data; .sect .bss
=2Eextern _count
=2Esect .text
_count:
push ebp
mov ebp,esp
push esi
push edi
xor edi,edi
mov esi,8(ebp)
I1_6:
xor eax,eax
cmp esi,12(ebp)
je 2f
jg 1f
inc eax
jmp 2f
1:
dec eax
2:
! kill cc
test eax,eax
jle I1_5
jmp I1_3
I1_5:
add edi,esi
add esi,1
jmp I1_6
I1_3:
mov eax,edi
pop edi
pop esi
leave
ret
---snip---

There's something very odd going on in that loop.

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

(Sorry, I didn't mean to send to both Perry and the list with my previous re=
ply.)

At 10:53 PM -0400 7/19/06, Perry E. Metzger wrote:
>I'm happy to interpret error messages and/or help make things build
>under NetBSD. It should be fairly straightforward -- I would guess
>most issues are caused by the fact that the current NetBSD compilers
>are fairly strict.

This is greatly appreciated.  What I am finding is the primary reasons ACK=
 isn't compiling is due to changes from BSD 4.2 to BSD 4.4 (outside of the=
 cdefs.h issue).  So far it's been a difference in off_t (from a long to=
 uint64_t) and a deprecated function call (ftime, replaced by gettimeofday),=
 and some #defines.  Tanenbaum uses pretty strict C in his stuff, as far as=
 I can tell, and so far I have not found a single compile error related to=
 the code itself.

>BTW, the right thing medium term is to make ACK into a pkgsrc package.

This is probably reasonable, since as far as I know pkgsrc has been ported=
 to all of the BSDs.  I'm still trying to put the pieces together, but I=
 think one step that will initially prevent usability on BSD is going to be=
 the lack of an ack.out -> elf linker/converter.  It took me a day or two to=
 realize ack.out is not a.out, but then again I'm a little slow on the uptak=
e.

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 Perry,
I definately appreciate your feedback and help. =20

   #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 environm=
ent
    #endif

At 10:57 PM -0400 7/19/06, Perry E. Metzger wrote:
>Congratulations. You've hit NetBSD's symbol renaming stuff.
>
>Unfortunately, in order to handle API versioning, it is kind of
>necessary for whatever compiler one uses under NetBSD to be able to
>deal with symbol renaming in order to select the appropriate version
>of the C library call in question -- no versioning support means you
>have no hope at all of linking against our C library.

Is this specific to NetBSD?  Is there a POSIX-like standard that could be=
 applied to the solution, short of defining _STANDALONE?  I would like to=
 avoid implementing any *BSD specific code, to the exclusion of the other=
 BSDs (or additional work for them).  I'm also surmising that anything that=
 breaks ACK (TACK?) on Linux isn't going to get into the tree.

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

[Perry E. M. <pe...@pi...>]

"Gregory T. (tim) Kelly" <gt...@di...> writes:
> "/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

Congratulations. You've hit NetBSD's symbol renaming stuff.

Unfortunately, in order to handle API versioning, it is kind of
necessary for whatever compiler one uses under NetBSD to be able to
deal with symbol renaming in order to select the appropriate version
of the C library call in question -- no versioning support means you
have no hope at all of linking against our C library.

Luckily, symbol renaming is fairly easy to implement. It requires only
the most minor of namespace tricks. Have a look at, for example,
sys/cdefs_aout.h or (preferably) sys/cdefs_elf.h for some clues on
what is being done.

Generally speaking, it should be pretty straightforward to make the
whole thing work right.

Perry

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

[Perry E. M. <pe...@pi...>]

"Gregory T. (tim) Kelly" <gt...@di...> writes:
> 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.

I'm happy to interpret error messages and/or help make things build
under NetBSD. It should be fairly straightforward -- I would guess
most issues are caused by the fact that the current NetBSD compilers
are fairly strict.

BTW, the right thing medium term is to make ACK into a pkgsrc package.

.pm

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

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

At 2:43 PM -0400 7/19/06, David Given wrote:
>As for whether the optimiser's sufficiently smart to be able to cope with
>complex pipelines --- beats me. I haven't gone into that part of the system
>yet, and am not terribly knowledgeable about the whole topic.

What (if any) are your long term plans with ACK?

>If I were to make an educated guess, I'd suggest that anything involving
>instruction reordering would have to go into the target optimiser; judging by
>the way ncg tables work, I don't think you'd have much mileage in trying to
>come up with a table that could do it directly.

Ok.  It occurs to me that ACK was written before there was extensive pipelining in CPUs.  It also seems to me that a stack-based virtual machine isn't going to be aware of pipelining.  

>LLgen doesn't really have much of a tree, but it would certainly be
>interesting to find out whether pm works at all. It ought to, but I haven't
>actually tried it yet. (It's still under development too, alas.)
>
>As soon as I have everything working on my Linux box I need to test on SF's
>build farm.

Sounds good.  I look forward to working with the new stuff, just to have a common base to work from.

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] back-end tables, assemblers, and front-ends

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

Gregory T. (tim) Kelly wrote:
[...]
> This has peephole optimization before the global optimizer and isn't=20
> platform dependent. Which version is correct? :-)

Uh... trust Ceriel on that one!

As for whether the optimiser's sufficiently smart to be able to cope with=

complex pipelines --- beats me. I haven't gone into that part of the syst=
em
yet, and am not terribly knowledgeable about the whole topic.

If I were to make an educated guess, I'd suggest that anything involving
instruction reordering would have to go into the target optimiser; judgin=
g by
the way ncg tables work, I don't think you'd have much mileage in trying =
to
come up with a table that could do it directly.

[...]
> If I download the standalone copy of LLgen, will building that give me =
a
> good overview of the new tree design?  Might make porting to NetBSD eas=
ier
> to sort out with a small tree.

LLgen doesn't really have much of a tree, but it would certainly be
interesting to find out whether pm works at all. It ought to, but I haven=
't
actually tried it yet. (It's still under development too, alas.)

As soon as I have everything working on my Linux box I need to test on SF=
's
build farm.

--=20
+- David Given --McQ-+ "Gaping from its single obling socket was
|  dg...@co...    | scintillating, many fauceted scarlet emerald..."
| (dg...@ta...) | --- Jim Theis, _The Eye of Argon_ (spelling
+- www.cowlark.com --+ original)

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

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

At 1:13 PM -0400 7/19/06, David Given wrote:
>> Ok. Is the new build generally self-contained and independent of the
>> POSIX platform it is running on? The current build appears to have
>> been able to build on BSD 4.1 and BSD 4.2, so while it hasn't yet run
>> successfully end-to-end, most of the problems just seem to be related to
>> the changes since BSD 4.2.
>
>It should be; it requires a C compiler called cc to bootstrap, but it
>should be pretty portable.
>
>(If you install the standalone copy of LLgen from the website --- which
>you'll need for the next version anyway --- that uses it. Rather
>overkill for such a small app, but I wanted to see how it worked in real
>life.)

If I download the standalone copy of LLgen, will building that give me a good overview of the new tree design?  Might make porting to NetBSD easier to sort out with a small tree.

>[...]
>>> make depend
>
>Running make directly doesn't appear to set the paths up correctly ---
>AFAIK, you have to run the INSTALL script every time you want to build
>something. I'm not sure if it's possible to do incremental builds.

Ugh.  Tends to make testing changes rather slow.

There are still some legitimate reasons to move do_deps/rm_deps/do_resolves to a variable format with a $(UTIL_BIN) path prefix.  On an installed world, UTIL_BIN might actually be /bin (eventually, but quite possibly on Minix).  

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] back-end tables, assemblers, and front-ends

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

At 11:13 AM -0400 7/19/06, David Given wrote:
>Yup. The whole system is done in multiple stages:
>
>   source file
>-> preprocessor
>-> front end compiler (emits em assembly)
>-> global optimiser (type 1)
>-> global optimiser (type 2)
>-> ...etc...
>-> back-end (emits native assembly)
>-> peep-hole optimiser
>-> assembler (emits ack.out object file)
>-> linker (emits ack.out binary)
>-> converter (emits native binary)
>
>For speed, the system tends to use a binary encoding of the em assembly
>rather than actual text. Every stage is a separate executable; look in
>lib.bin for all the bits.

Ok, "A Practical Toolkit For Making Portable Compilers" has the following:

1. The preprocessor.
2. The front ends.
3. The peephole optimizer.
4. The global optimizer.
5. The back end.
6. The target machine optimizer.
7. The universal assembler/linker.
8. The utility package.

This has peephole optimization before the global optimizer and isn't=
 platform dependent.  Which version is correct?  :-)

I've been reading about the optimizers and been wondering about their impact=
 on the object code and instruction scheduling.  While once upon a time RISC=
 was supposed to be a one instruction, one cycle design, pipelining killed=
 that dream.  PowerPC is prone to performance nose-dives when instructions=
 are not scheduled well and bubbles or instruction dependencies occur (in=
 particular operations that set the conditional registers for branching). =
 While the actual number of cycles each instruction takes is not easily=
 determined without the NDA documentation (Book IV), it is possible to=
 minimize bubbles and waits by scheduling operations well in advance of when=
 the conditional branch needs to be evaluated.  On the surface, this appears=
 to be counter to the peep-hole optimization as described by the overview. =
=20

Can the target machine optimizer reverse some/most/all of the effects of=
 peephole optimization? (I'm trying to figure out all of the parts that need=
 to be written.)

On the plus side, I like how the global optimizer appears to be able=
 (according to the ngc doc) to give hints regarding register usage.  This=
 should help a lot in the stack->register translations for the backend.

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:
[...]
> Ok. Is the new build generally self-contained and independent of the
> POSIX platform it is running on? The current build appears to have
> been able to build on BSD 4.1 and BSD 4.2, so while it hasn't yet run
> successfully end-to-end, most of the problems just seem to be related t=
o
> the changes since BSD 4.2.

It should be; it requires a C compiler called cc to bootstrap, but it
should be pretty portable.

(If you install the standalone copy of LLgen from the website --- which
you'll need for the next version anyway --- that uses it. Rather
overkill for such a small app, but I wanted to see how it worked in real
life.)

[...]
>> make depend

Running make directly doesn't appear to set the paths up correctly ---
AFAIK, you have to run the INSTALL script every time you want to build
something. I'm not sure if it's possible to do incremental builds.

--=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] back-end tables, assemblers, and front-ends

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

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

Yup. The whole system is done in multiple stages:

   source file
-> preprocessor
-> front end compiler (emits em assembly)
-> global optimiser (type 1)
-> global optimiser (type 2)
-> ...etc...
-> back-end (emits native assembly)
-> peep-hole optimiser
-> assembler (emits ack.out object file)
-> linker (emits ack.out binary)
-> converter (emits native binary)

For speed, the system tends to use a binary encoding of the em assembly
rather than actual text. Every stage is a separate executable; look in
lib.bin for all the bits.

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

Don't see any reason why not, although the em calling conventions must
match, of course. I'm sure it's perfectly easy to compile a Pascal
program that calls out to C functions or vice versa, because they're
very similar languages --- interoperating Basic and C would probably be
trickier, though.

Some of the language run-time libraries are actually written by hand in
em assembly for maximum portability (look for files with a .e extension).=


--=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 10:59 AM -0400 7/19/06, David Given wrote:
>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.)

Ok.  Is the new build generally self-contained and independent of the POSIX=
 platform it is running on?  The current build appears to have been able to=
 build on BSD 4.1 and BSD 4.2, so while it hasn't yet run successfully=
 end-to-end, most of the problems just seem to be related to the changes=
 since BSD 4.2.

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

I tried this:

#!/bin/sh
: $Id: rm_deps,v 1.2 1994/06/23 13:47:02 ceriel Exp $

: remove dependencies from a makefile, write result on standard output.
: we cannot do this directly in a makefile because some make versions
: have # start a comment, always.

sed -e '/^#DEPENDENCIES/,$d' $1
echo '#DEPENDENCIES'

> make depend
=2E/util/int/M.warn_h ./doc/int/appA
=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

(the "." represents the path on my machine, which I've deleted for public co=
nsumption)

If I add the path to the rm_deps file, with or without the #!/bin/sh, I get=
 a radically different output (with other failures due to .SUF files not=
 found).  In some of the other Makefiles (specifically in lang/cem/lint),=
 there is a UTIL_BIN defined, which piggybacks on $(UTIL_HOME)/bin, exactly=
 what I need (RM_DEPS=3D$(UTIL_BIN)/rm_deps). =20

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