The ACK compiler

29 views
Skip to first unread message

aaaaaaaaaaaaaaaaaaaaaaaaaa

unread,
Jul 31, 2010, 4:55:06 PM7/31/10
to
Gents,

I spent some time again with Minix and the excellent ACK compiler. It
has multiple front ends: for Pascal, C and Modula-2. So I got the
current version of ACK for Linux, compiled it and installed it.

WOOWW! The ACK blows you out of your socks! This is a very very good
Modula-2 compiler. It outperforms Mocka for a few tests that I did.
See http://fruttenboel.verhoeven272.nl/ack/index.html for some more
details

Christoph Schlegel

unread,
Aug 1, 2010, 7:21:00 PM8/1/10
to

I am not able to build the compiler due to an error reported a long time
ago:

http://sourceforge.net/tracker/?func=detail&aid=2902044&group_id=130811&atid=718966

Do you have a workaround?

Regards

Christoph

aaaaaaaaaaaaaaaaaaaaaaaaaa

unread,
Aug 2, 2010, 5:11:04 AM8/2/10
to
On Aug 2, 1:21 am, Christoph Schlegel <modu...@gmx.net> wrote:

> I am not able to build the compiler due to an error reported a long time
> ago:
>

> http://sourceforge.net/tracker/?func=detail&aid=2902044&group_id=1308...


>
> Do you have a workaround?

I got the attention from David Given and he also told that his version
had some 'bit-rot' and did not compile cleanly.
I got some warnings or at least some messages while compiling, but all
went along and the ACK seems to have been built.

The author used Ubuntu. I used Slackware 12.2. Perhaps its due to some
kind of libc.

aaaaaaaaaaaaaaaaaaaaaaaaaa

unread,
Aug 2, 2010, 9:46:10 AM8/2/10
to
I ported my AVR disassembler from Mocka to ACK and it works great. The
ACK even signaled a CARDINAL UnderFlow error. Took some time to get
that fixed. But it turned out to be rather easy, in the end.

http://fruttenboel.verhoeven272.nl/ack/dis05.html

So, I guess if the ACK does not build good, better check my page where
I told how I did it: http://fruttenboel.verhoeven272.nl/ack/getit.html

I'm a happy user, that's for sure. Now I only need to find out if
there is a fixed place to store my own modules. The standard modules
are compiled into the compiler and only the DEF files are exposed.

Duke Normandin

unread,
Aug 2, 2010, 1:51:01 PM8/2/10
to

gcc "-g" "-I/home/dnormandin/tmp/ack-6.0pre3/h" "-I/home/dnormandin/tmp/ack-6.0pre3/modules/h" "-I/tmp/ack-temp/headers/" -c -o "/tmp/ack-temp/pmcache/230-tabgen.o" "util/cmisc/tabgen.c"
util/cmisc/tabgen.c:295: error: conflicting types for 'getline'
/usr/include/stdio.h:653: error: previous declaration of 'getline' was here
rm -f "/tmp/ack-temp/pmcache/230-tabgen.o"
pm: object 'cfile', defined at pmfile:38, failed to build with return code 256

dnormandin@select-man:~/tmp/ack-6.0pre3$

Any ideas on how to fix this?

I'm on the latest Xubuntu installation. TIA...
--
Duke

aaaaaaaaaaaaaaaaaaaaaaaaaa

unread,
Aug 3, 2010, 3:47:38 AM8/3/10
to
On Aug 2, 7:51 pm, Duke Normandin <dukeofp...@ml1.net> wrote:

> dnormandin@select-man:~/tmp/ack-6.0pre3$
>
> Any ideas on how to fix this?
>
> I'm on the latest Xubuntu installation. TIA...

I relayed the question to david given. I myself have not so good
experiences with Debian (and hence also Ubuntu and Knoppix) kinds of
Linux. Debian have created their own standards in libraries. They say
they're better. To me, they're only different.

Many such problems stem from this behavior.... The nice, colourful,
user interface has its price.

The problem need not be in the ack. It may be in the pm (david's
version of make). I'll try to make a binary edition of the ACK.

Marco van de Voort

unread,
Aug 3, 2010, 11:21:39 AM8/3/10
to
On 2010-08-03, aaaaaaaaaaaaaaaaaaaaaaaaaa <jan...@gmail.com> wrote:
> Many such problems stem from this behavior.... The nice, colourful,
> user interface has its price.

(I think it is more that they don't give a d@mn about any form of binary
compatibility, partially also because they move slower because mostly
volunteer. Redhat's environments don't suffer from this so much)

Duke Normandin

unread,
Aug 3, 2010, 11:39:54 AM8/3/10
to
On 2010-08-03, aaaaaaaaaaaaaaaaaaaaaaaaaa <jan...@gmail.com> wrote:

Thanks for following up with David Given!

Just to be clear, will the ACK compiler produce code that will execute
on my Linux box, or does it only produce code for legacy hardware?

aaaaaaaaaaaaaaaaaaaaaaaaaa

unread,
Aug 3, 2010, 12:31:53 PM8/3/10
to
On Aug 3, 5:39 pm, Duke Normandin <dukeofp...@ml1.net> wrote:

> Thanks for following up with David Given!
>
> Just to be clear, will the ACK compiler produce code that will execute
> on my Linux box, or does it only produce code for legacy hardware?

I contacted David. Thursday at last there will be a new release with
the getline function fixed.

When I issue the command 'ack dis05.mod -mpc86 -o poep' then a floppy
disk image for a standalone 8086 machine is generated.

When I issue the command 'ack dis05.mod -mlinux386 -o poep' then an
ELF executable is made that runs perfectly fine in my Slackware Linux
system. One thing: do NOT use 'strip' to strip the executables. You
will end up with -something- but not an executable...

The file extension is necessary with the ACK since it uses it to load
the right frontend. '.mod' extensions load the Modula-2 front end.
'.c' and '.pas' will load the C and the Pascal frontend
(respectively).

Use 'wget members.home.nl/jmr272/AVRdis' (without the quotes) to get
the ACK compiled executable of my AVR disassembler. You will not be
able to disassemble a file since you will not have the processor
description files in /usr/local/AVR. But it will at least show the
version number. You can run the file after 'chmod 755 AVRdis'.
I can disassemble ANY Intel Hex file. Read more in
http://fruttenboel.verhoeven272.nl/AVR/index.html

Duke Normandin

unread,
Aug 3, 2010, 1:01:58 PM8/3/10
to
On 2010-08-03, aaaaaaaaaaaaaaaaaaaaaaaaaa <jan...@gmail.com> wrote:
> On Aug 3, 5:39 pm, Duke Normandin <dukeofp...@ml1.net> wrote:
>
>> Thanks for following up with David Given!
>>
>> Just to be clear, will the ACK compiler produce code that will execute
>> on my Linux box, or does it only produce code for legacy hardware?
>
> I contacted David. Thursday at last there will be a new release with
> the getline function fixed.

So that should fix the compile problem I had?

> When I issue the command 'ack dis05.mod -mpc86 -o poep' then a floppy
> disk image for a standalone 8086 machine is generated.
>
> When I issue the command 'ack dis05.mod -mlinux386 -o poep' then an
> ELF executable is made that runs perfectly fine in my Slackware Linux
> system. One thing: do NOT use 'strip' to strip the executables. You
> will end up with -something- but not an executable...
>
> The file extension is necessary with the ACK since it uses it to load
> the right frontend. '.mod' extensions load the Modula-2 front end.
> '.c' and '.pas' will load the C and the Pascal frontend
> (respectively).

All sounds good to me! Can't wait to try it out...

> Use 'wget members.home.nl/jmr272/AVRdis' (without the quotes) to get
> the ACK compiled executable of my AVR disassembler. You will not be
> able to disassemble a file since you will not have the processor
> description files in /usr/local/AVR. But it will at least show the
> version number. You can run the file after 'chmod 755 AVRdis'.
> I can disassemble ANY Intel Hex file. Read more in
> http://fruttenboel.verhoeven272.nl/AVR/index.html

Cool! Thanks...

cvs

unread,
Aug 3, 2010, 1:34:27 PM8/3/10
to

Thank you for bringing ACK into discussion again. I'll be happy to
play with it as soon as it builds.

As a long-time user of Slackware and Debian (I like both) I do not
understand what you are saying about the latter. Debian gives you the
freedom to decide exactly what you want on your disc - there is even
more (sometimes too much) choice than with Slackware. It is not -
except you want it to be - a nice-interface-distribution.

Regards

Christoph

aaaaaaaaaaaaaaaaaaaaaaaaaa

unread,
Aug 3, 2010, 4:41:54 PM8/3/10
to
On Aug 3, 7:01 pm, Duke Normandin <dukeofp...@ml1.net> wrote:

> So that should fix the compile problem I had?

Yes.

> > Use 'wget members.home.nl/jmr272/AVRdis' (without the quotes) to get

> Cool! Thanks...

Perfect.

aaaaaaaaaaaaaaaaaaaaaaaaaa

unread,
Aug 3, 2010, 4:52:47 PM8/3/10
to
On Aug 3, 7:34 pm, cvs <cvschle...@gmail.com> wrote:

> As a long-time user of Slackware and Debian (I like both)

So did I.

I'll give you an example.

I was very pleased with my Debian Sarge system. Used it for many
years. Then I needed a new browser. But Sarge was not supported
anymore. All repos were ERASED. I could only find an old DVD at
CheapByts.com with the Sarge distro. But on it wer the same old
browsers...
Tried to compile a new SeaMonkey. Failed. The libraries were
incorrect. Tried to install new libraries. Failed: incompatible with
Debian. Got myself a TFT. Could not get the thing working. I needed to
cast a magic spell that was only in the xorg.conf file... Etc etc etc.

Now I have a system that will install anything I want. Perhaps things
have changed. But I won't find out. It can change over night again.
I'm not going to take that risc.

The aptget and aptitude systems are great. But the Debain system
should honor satisfied users of older versions. If you're always
forced by someone else to upgrade, that does not sound like 'free' as
in 'freedom' anymore. As if there is an eleventh commandment: thou
shall not use old versions of my Software. Which seems to be the motto
of The Other System. :o|

> Debian gives you the freedom to decide exactly what you want on your disc

As long as it is the distro that THEY approve....

Christoph Schlegel

unread,
Aug 4, 2010, 1:44:37 PM8/4/10
to

Well. I guess things have not changed as most of the libraries in the
open source world are more or less developed without giving the users a
break - as I update my Debian installation weekly I didn't run into the
problems you describe. Ok, enough not Modula-2 related talk for me -

David Given

unread,
Aug 4, 2010, 3:18:13 PM8/4/10
to
On 03/08/10 21:41, aaaaaaaaaaaaaaaaaaaaaaaaaa wrote:
> On Aug 3, 7:01 pm, Duke Normandin <dukeofp...@ml1.net> wrote:
>
>> So that should fix the compile problem I had?
>
> Yes.

Now fixed: you can get the new version here:

https://sourceforge.net/projects/tack/files/

It's great that there's all this interest in the ACK, but I should warn
you that there are a few rather major problems:

- it's *old*. It predates most modern, useful, ABI standards --- like
ELF, debuggers, shared libraries, etc. Right now it only generates
linux386 binaries because of a hacky tool I wrote that converts ACK
object files into marginly-compliant ELF files.

- it's limited. Because it doesn't understand Linux libraries, it
doesn't have access to any sophisticated functionality --- it can only
just make system calls! You can see what's supported by looking in
plat/linux386/libsys.

- it's difficult to develop for. The underlying architecture of the ACK
is interesting but fundamentally flawed which means there's very
unlikely to be new code generators for it --- I spent several months
trying to produce a PowerPC code generator some years back, and
eventually gave up because the code generator architecture can't really
cope with registers.

So you should be aware of what you're getting yourself into!

That said, if anyone wants to adopt the Modula-2 backend and do
bugfixes, enhancements, etc I'd be delighted to accept them. Also,
there's a whole bunch more code generators that the ACK supports that
aren't currently enabled --- if anyone has a real machine that supports
one, such as 68000, I can turn it on --- but you'll have to write the
syscall library yourself.

Incidentally, I note that the example Modula-2 program in
examples/hilo.mod doesn't work properly; it doesn't flush the output
buffers before prompting the user for input. The C version calls
fflush(stdout), but there doesn't seem to be a Modula-2 version of this
in InOut. Any ideas?

--
┌─── dg@cowlark.com ───── http://www.cowlark.com ─────

│ "Home is where, when you have to go there, they have to take you in."
│ --- Cordelia Naismith

Duke Normandin

unread,
Aug 4, 2010, 6:07:24 PM8/4/10
to
On 2010-08-04, David Given <d...@cowlark.com> wrote:
> On 03/08/10 21:41, aaaaaaaaaaaaaaaaaaaaaaaaaa wrote:
>> On Aug 3, 7:01 pm, Duke Normandin <dukeofp...@ml1.net> wrote:
>>
>>> So that should fix the compile problem I had?
>>
>> Yes.
>
> Now fixed: you can get the new version here:
>
> https://sourceforge.net/projects/tack/files/

Thank you!

>
> It's great that there's all this interest in the ACK, but I should warn
> you that there are a few rather major problems:

[snip]

> So you should be aware of what you're getting yourself into!

[snip]

I appreciate your candor and warnings. I might have to pass!

aaaaaaaaaaaaaaaaaaaaaaaaaa

unread,
Aug 5, 2010, 4:04:21 AM8/5/10
to
On Aug 4, 9:18 pm, David Given <d...@cowlark.com> wrote:

> Incidentally, I note that the example Modula-2 program in
> examples/hilo.mod doesn't work properly; it doesn't flush the output
> buffers before prompting the user for input. The C version calls
> fflush(stdout), but there doesn't seem to be a Modula-2 version of this
> in InOut. Any ideas?

It's already there, in Streams. Streams.FlushStream?

I wrote my own (WriteBf) for the dis05 disassembler.

PROCEDURE WriteBf;

VAR strus : Streams.StreamResult;

BEGIN
Streams.FlushStream (Streams.OutputStream, strus)
END WriteBf;

Works fine!

The lack of existing libraries simply means we can better ones right
away!

aaaaaaaaaaaaaaaaaaaaaaaaaa

unread,
Aug 5, 2010, 1:30:03 PM8/5/10
to
On Aug 4, 9:18 pm, David Given <d...@cowlark.com> wrote:

> It's great that there's all this interest in the ACK, but I should warn
> you that there are a few rather major problems:

Minor problemmettes.

> - it's *old*.

I am older!

> Right now it only generates linux386 binaries because of a hacky tool
> I wrote that converts ACK object files into marginly-compliant ELF files.

One of the guys here is probably smart enough to make a better one.
Some are creating the n-th Modula-2 compiler, so that, in a few years,
every Modula-2 programmer can work with his private compiler.

> - it's limited. Because it doesn't understand Linux libraries, it
> doesn't have access to any sophisticated functionality

Same with Mocka. Mock has Foreign Modules. ACK too, if I am right. And
instead of making the (n+1)-th Modula-2 compiler, perhaps it pays
better off to overhaul a classic compiler.

> - it's difficult to develop for. The underlying architecture of the ACK
> is interesting but fundamentally flawed which means there's very
> unlikely to be new code generators for it --- I spent several months
> trying to produce a PowerPC code generator some years back, and
> eventually gave up because the code generator architecture can't really
> cope with registers.

The compiler generates EM code. Each backend seems to be a translator
from EM code to machine code.

> So you should be aware of what you're getting yourself into!

A nice adventure! Like riding to Santiago de Comnpostella on your
fixed speed city bicycle!

> That said, if anyone wants to adopt the Modula-2 backend and do
> bugfixes, enhancements, etc I'd be delighted to accept them. Also,
> there's a whole bunch more code generators that the ACK supports that
> aren't currently enabled --- if anyone has a real machine that supports
> one, such as 68000, I can turn it on --- but you'll have to write the
> syscall library yourself.

Is the source included?

> Any ideas?

Already solved this, last morning, before I turned myself into Postman
Pat again. I'm back to normal again. :o)

I think it is awesome to have ONE compiler for both C, Pascal and
Modula-2. It would be a shame to let it die. People on this list know
that I'm not too fond of Not-so-modula-2-ish-Modula-2-compilers. I
need no OOP. OOP is already in Modula-2. The majority of the safety
mechanisms of Java relate directly to Modula-2 and Oberon. So why
incorporate unsafe and unclear mechanisms when there's a good compiler
waiting for some maintenance?
The PC platform has been evolving for 30 years now. And still I can
run DOS on it. A similar thing should apply for the ACK.

Marco van de Voort

unread,
Aug 5, 2010, 2:27:04 PM8/5/10
to
On 2010-08-05, aaaaaaaaaaaaaaaaaaaaaaaaaa <jan...@gmail.com> wrote:
>> I wrote that converts ACK object files into marginly-compliant ELF files.
>
> One of the guys here is probably smart enough to make a better one.
> Some are creating the n-th Modula-2 compiler, so that, in a few years,
> every Modula-2 programmer can work with his private compiler.

Well, actually this kind of stuff is why I moved from a M2 compiler (topspeed ) to a pascal
compiler (FPC for hobby, Delphi for professional life).

It was not a preference for that language, but general compiler (+libs)
quality, as well as jobs.

As a dialect/language, I was perfectly happy with M2.

> Same with Mocka. Mock has Foreign Modules. ACK too, if I am right. And
> instead of making the (n+1)-th Modula-2 compiler, perhaps it pays
> better off to overhaul a classic compiler.

Two wrongs don't make a right

> The compiler generates EM code. Each backend seems to be a translator
> from EM code to machine code.

... but it must exist, and I still have a m68k, a G4 and G5.

>> So you should be aware of what you're getting yourself into!
>
> A nice adventure! Like riding to Santiago de Comnpostella on your
> fixed speed city bicycle!

If you like pain, it is easier to ask sb to give you a good whipping
sometimes. In Amsterdam, that shouldn't be that much of a problem :-)

>> aren't currently enabled --- if anyone has a real machine that supports
>> one, such as 68000, I can turn it on --- but you'll have to write the
>> syscall library yourself.

I still have a 840AV, and these can be obtained fairly cheap. The problem
is that nearly all old m68k's are SCSI, and these discs are expensive, and
the cheap ones are so old that you burn one per year.

If sb has good experience with some scsi2 to sata converter (even if it
costs say Eur 70) or so, I'm willing to gamble that.

The 840AV is interesting because it takes 128MB of fairly affordable 72pins
memory, and runs Linux fine (with MACOS as bootloader)

> I think it is awesome to have ONE compiler for both C, Pascal and
> Modula-2. It would be a shame to let it die

Then start contributing. Yes, everybody things the compiler is magic that
only higher magicians can, but it is like swimming. We all have to go into
the water the first time. Hard work can make up for talent perfectly fine
(*)

(*) as far as compilers go, I'm in the hard work category unfortunately.

> mechanisms of Java relate directly to Modula-2 and Oberon. So why
> incorporate unsafe and unclear mechanisms when there's a good compiler
> waiting for some maintenance?

Learn more about compilers. Compile trees with their polymorphic nodes are
the perfect opportunity to learn about OO. And no, OO is no cure all, but it
can help.

> The PC platform has been evolving for 30 years now. And still I can
> run DOS on it.

(I hope that doesn't last that long anymore, the workarounds for BIOS
compatibility are getting painful. Give me EFI any day)


aaaaaaaaaaaaaaaaaaaaaaaaaa

unread,
Aug 5, 2010, 4:48:33 PM8/5/10
to
On Aug 4, 9:18 pm, David Given <d...@cowlark.com> wrote:

> Incidentally, I note that the example Modula-2 program in
> examples/hilo.mod doesn't work properly; it doesn't flush the output
> buffers before prompting the user for input. The C version calls
> fflush(stdout), but there doesn't seem to be a Modula-2 version of this
> in InOut. Any ideas?

I published a working version of HiLo: http://fruttenboel.verhoeven272.nl/ack/test7.html

Works fine.

aaaaaaaaaaaaaaaaaaaaaaaaaa

unread,
Aug 5, 2010, 4:51:06 PM8/5/10
to
On Aug 5, 8:27 pm, Marco van de Voort <mar...@turtle.stack.nl> wrote:

> As a dialect/language, I was perfectly happy with M2.

Then stick with it.

> Two wrongs don't make a right

But two lefts do :o)

> ... but it must exist, and I still have a m68k, a G4 and G5.

The Mac is dead. It turned into a status symbol. To accompany the
iPhone and such.

> If you like pain, it is easier to ask sb to give you a good whipping

Who is sb? Steven Blom?

Or Steven Pemberton?

David Given

unread,
Aug 5, 2010, 6:25:38 PM8/5/10
to
On 05/08/10 21:48, aaaaaaaaaaaaaaaaaaaaaaaaaa wrote:
[...]

> I published a working version of HiLo: http://fruttenboel.verhoeven272.nl/ack/test7.html

Merged and checked in; thanks!

David Given

unread,
Aug 5, 2010, 6:36:55 PM8/5/10
to
On 05/08/10 18:30, aaaaaaaaaaaaaaaaaaaaaaaaaa wrote:
[...]

>> - it's difficult to develop for. The underlying architecture of the ACK
>> is interesting but fundamentally flawed which means there's very
>> unlikely to be new code generators for it --- I spent several months
>> trying to produce a PowerPC code generator some years back, and
>> eventually gave up because the code generator architecture can't really
>> cope with registers.
>
> The compiler generates EM code. Each backend seems to be a translator
> from EM code to machine code.

Specifically, there are two big problems: firstly, it seems to be very
unwilling to cache values in registers between statements. This isn't a
problem on old CISC systems like x86 or 8080, as there aren't enough
registers to be worth sving stuff in most of the time; but on RISC
platforms like PowerPC and ARM it was generating terrible code.

Secondly, it cannot distinguish between different register classes if
they're the same size! When I was trying to make the PowerPC code
generator work, I discovered that I couldn't add floating point support:
it would either store all floats in integer registers and shuffle them
into float registers to do work and then back again, or else store all
integers in float registers and shuffle etc, depending on the order I
defined them in the code generator definition file.

In addition, the EM spec defines lots of things it shouldn't be, making
a lot of optimisations impossible. (A large number of EM instructions
*only* take parameters on the stack, not in registers.) Again, on the
old CISC machines, this wasn't a problem, as they were very
stack-centric... not so good on modern machines.

Trying to overhaul the code generator library would basically involve
rewriting it from scratch, and it's just not worth the effort. (But that
doesn't mean that what's there now isn't useful.)

Now, taking the ACK Modula-2 front end and porting it to use the LLVM
backend; that could be worthwhile...

[...]


>> That said, if anyone wants to adopt the Modula-2 backend and do
>> bugfixes, enhancements, etc I'd be delighted to accept them. Also,
>> there's a whole bunch more code generators that the ACK supports that
>> aren't currently enabled --- if anyone has a real machine that supports
>> one, such as 68000, I can turn it on --- but you'll have to write the
>> syscall library yourself.
>
> Is the source included?

Yup; look in plat/*/libsys. The pc86 one is a good place to start
because it's about as minimal as it gets (most functions are stubs).
Right now they're written in C and assembler, but as it's all compiled
with the ACK itself, there's no reason why you couldn't write bits in
Modula-2, if you could figure out the linkages.

Jean-Pierre

unread,
Aug 5, 2010, 8:51:06 PM8/5/10
to
aaaaaaaaaaaaaaaaaaaaaaaaaa a écrit:

> One of the guys here is probably smart enough to make a better one.
> Some are creating the n-th Modula-2 compiler, so that, in a few years,
> every Modula-2 programmer can work with his private compiler.

And why is that any of your business?

Suppose you are mowing your lawn and your lazy neighbour shouts over
the fence "Hey, dumbo, come over here, I need my lawn mowed, do my
lawn, not yours!". Are you going to do what he says? Somehow, I doubt
you would.

> instead of making the (n+1)-th Modula-2 compiler, perhaps it pays
> better off to overhaul a classic compiler.

The keyword word there is: "perhaps".

Perhaps those who work on other compilers did check ACK first and
found like David Given said "it requires major rewrites, it's not
worth the effort".

Perhaps, those who work on other compilers did get funded to do so.
Perhaps nobody provided any funding for maintenance on ACK. Perhaps
you should offer funding the effort to do so.

Perhaps, those who work on other compilers have been asked nicely to
do so. Perhaps nobody asked them nicely to do maintenance on ACK.
Perhaps you should stop bitching and ask nicely instead.

Perhaps, those who work on other compilers do so because its part of
their university course work or masters or PhD thesis. Perhaps
maintenance on ACK wasn't offered to them as a choice.

Whatever the reasons are that others don't do what you want them to
do, perhaps you should do the work you want others do to for you by
yourself.

I don't know anything about making or fixing compilers, but I know
that if I did, I would not want to work on a compiler where users are
bitching and tell me what I should and shouldn't do in my free time. I
would say "fix it yourself".

JP

Marco van de Voort

unread,
Aug 5, 2010, 10:12:50 PM8/5/10
to
On 2010-08-05, aaaaaaaaaaaaaaaaaaaaaaaaaa <jan...@gmail.com> wrote:
> On Aug 5, 8:27 pm, Marco van de Voort <mar...@turtle.stack.nl> wrote:
>
>> As a dialect/language, I was perfectly happy with M2.
>
> Then stick with it.

There is more than just language.

>> Two wrongs don't make a right
>
> But two lefts do :o)

Two left feet suck too.

>> ... but it must exist, and I still have a m68k, a G4 and G5.
>
> The Mac is dead. It turned into a status symbol. To accompany the
> iPhone and such.

Then take e.g. arm.

>> If you like pain, it is easier to ask sb to give you a good whipping
>
> Who is sb? Steven Blom?

Somebody.

Marco van de Voort

unread,
Aug 5, 2010, 10:16:13 PM8/5/10
to
On 2010-08-06, Jean-Pierre <jpl...@yahoo.com> wrote:
> I don't know anything about making or fixing compilers, but I know
> that if I did, I would not want to work on a compiler where users are
> bitching and tell me what I should and shouldn't do in my free time. I
> would say "fix it yourself".

(well, don't even try to start working on compilers then. Bitching users
are pretty much a given)

aaaaaaaaaaaaaaaaaaaaaaaaaa

unread,
Aug 6, 2010, 3:39:34 AM8/6/10
to
On Aug 6, 12:36 am, David Given <d...@cowlark.com> wrote:

> Specifically, there are two big problems: firstly, it seems to be very
> unwilling to cache values in registers between statements. This isn't a
> problem on old CISC systems like x86 or 8080, as there aren't enough
> registers to be worth sving stuff in most of the time; but on RISC
> platforms like PowerPC and ARM it was generating terrible code.

In Compiler Construction, Wirth gives an example for code generation
with a processor with 32 full width registers

http://www-old.oberon.ethz.ch/WirthPubl/CBEAll.pdf

Perhaps a nice hint....

> Secondly, it cannot distinguish between different register classes if
> they're the same size! When I was trying to make the PowerPC code
> generator work, I discovered that I couldn't add floating point support:
> it would either store all floats in integer registers and shuffle them
> into float registers to do work and then back again, or else store all
> integers in float registers and shuffle etc, depending on the order I
> defined them in the code generator definition file.

I see the Mac more and more as an accessorie to bling bling besides an
iPod and an iPhone... Too bad since the Mac used to be a serious
system. Perhaps (at first) concentrate on 80386 or 80486 code.

> In addition, the EM spec defines lots of things it shouldn't be, making
> a lot of optimisations impossible. (A large number of EM instructions
> *only* take parameters on the stack, not in registers.) Again, on the
> old CISC machines, this wasn't a problem, as they were very
> stack-centric... not so good on modern machines.

Is there a compiler switch that leaves the generated Em files intact?
I'd like to look at them. First for learning about them, then for an
optimized (human readable) version and then, later, for optimisation
and then, perhaps, ever, a new code generator.

EM is a stack machine. That is the easiest way to generate code from a
source doing a recursive descent parser. Like my Plov
http://fruttenboel.verhoeven272.nl/m4m/index.html

> Trying to overhaul the code generator library would basically involve
> rewriting it from scratch, and it's just not worth the effort. (But that
> doesn't mean that what's there now isn't useful.)

You'e a young man with a future. I'm old(er) with a history. I don't
mind reliving part of my history. And there are others on this list in
the same situation. Perhaps we could team up. And once a year meat in
San Diego.... Or Zuerich.

> Now, taking the ACK Modula-2 front end and porting it to use the LLVM
> backend; that could be worthwhile...

Then go for it. You can't always do sensible things. Life is too short
for that.

> Yup; look in plat/*/libsys. The pc86 one is a good place to start
> because it's about as minimal as it gets (most functions are stubs).
> Right now they're written in C and assembler, but as it's all compiled
> with the ACK itself, there's no reason why you couldn't write bits in
> Modula-2, if you could figure out the linkages.

OK, later. First I have my postman pat role coming up.

aaaaaaaaaaaaaaaaaaaaaaaaaa

unread,
Aug 6, 2010, 3:43:00 AM8/6/10
to
On Aug 6, 2:51 am, Jean-Pierre <jpl...@yahoo.com> wrote:

> And why is that any of your business?

Touchy... Or Touche'?

> Perhaps, those who work on other compilers did get funded to do so

Aha. Nowwe're getting somewhere. Most people are on this list for
their love and admiration for a very nice language. Not for the
money.

> JP

That's how are prime minister is called...

aaaaaaaaaaaaaaaaaaaaaaaaaa

unread,
Aug 6, 2010, 3:44:56 AM8/6/10
to
On Aug 6, 4:12 am, Marco van de Voort <mar...@turtle.stack.nl> wrote:

> There is more than just language.

Then you are not a geek.

> >> Two wrongs don't make a right
>
> > But two lefts do :o)

It was THREE lefts....

> Two left feet suck too.

I believe you on your word!

Marco van de Voort

unread,
Aug 6, 2010, 4:30:30 AM8/6/10
to
On 2010-08-06, aaaaaaaaaaaaaaaaaaaaaaaaaa <jan...@gmail.com> wrote:
>> unwilling to cache values in registers between statements. This isn't a
>> problem on old CISC systems like x86 or 8080, as there aren't enough
>> registers to be worth sving stuff in most of the time; but on RISC
>> platforms like PowerPC and ARM it was generating terrible code.
>
> In Compiler Construction, Wirth gives an example for code generation
> with a processor with 32 full width registers
>
> http://www-old.oberon.ethz.ch/WirthPubl/CBEAll.pdf
>
> Perhaps a nice hint....

Changing the method of register allocation is usually nothing short of a
complete rewrite of the codegenerator. But your remarks were about using the
old compiler, not starting yet another one.

FPC did this from 1.0 to 2.0, and it took 5 years.

The reasons to rewrite then were that the cg and regalloc relied on having 3
free general purpose registers between blocks, which constantly broke,
because it had to be guaranteed by hand.

The other was that dividing registers (ax->eax) was a hack. Since we started
from nothing, more architecture independance was also needed.

And most other CG parts interact with the codegenerator...

Such a casual remark might sound great to score points in a discussion, but
people that would begin some adventure like this, know these kinds of stuff
already. The internet is full of papers on register colouring.

Worse, any new architecture that you add has its own quirks. m68k with its
address only registers, sparc with its delay slots, arm needs all data
aligned (older powerpcs like 603 were no picking in that department either
btw).

>> Secondly, it cannot distinguish between different register classes if
>> they're the same size! When I was trying to make the PowerPC code
>> generator work, I discovered that I couldn't add floating point support:
>> it would either store all floats in integer registers and shuffle them
>> into float registers to do work and then back again, or else store all
>> integers in float registers and shuffle etc, depending on the order I
>> defined them in the code generator definition file.

(What about the x87 codegeneration? Or didn't you keep anything in regs
because it is stack based?)

> I see the Mac more and more as an accessorie to bling bling besides an
> iPod and an iPhone...

Naah, it always was, it is just more obvious now, and went from OS bling to
hardware bling :-)

> Too bad since the Mac used to be a serious system. Perhaps (at first)
> concentrate on 80386 or 80486 code.

I would focus on x86_64 code. Easier, more regs, and by the time you are
finished, x86 is legacy.

>> Now, taking the ACK Modula-2 front end and porting it to use the LLVM
>> backend; that could be worthwhile...
>
> Then go for it. You can't always do sensible things. Life is too short
> for that.

In this type of sport, doing something insensible is more like insanity. It
is just too much work to be frivolous about it.

That's why doing more than minimal maintenance on older compilers, while
often begged for by users, is usually not a good idea.

On the other hand, be wary of people that say they have a perfect and
cleanly implemented compiler. It is with near complete certainty unusable.

Marco van de Voort

unread,
Aug 6, 2010, 4:31:54 AM8/6/10
to
On 2010-08-06, aaaaaaaaaaaaaaaaaaaaaaaaaa <jan...@gmail.com> wrote:
>> There is more than just language.
>
> Then you are not a geek.

Is that a compliment or an insult? Or am I merely a geek which has to manage
time?

Anyway, you didn't comment on the main bit in this thread, why don't you
start working on compilers (be it fixing or implementing one) yourself?

David Given

unread,
Aug 6, 2010, 2:39:20 PM8/6/10
to
On 06/08/10 08:39, aaaaaaaaaaaaaaaaaaaaaaaaaa wrote:
[...]

> Is there a compiler switch that leaves the generated Em files intact?
> I'd like to look at them. First for learning about them, then for an
> optimized (human readable) version and then, later, for optimisation
> and then, perhaps, ever, a new code generator.

Yes; compile stuff with the -c.e parameter, and it'll emit .e EM source.

There's a rather basic reference in the 'em' document here:

http://tack.sourceforge.net/olddocs.html

(You want the PDF version, not the HTML version --- the formatting
didn't make it through the conversion process intact.)

> EM is a stack machine. That is the easiest way to generate code from a
> source doing a recursive descent parser.

Correct. *But*, modern processors are not stack machines, which is why
code generators for modern architectures live or die by their ability to
do register allocation.

Some of EM's specification make it impossible to do this well. For
example, the ABI specification *requires* parameters and locals to be
stored on the physical stack, which means that if you're on a machine
that wants to pass parameters in registers you're out of luck.

And while there's an engine in place to analyse the EM expression stack
and map it to registers, the EM spec allows you to manipulate the stack
at will, *including* modifying by variable amounts at runtime. These are
impossible to analyse and completely wrecks the ability for the ACK code
generator to produce good code.

If you look at systems like the JVM, you'll see that they're very
careful to forbid this kind of thing --- the JVM guarantees, for
example, that you can predict ahead of time the stack offset for every
byte of code. This allows JVM bytecode to be compiled into native code
efficiently (and modern JITs are really, really good).

EM combines the worst of two worlds, where it's both high-level but also
dictates details of the low-level machine, which vastly restricts the
opportunity to produce code that's anyone near acceptable on platforms
that differ from its expectations.

aaaaaaaaaaaaaaaaaaaaaaaaaa

unread,
Aug 6, 2010, 4:10:14 PM8/6/10
to
On Aug 6, 10:31 am, Marco van de Voort <mar...@turtle.stack.nl> wrote:

> > Then you are not a geek.
>
> Is that a compliment or an insult? Or am I merely a geek which has to manage
> time?

Would you like to be insulted? In that case, bad luck for you. I never
insult people. Unless I do, but then you will NEVER have to ask
yourself that question. So, the fact that you -DID- ask, is answer
enough, I guess...
Some people read a lot of things between the lines. But between the
lines is only your own personal prejudice...

> Anyway, you didn't comment on the main bit in this thread, why don't you
> start working on compilers (be it fixing or implementing one) yourself?

I wrote my own compiler. It compiles to a kind of EM code. It is
targeted at micro controllers only. Look for m4m or Plov. It's a long
lasting project.

aaaaaaaaaaaaaaaaaaaaaaaaaa

unread,
Aug 6, 2010, 4:19:53 PM8/6/10
to
On Aug 6, 8:39 pm, David Given <d...@cowlark.com> wrote:

> Yes; compile stuff with the -c.e parameter, and it'll emit .e EM source.

OK Thanks for that.

> (You want the PDF version, not the HTML version --- the formatting
> didn't make it through the conversion process intact.)

I managed to find a PS file called IR81a that houlds a description of
EM. But its 83 pages...

> Correct. *But*, modern processors are not stack machines, which is why
> code generators for modern architectures live or die by their ability to
> do register allocation.

The Z80 was no stack processor either. Forth is a typical stack
language. Yet many Forth interpreters were implemented on CP/M
machines. Even on the Jupiter Ace! Just reserve a few registers for a
data stack, an operations stack and a return stack. The other
registers can be used by dedicated routines.

> Some of EM's specification make it impossible to do this well. For
> example, the ABI specification *requires* parameters and locals to be
> stored on the physical stack, which means that if you're on a machine
> that wants to pass parameters in registers you're out of luck.

Then you need a seperate call interface.

> And while there's an engine in place to analyse the EM expression stack
> and map it to registers, the EM spec allows you to manipulate the stack
> at will, *including* modifying by variable amounts at runtime. These are
> impossible to analyse and completely wrecks the ability for the ACK code
> generator to produce good code.

Hmm.

I may need to contact AST and CJ about this.

I'm going to take closer look at the Em files first.

aaaaaaaaaaaaaaaaaaaaaaaaaa

unread,
Aug 7, 2010, 3:03:50 AM8/7/10
to
On Aug 6, 8:39 pm, David Given <d...@cowlark.com> wrote:
> On 06/08/10 08:39, aaaaaaaaaaaaaaaaaaaaaaaaaa wrote:
> [...]

> Yes; compile stuff with the -c.e parameter, and it'll emit .e EM source.

This did not produce any results on my 6.0pre3 release:

Hmm, strange. Now it does... Here's the correct comamnd line:

jan@Beryllium:~/modula/AVR/dis$ ack -c.e dis05.mod

which produces a dis05.e file.

The disassembler compiles to a 50 KB file so that is too much. I'll
have to make some very small executables first to see how to cope with
the EM codes. Perhaps the C compiler makes smaller sources.

noch

unread,
Aug 7, 2010, 8:25:51 AM8/7/10
to
On Aug 1, 1:55 am, aaaaaaaaaaaaaaaaaaaaaaaaaa <jan...@gmail.com>
wrote:
> Gents,
>
> I spent some time again with Minix and the excellent ACK compiler. It
> has multiple front ends: for Pascal, C and Modula-2. So I got the
> current version of ACK for Linux, compiled it and installed it.
>
> WOOWW! The ACK blows you out of your socks! This is a very very good
> Modula-2 compiler. It outperforms Mocka for a few tests that I did.
> Seehttp://fruttenboel.verhoeven272.nl/ack/index.htmlfor some more
> details

Just curious: did you ever consider to try GNU Modula-2?
I guess you will be far more excited than now if you try it :)

noch

unread,
Aug 7, 2010, 8:27:10 AM8/7/10
to
On Aug 1, 1:55 am, aaaaaaaaaaaaaaaaaaaaaaaaaa <jan...@gmail.com>
wrote:
> Gents,
>
> I spent some time again with Minix and the excellent ACK compiler. It
> has multiple front ends: for Pascal, C and Modula-2. So I got the
> current version of ACK for Linux, compiled it and installed it.
>
> WOOWW! The ACK blows you out of your socks! This is a very very good
> Modula-2 compiler. It outperforms Mocka for a few tests that I did.
> Seehttp://fruttenboel.verhoeven272.nl/ack/index.htmlfor some more
> details

>>Is it free?

>>>Yes. As of 2003, the ACK is in the Public Domain or on a GPL
No, not gpl. It is opened under BSD. Which matters for me, for
example :)

aaaaaaaaaaaaaaaaaaaaaaaaaa

unread,
Aug 8, 2010, 5:24:57 PM8/8/10
to
On Aug 7, 2:25 pm, noch <chno...@gmail.com> wrote:

> Just curious: did you ever consider to try GNU Modula-2?

Yes, a few years ago I did. It was a pain to download and install. It
required a gcc version from the early Cretacious to get running and
lots of other things that hinted, that it was not a Modula-2 compiler
but a new M2C translator.
When I eventually got it running it was as slow as a turd in a funnel
(dutch proverb) so I stayed loyal to Mocka. Which in itself is an
excellent Modula-2 compiler.
All in all, I expressed my disappointment about it on this (or
another) list and some people still blame me for giving my opinion.

> I guess you will be far more excited than now if you try it :)

Then a lot of things must have changed in the mean time. Are there
websites (of independant users) that come up with examples and
experiences? Something like I do on my website?

aaaaaaaaaaaaaaaaaaaaaaaaaa

unread,
Aug 8, 2010, 5:26:14 PM8/8/10
to
On Aug 7, 2:27 pm, noch <chno...@gmail.com> wrote:
>
> No, not gpl. It is opened under BSD. Which matters for me, for
> example :)

You prefer the WTFPL? Why would a license bother you?

Norayr Chilingarian

unread,
Aug 8, 2010, 5:37:38 PM8/8/10
to
On Aug 9, 2:26 am, aaaaaaaaaaaaaaaaaaaaaaaaaa <jan...@gmail.com>
wrote:

I prefer GPL compiler with LGPL libraries.
GM2 has a community. It is the only compiler which implements whole
(or almost whole) ISO library set.
Yes, it is based on gcc, and gcc is slow, but instead, very optimizing
compiler.
It has so many backends, that you will probably satisfied.
It has nice architecture, where everybody can add it's own backend cpu
or frontend language.
And this is why it is possible to build gm2 for avr compiler. The only
problem - lack of avr specific libraries, but you can easily write
your won libs by using asm or bind to existing c libraries.
And it is very easy to install because there is an apt repo and you
only need to drop a line in /etc/apt/sources.list and apt-get update;
apt-get install gm2 :)

Marco van de Voort

unread,
Aug 8, 2010, 5:44:18 PM8/8/10
to
On 2010-08-08, Norayr Chilingarian <chn...@gmail.com> wrote:
>> You prefer the WTFPL? Why would a license bother you?
>
> I prefer GPL compiler with LGPL libraries.

Almost enough. (L)GPL with static linking exception or better (e.g. 3 clause
BSD). You don't want to have to package each and every package into a
separate dynamic library.

B. Kowarsch

unread,
Aug 9, 2010, 1:59:36 AM8/9/10
to
Norayr Chilingarian wrote:

> GM2 has a community. It is the only compiler which implements whole
> (or almost whole) ISO library set.

That last bit is not correct. There are several other compilers who
support ISO including the ISO library: Mod51, p1, XDS, possibly
TopSpeed and MaX too. In fact, IIRC, p1 is the only compiler that
supports the full ISO standard (IS 10514-1/2/3).

You may also want to consider that not everybody considers ISO a must-
have feature. Opinions are divided.

> It [=>GCC] has nice architecture, where everybody can add it's own backend cpu
> or frontend language.

Have you have ever tried to do that yourself. I have never come across
any GCC front-end maintainer who would characterise GCC to have a
"nice" architecture. Many maintainers curse it. Even the most loyal
GCC hackers will generally conceit that there is a lot of cruft in
GCC.

The fact that GNU Modula-2 is still reliant on an older version of GCC
is testament to the difficulties involved to keeping front-ends
synchronised with the code-base.

That is not to say that GNU Modula-2 hasn't made laudable progress. To
the contrary, the difficulties involved in maintaining a GCC front-end
make Gaius' achievements all the more impressive.

> And it is very easy to install because there is an apt repo and you
> only need to drop a line in /etc/apt/sources.list and apt-get update;
> apt-get install gm2 :)

To be fair, it should be noted that the compiler is still under
development. If you need to build it yourself, then it is not as
simple and in fact the build may fail altogether. There are a number
of reasons why you may need to build it yourself. For example if, as
you suggested you want to supply your own target, or if you need it on
a platform for which no current binary package is yet available, or if
you run into a bug that Gaius has only recently fixed in a version for
which there is no binary package yet available.

Sure, this is to be expected for any compiler under development but
bear in mind that the original poster has made comments of the kind
that suggest he is rather less likely to have the patience required
when using a tool that hasn't reached release status yet.

aaaaaaaaaaaaaaaaaaaaaaaaaa

unread,
Aug 9, 2010, 5:29:33 AM8/9/10
to
On Aug 8, 11:37 pm, Norayr Chilingarian <chno...@gmail.com> wrote:

> I prefer GPL compiler with LGPL libraries.

OK. I think it won't matter that much as long as you use products of
hobbyists or people who are not out to make a living.

> GM2 has a community. It is the only compiler which implements whole
> (or almost whole) ISO library set.

The first part is interesting. ISO cannot please me very much. just
PIM would be fine to me.

> Yes, it is based on gcc, and gcc is slow, but instead, very optimizing
> compiler.

Is it still the 2.95 version I had to install, next to the 3.x that
Slackware was already using at that time? Or will it use any gcc
version by now?

> And this is why it is possible to build gm2 for avr compiler.

Well, that of course, is very interesting then. Hmm. It looks like
your kind words convinced me to try something out once more. Thanks
for that. I like kind words.

> The only problem - lack of avr specific libraries,

Most AVR systems are one-ofs. Only some (like the Arduino, or the ETT
range of micro's) are mass produced. If one is familiar with MCU's
making a dedicated library would pose no real problem. No, it would
open up a lot of opportunities. Create your own board with your own
GM2 environment. And publish it under the BSD license. Or the WTFPL.

> And it is very easy to install because there is an apt repo and you
> only need to drop a line in /etc/apt/sources.list and apt-get update;
> apt-get install gm2 :)

I'm a slackware guy. Is there a tgz file? Did you ask Alien Bob to
make a package out of it? Alien Bob is a nice guy. Perhaps I ougfht to
give it a try. Perhaps even make a tgz package out of it.

Thanks for the inspiring answer.

Marco van de Voort

unread,
Aug 9, 2010, 5:46:31 AM8/9/10
to
On 2010-08-09, B. Kowarsch <bk.usenet....@gmail.com> wrote:

(the fun part is that with a few substitutions (M2->pascal, P1->P5) this
post is still entirely valid)

>> It [=>GCC] has nice architecture, where everybody can add it's own backend cpu
>> or frontend language.
>
> Have you have ever tried to do that yourself. I have never come across
> any GCC front-end maintainer who would characterise GCC to have a
> "nice" architecture. Many maintainers curse it. Even the most loyal
> GCC hackers will generally conceit that there is a lot of cruft in
> GCC.

A similar debate is now raging in the GNU Pascal list:
http://www2.gnu-pascal.de/crystal/gpc/en/

starting with

http://www2.gnu-pascal.de/crystal/gpc/en/mail14666.html

One of the main reasons is the macro based treenode stuff.

> The fact that GNU Modula-2 is still reliant on an older version of GCC
> is testament to the difficulties involved to keeping front-ends
> synchronised with the code-base.

Same with GPC. There are some gcc 4 attempts, but they were not entirely
stable yet. And I've watched the project from a distance for over a decade
and can't remember a time that they didn't use a slightly aging compiler

(though only rarely _really_ old versions, so they did do constant work to
keep up).

Norayr Chilingarian

unread,
Aug 10, 2010, 4:55:31 AM8/10/10
to
On Aug 9, 10:59 am, "B. Kowarsch" <bk.usenet.posts.o...@gmail.com>
wrote:

> Norayr Chilingarian wrote:
> > GM2 has a community. It is the only compiler which implements whole
> > (or almost whole) ISO library set.
>
> That last bit is not correct. There are several other compilers who
> support ISO including the ISO library: Mod51, p1, XDS, possibly
> TopSpeed and MaX too. In fact, IIRC, p1 is the only compiler that
> supports the full ISO standard (IS 10514-1/2/3).
OK.
However, gm2 has a community. A lot of testers, and if you sunscribe
to mailing list, you will see how many fixes and tests being done.
Overall, work on gm2 is very active.

> You may also want to consider that not everybody considers ISO a must-
> have feature. Opinions are divided.

OK

> > It [=>GCC] has nice architecture, where everybody can add it's own backend cpu
> > or frontend language.
>
> Have you have ever tried to do that yourself. I have never come across
> any GCC front-end maintainer who would characterise GCC to have a
> "nice" architecture. Many maintainers curse it. Even the most loyal
> GCC hackers will generally conceit that there is a lot of cruft in
> GCC.

I personally prefer independent compiler. And once, when I was doing
mine, I described why I prefer to not use gcc, but write codegenerator
form scratch.
However,
a) - I consider gcc as a nice solution. Once you write a frontend, you
have the language on all (or almost all) supported architectures.
Of course it needs testing. And gm2 has a community which helps a lot.
b) - Let's not forget, that tack is not an independent compiler
itself. It is a compiler with pretty old architecture, not necessarily
best intermeddiate representation (virtual cpu opcodes versus trees in
gcc), and it is written in C.
Besides, gm2 frontend is written in Modula-2.

>
> The fact that GNU Modula-2 is still reliant on an older version of GCC
> is testament to the difficulties involved to keeping front-ends
> synchronised with the code-base.

Gaius do a great job and as far as I see in mailing list, he manage to
sync compiler with latest gcc versions.

> That is not to say that GNU Modula-2 hasn't made laudable progress. To
> the contrary, the difficulties involved in maintaining a GCC front-end
> make Gaius' achievements all the more impressive.

Yep.


> > And it is very easy to install because there is an apt repo and you
> > only need to drop a line in /etc/apt/sources.list and apt-get update;
> > apt-get install gm2 :)
>
> To be fair, it should be noted that the compiler is still under
> development. If you need to build it yourself, then it is not as
> simple and in fact the build may fail altogether.

To be fair, I consider gm2 which is "in development" more stable, than
ack's modula-2 frontend.
It also has more featers, supports most language dialects, including
PIM's, able to compile Ulm libraries set, Logitech libraries set.
I would describe "ack" as a hobby/toy compiler compared to gm2/gcc
solution.
Besides, I appreciate work which David does.
I think that the world with one gcc and without mocka, tack, would be
gray.
Of course it is better to have *different* compilers, and different
implementations.
And people are different, they think different. That's why we have zoo
of languages, and zoo of compiler implementations.
That's nice :)
I was wondering why author of the first post in the thread does not
appreciate gm2, because I consider gm2 much better solution compared
to tack. If we keep in mind development for the modern computers.
Besides, he seem to be interested in microcontroller development, and
I think, that on the base of gm2 + avr libraries it is possible to
build a great alternative to the mainstream c based development.
However, I do not consider neither ack nor gm2 as perfect
implementation.
I personally would like to see modula-2 compiler which is gcc/ack/
other infrastructure independent. Like fpc team did.

aaaaaaaaaaaaaaaaaaaaaaaaaa

unread,
Aug 11, 2010, 5:41:55 AM8/11/10
to
Yesterday I downloaded a 52 MB GM2 tarball. That was the easy part.

After unpacking, the difficult part started. LOTS and lots of
documentation. I got the impression I was looking at a japanese user
manual. In japanese. Overdetailed information about anything I did not
want to know. The documentation was so overwhelming, I could not find
out where to start. The README file was not a README file but a
pointer to an array of pointers. Installing the ACK took some time,
but after reading a few files, it was clear and from then it was
rather straight forward.

So, after seeing scripts for 'configure' and a Makefile I jumped into
the deep. './configure' and then 'make'. The make started compiling.
ONE FULL HOUR later it was done. Judging the messages, it compiled a
new (or rather: an OLD) gcc tree on my system. At that point, I didn't
have the courage to type make install. What was about to happen with
my already installed gcc version 4.2.4? Would I get conflicts? I did
not want to risk anything here. It felt like standing at a gas
station, empty fuel tank and four unmarked filler outlets. Which one
was diessel? Which one is petrol?

So I quit. If installation is so darned difficult, operation won't be
easy as well. At no point reading the files I understood how the
compiler is started, or the role of gcc in gm2. I also got a bit scaed
that I, the user, would become responsible to tell which standard
(PIMx, ISO, etc) my sources would have to comply to.

Setting up the ACK took something like 20 minutes. Setting up Mocka
can be done in less than 10 minutes. I once installed XDS and as far
as I remember that also took less than 15 minutes. AND, most
importantly, the instructions to do so were clear from the beginning.

Jomu

unread,
Aug 11, 2010, 8:37:21 AM8/11/10
to
On Aug 11, 11:41 am, aaaaaaaaaaaaaaaaaaaaaaaaaa <jan...@gmail.com>
wrote:

> Yesterday I downloaded a 52 MB GM2 tarball. That was the easy part.
>
> After unpacking, the difficult part started. LOTS and lots of
> documentation. I got the impression I was looking at a japanese user
> manual. In japanese. Overdetailed information about anything I did not
> want to know. The documentation was so overwhelming, I could not find
> out where to start. The README file was not a README file but a
> pointer to an array of pointers. Installing the ACK took some time,
> but after reading a few files, it was clear and from then it was
> rather straight forward.

Looks like you had same problems with gm2 as I had with my plywood
plotter project. Mind you, I burnt all plywood and made rabbit cages
from it once I heard people are making Modula-2 R10, but before
plotter project I also did my time with gm2.

As I am using Fedora and rpms, and gm2 guy is GNU/Linux, meaning
Debian shop - I had to convert that .deb of his into .rpm of rebel
Fedora camp. Tried to convert it by some tool, then opened few files
and made rpm spec in 30 seconds.

Since then, it works as advertised.

Christoph Schlegel

unread,
Aug 11, 2010, 10:48:11 AM8/11/10
to

Hi,

http://www.nongnu.org/gm2/gm2.html#SEC31

The instructions to build and install GM2 are half a page of text.
Including instructions about an installation to a directory far away
from your pre-installed gcc (Debian GM2 binaries install cleanly to /opt)

Regards

Christoph

aaaaaaaaaaaaaaaaaaaaaaaaaa

unread,
Aug 12, 2010, 4:47:23 AM8/12/10
to
On Aug 11, 4:48 pm, Christoph Schlegel <modu...@gmx.net> wrote:
> Hi,
>
> http://www.nongnu.org/gm2/gm2.html#SEC31

this indeed is the easy page.

pity this was not in the README file. Now there was a disambiguity.

Oh well. Mocka is fine and so is the ACK. Two compilers is good enough
for me

Norayr Chilingarian

unread,
Aug 12, 2010, 7:29:07 AM8/12/10
to

http://www.nongnu.org/gm2/gm2.html#SEC31
Thanks for the link.
This is exactly what I meant.

> At that point, I didn't
>have the courage to type make install.

That's very wise.
make install would overwrite your existing files.
I usually add --prefix=/opt/gm2-version option.
./configure --prefix=
In order to make sure nothing will be overwritten.
After that make install will move files to the mentioned folder.
Then you need to call it like
/opt/gm2/bin/gm2
or
add /opt/gm2/bin to your PATH environment variable.
This was the hard way, you tried to follow.

Again, if you are using Debian based distribution I would advise to
try to install gm2 with apt-get.

Christoph Schlegel

unread,
Aug 12, 2010, 3:56:38 PM8/12/10
to
> Am 11.08.2010 11:41, schrieb aaaaaaaaaaaaaaaaaaaaaaaaaa:

[snip]

>> Setting up the ACK took something like 20 minutes. Setting up Mocka
>> can be done in less than 10 minutes. I once installed XDS and as far
>> as I remember that also took less than 15 minutes. AND, most
>> importantly, the instructions to do so were clear from the beginning.

[snip]

Don't forget it's the GNU compiler collection which builds ack for you -

aaaaaaaaaaaaaaaaaaaaaaaaaa

unread,
Aug 13, 2010, 4:38:09 AM8/13/10
to

I'll stick to mocka for production grade and the ACK for fun.

Neither GM2 nor R10 or any other 'current' compiler add something that
really matters.

Reply all
Reply to author
Forward
0 new messages