RE: Algol Front End

RE: Algol Front End

[Gaius Mulley]

> Steven Bosscher (07 May 2002 09:46:25 +0200) writes:
> Op di 07-05-2002, om 02:23 schreef Scott Robert Ladd:
>> As for other languages, I would be most interested in Modula-2,
>> given that I used that language extensively back in the 1980s. I
>> know it had some popularity in certain circles, especially in
>> Europe.
>
> It already exists, but I'm not sure how well it works.
>
> http://floppsie.comp.glam.ac.uk/Glamorgan/gaius/web/GNUModula2.html

we passed a milestone last Friday, gm2 was able to build itself on
a sparc platform. Until that point it had only built itself (fully)
on the *86 architecture. It is reliable enough to be used in its
own development (on these architectures at least)

Gaius

Re: Algol front end

[Robert Dewar]

> I believe that the amount of work needed to put either of them within the
> gcc framework is about the same. a68g has a transput implementation closer
> to that of the Revised Report on Algol68. ctrans uses the underlying C
> printf function. Neither implemented the book paradigm or formatted
> output, which is rather like having a C compiler without any printf
> functions or varargs. The parser would need to be interfaced to the new
> tree; something that is going to hamper attempts to bring gpc into the
> fold. Sothis is clearly not soemthing that will make 3.2.

I am amazed that anyone would even consider that this could "make 3.2".
There is a *lot* of work here. Ctrans is a starting point, but only that.
My students this last semester have been working on Algol-68S implementations
in the compiler class (the assignment was to write in Algol-68S, and generate
code for MMIX, and do a full bootstrap -- at least two students already
succeeded in completing the bootstrap :-)

Anyway, that's why I know quite a bit about Ctrans, since quite a few students
used Ctrans as the path to the bootstrap.

Re: Algol front end

[Trevor Jenkins]

On Tue, 14 May 2002, Robert Dewar wrote:

> > I believe that the amount of work needed to put either of them within the
> > gcc framework is about the same. a68g ... ctrans ...
> > The parser would need to be interfaced to the new
> > tree; something that is going to hamper attempts to bring gpc into the
> > fold. Sothis is clearly not soemthing that will make 3.2.
> 
> I am amazed that anyone would even consider that this could "make 3.2".

Nobody did. I was pointing out that any such idea would be
unachieveable. Also who apart from me wants it? ;-)

> There is a *lot* of work here. Ctrans is a starting point, but only that.

Yes, there's the support library to consider. As I say both a58g and
ctrans are incomplete in that respect.

Re: Algol Front end

[Robert Dewar]

Lars wrote

Something like this for the 32-bit case?

  int32_t
  add (int32_t x, int32_t y)
  {
    int32_t z = x + y;
    int32_t c;

    /* Carry out of the four bits, subcase 1.  */
    c = (x >> 3) & (y >> 3);

RObvert replies

Yes, right something like that :-)

Re: Algol Front end

[Arthur I Schwarz]

dewar@gnat.com (Robert Dewar) writes:
> Table lookup is not the way to go for packed decimal addition.
>
> Basically you want to do a standard addition, and then deal with the
> carries.
>
> There are two cases of carries
>
> 1. Where there is a carry out of the four bits. Two subcases here
>      100? + 100? => overflow, easily detected by an AND
>
>      1001 + 0111 (or vice versa), detectable by some sequence of
>      logical fiddling
>
> 2. Where the carry is within the four bits, i.e. the result is 11??
>    or 101?  (again detectable by some logical fiddling)
>
> That's as far as I have time to get right now, but starting from
> this, you can figure out a series of logical operations to effect
> the carry adjust.

Something like this for the 32-bit case?

  int32_t
  add (int32_t x, int32_t y)
  {
    int32_t z = x + y;
    int32_t c;

    /* Carry out of the four bits, subcase 1.  */
    c = (x >> 3) & (y >> 3);

    /* Carry out of the four bits, subcase 2.  */
    c |= (x >> 3) & x & (y >> 2) & (y >> 1) & y;
    c |= (y >> 3) & y & (x >> 2) & (x >> 1) & x;

    /* Carry within the four bits.  */
    c |= (z >> 3) & ((z >> 2) | (z >> 1));

    return z + 6 * (c & 0x11111111);
  }

--
Lars Brinkhoff          http://lars.nocrew.org/     Linux, GCC, PDP-10,
Brinkhoff Consulting    http://www.brinkhoff.se/    HTTP programming

-------------------------------------------------------------------------------------

Thank you both. Not to belabor it but so that I better understand the
issues, what about:

  union uParts {
   unsigned      iSum;
   unsigned char b[2];
  };

  uParts   x;

  unsigned carry;

  unsigned result;

  PACKED_DECIMAL_DIGIT pack1, pack2;

  uParts const static sum[] = { 0x0000, ... };    // precomputed result of
addition

  x.iSum = sum[pack1 + pack1]

  carry =  (unsigned) x.b[0];  // assuming that b[0] has the carry.

  result = (unsigned) x.b[1];  // assuming that b[1] contains the packed
sum

If this works I would assume that it takes less time and less space than
the algorithmic solution. What I don't understand is what's wrong with the
approach? It is unnecessary to execute an algorithm to detect carries and
the resultant sum is always correct. All of the operations performed at run
time algorithmically are performed off-line and stored in a table. At run
time execution is truncated by indexing into an existing array containing
precomputed results. So what am I missing?

art

BCD [was Re: Algol front end]

[Bonzini Paolo]

Yes, Realia COBOL was great.  I used it for midly large file processing
(the full payroll for a 120.000 inhabitants city) and was amazed at the
speed of its filesystem and especially of its numerics.  Much faster than
a Bull (then honeywell) DPS/4.

Anyway here is some code that I dug out...

---

/* packed decimal 8-digit add */

#define ONES4 (UINT_MAX / 15)       /* 0x11111111 */
#define EIGHTS4 (ONES4 * 8)         /* 0x88888888 */
#define SIXES4  (ONES4 * 6)         /* 0x66666666 */


/* carry_out:c = a + b + carry_in */
add_ssaaaa (carry_out, c, 0, a, 0, b + carry_in);

b3 =    c & EIGHTS4;
carry = (a | b) & ~c & EIGHTS4;  /* carry generated (overflow in bit 3) */
gen   = ((c & SIXES4) * 7) & b3; /* out of range generated (101? or 110?) */
prop  = ((c & ONES4)  * 8) & b3; /* carry propagated (1001) */

do
  {
    old = carry;
    carry |= gen;
    gen = prop & (carry << 4);  /* propagate carry... */
  }
while (carry != old);

/* carry_out:c = c + carry_out:carry */
add_ssaaaa (carry_out, c, carry_out, carry, 0, c);


---


/* ASCII 4-digit add */

#define ONES8      (UINT_MAX / CHAR_MAX) /* 0x01010101 */
#define EIGHTS8    (ONES8 * 8)           /* 0x08080808 */
#define SIXES8     (ONES8 * 6)           /* 0x06060606 */
#define SIXTEENS8  (ONES8 * 16)          /* 0x10101010 */
#define ASC_ZEROS8 (ONES8 * '0')         /* 0x30303030 */

c = a + b;

carry = (c & SIXTEENS8) >> 1;
b3    = c & EIGHTS8;
carry = (a | b) & ~c & EIGHTS4;  /* carry generated (overflow in bit 3) */
gen   = ((c & SIXES8) * 7) & b3; /* out of range generated (101? or 110?) */
prop  = ((c & ONES8)  * 8) & b3; /* carry propagated (1001) */

do
  {
    old = carry;
    carry |= gen;
    gen = prop & (carry << 8);  /* propagate carry... */
  }
while (carry != old);

carry = (carry >> 3) * 246 - ASC_ZEROS8;

/* carry_out:c = c + carry_out:carry */
add_ssaaaa (carry_out, c, 0, carry, 0, c);


---

The only thing I don't like is the carry-propagation loop.  Robert, do you
think it is avoidable (yes, it is unrollable)???

When writing this kind of code for a COBOL system, treelang could be
useful.  You could write all the required inlines as C code, convert them
to treelang, and then load them at run-time so that they are automatically
inlined.  Maybe the treelang could also be automatically generated by a
Perl script.

For sorting/merging code, GNU sort has all the required functionalities
and more.  If days were 48h I would surely love working on the COBOL/GCC
runtime; maybe even 30h would suffice. :-)

Paolo

Re: Algol front end

[Lars Brinkhoff]

Maybe this could be reused in a Algol 68 front end?
http://www.xs4all.nl/~jmvdveer/algol.html

-- 
Lars Brinkhoff          http://lars.nocrew.org/     Linux, GCC, PDP-10,
Brinkhoff Consulting    http://www.brinkhoff.se/    HTTP programming

Re: Algol front end

[Trevor Jenkins]

On 14 May 2002, Lars Brinkhoff <lars.spam@nocrew.org> wrote:

> Maybe this could be reused in a Algol 68 front end?
> http://www.xs4all.nl/~jmvdveer/algol.html

That's a possible one and as already mentioned is the one listed on
http://www.fsf.org/ and is distributed under the <quote>GNU
Licence</quote>. The other is the ctrans parser, which currently produces
C rather than binary output. However, I'm somewhat hesitant about the
copyright of this; it originates from the UK's Defense Research
Agency---the commerical wing of which was recently responsbible for the
fiasco over on-line access to the 1901 census.

I believe that the amount of work needed to put either of them within the
gcc framework is about the same. a68g has a transput implementation closer
to that of the Revised Report on Algol68. ctrans uses the underlying C
printf function. Neither implemented the book paradigm or formatted
output, which is rather like having a C compiler without any printf
functions or varargs. The parser would need to be interfaced to the new
tree; something that is going to hamper attempts to bring gpc into the
fold. Sothis is clearly not soemthing that will make 3.2.

Re: Algol Front End

[Robert Dewar]

<<Algol 60 is a rather small and very clean language.  Bob Dewar said
"probably > C" -- I would say smaller than C and certainly easier.
That would make a good starting point.  The reference is the "Revised
Report on Algol 60 (Backus, Naur, et al., 1962 or thereabouts)
>>

(by the way I am Robert, never Bob :-)

The reason I say > C is
dynamic arrays
nested subprograms
call by name
untyped parameters (though I would actually go with Algol-60 modified to 
get rid of this problem).

I am not at all sure that Algol-60 is easier than C, but it's a matter
of opinion certainly they are both easy small languages.

Re: Algol Front end

[Robert Dewar]

Table lookup is not the way to go for packed decimal addition.

Basically you want to do a standard addition, and then deal with the carries.

There are two cases of carries

1. Where there is a carry out of the four bits. Two subcases here
     100? + 100? => overflow, easily detected by an AND

     1001 + 0111 (or vice versa), detectable by some sequence of logical
     fiddling

2. Where the carry is within the four bits, i.e. the result is 11?? or 101?
    (again detectable by some logical fiddling)

That's as far as I have time to get right now, but starting from this, you
can figure out a series of logical operations to effect the carry adjust.

Re: Algol Front end

[Arthur I Schwarz]

  If anyone does have any good information on optimising packed decimal
code
  (other than Knuth's routines for converting to and from decimal) I would
be
  interested to hear about it.

Don't know much about the 'good' but here is a tradeoff between space and
time.

For Addition:

    When treated as an integer, the sum of any two decimal numbers, [0..9],
    is less than or equal to 18, hence, the sum adds at most 1-bit to the
    resultant when both numbers are treated as a binary. Using a carry,
from
    the preceding step, adds one number, but not one digit, to the
resultant.

    Using this result, we could:

    int sum[16] = { 0x0000, 0x0001, 0x0002, 0x0003, 0x0004
                  , 0x0005, 0x0006, 0x0007, 0x0008, 0x0009
                  , 0x0100, 0x0101, 0x0102, 0x0103, 0x0104
                  , 0x0105, 0x0106, 0x0107, 0x0108, 0x0109 };

    int value = sum[pack1 + pack2];

    int value = sum[pack1 + pack2 + carry]; if there is a carry

    Being inefficient (at two bytes) a 512 term array could handle
    adding 2-digit decimal numbers, and cutting down the number of
    required accesses.

    The change is:

    long sum[308] = { ... };   // where 'long' is at least 32-bits

For Multiplication.
    Multiplication can be handled in a similar fashion with two bits added
    to the result (9 * 9 = 81 & log(2) 81 = 6), with a carry of at most '9'
    from the preceding multiplication.

    Division and subtraction can be handled in a similar fashion.

I have forgotten how negative numbers are treated and so, the above
arguments
may have to be tweaked.

I don't know the timing and haven't seen the algorithms and results
mentioned. The above argument changes a computation from an algorithm to a
table lookup. If the table lookup is faster than the algorithm, it wins,
otherwise, it loses. It probably is unusable for putting into a toaster but
may be suitable for your use.

art

Re: Algol Front end

[Robert Dewar]

> On the IBM mainframe there is no performance difference between packed decimal
> and binary numbers, in general - I have done tests to verify this. This  not
> true on machines without packed decimal hardware/microcode support. Strictly
> speaking the X86s do have some rudimentary packed decimal support, but the
> decimal format is different from the X/Open COBOL packed decimal standard,
> which is the same as the format supported by the IBM mainframes.

Most certainly packed decimal does not run as fast as normal binary register
operations. if your tests show otherwise they are flawed.

> Not only do you have to write a lot of code to support packed decimal, but it
> is complex/tricky or relatively slow or probably both.

We found it pretty easy in Realia COBOL to beat the general performance of
IBM COBOL (that was a 4.77MHz PC vs a 370/148). Both have scaled up by now,
but the PC has scaled up more :-)

> Of course you can implement packed decimal in GCC via function calls, however
> most of the optimisation does not work because GCC does not understand what is
> going on. You could try and inline the runtime but I suspect without proof this
> would lead to unacceptable code bloat.

You should be able to get perfectly reasonable performance with runtime
calls, we certainly did in Realia COBOL. The code that IBM generates is
not that good.

> I had a look at the Ada runtime for packed decimal about 12 months ago, and I
> would be amazed if it is anywhere near as fast as binary arithmetic. From
> memory it was written in Ada so it is probably not reusable for COBOL. If
> anyone does have any good information on optimising packed decimal code (other
> than Knuth's routines for converting to and from decimal) I would be interested
> to hear about it.

The Ada runtime is not the place to look, there are no efficient routines
there. The Realia runtime would be a good place to look, but unfortunately
that is proprietary.

Do you have any further information re your comment on going bits in parellel?

It's a relatively straightforward algorithm. I have recreated it a couple of
times, I could do so again I suppose. You use the same algorithm that the
IBM mainframe likely uses.

> a) Warn people not to use PD if they want fast programs contrary to their
> expectations from their mainframe work.

Not necessary to give this warning if you do a decent job on the runtime
routines. The IBM mainframe has no special secrets. What it does in hardware
you can come close to doing in software, especially on a 64-bit machine
where you can process 16 digits at a time.

> b) Try and find ways to turn packed decimal into binary eg for isolated data
> items that are not aliased in any way.

That's a worthwhile optimization, but you can do just fine without it.

> Anyway I am not complaining, it was just a side comment... I would not think
> the silicon for packed decimal support is justified. If GCC native support for
> packed decimal is justified, someone will no doubt contribute it!

If you can do a packed decimal addition of 16 digits in a few clocks (which
is certainly possible) that's good enough to get perfectly fine performance.

Re: Algol Front end

[Robert Dewar]

> I am working on a COBOL front end for GCC.
> http://cobolforgcc.sourceforge.net. Modern CPUs and GCC have some
> trouble with COBOLisms like packed decimal.

It may be true that GCC has trouble with packed decimal, but it is plain
wrong to say that modern CPUs have trouble with this. You can do packed
decimal addition very efficiently on any modern RISC machine (the algorithms
for doing multiple digits in parallel are non-trivial, the otherwise OT
topic on counting bits is relevant here :-), but well known. 

All you are saying is that modern RISC machines do not have built in 
microprograms for doing these operations like IBM mainframes. But that's
true of many complex operations, and to say that because a machine does
not have some silly complex CISC instruction that "it has trouble" is
essentially questioning what by now is generally accepted understanding
of RISC design principles.

Yes, a COBOL compile will require a very large library, including not
only packed decimal, but also, as you note a sort merge (a relatively
easy component), and a full indexed file system. Creating the required
runtime library for a COBOL compiler is indeed a huge project (I should
know since I wrote the run time for the Realia COBOL compiler, now sold
by Computer Associates), including the sort and the indexed file system,
and literally hundreds of format specific routines (e.g. packed decimal
addition).

In fact, going back to the original statement, it really is NOT true that
GCC has trouble with packed decimal. No more than it has toruble in Ada
with decimal fixed-point types. It is just that the generated code will
have to call appropriate run-time routines. Big deal, so what?

Re: Algol Front end

[Tim Josling]

On the IBM mainframe there is no performance difference between packed decimal
and binary numbers, in general - I have done tests to verify this. This  not
true on machines without packed decimal hardware/microcode support. Strictly
speaking the X86s do have some rudimentary packed decimal support, but the
decimal format is different from the X/Open COBOL packed decimal standard,
which is the same as the format supported by the IBM mainframes.

Not only do you have to write a lot of code to support packed decimal, but it
is complex/tricky or relatively slow or probably both.

Of course you can implement packed decimal in GCC via function calls, however
most of the optimisation does not work because GCC does not understand what is
going on. You could try and inline the runtime but I suspect without proof this
would lead to unacceptable code bloat.

It may be you could define fake PD registers and instructions in the machine
descriptions and actually get GCC to do optimisation of the PD code, but this
would be a big challenge.

I had a look at the Ada runtime for packed decimal about 12 months ago, and I
would be amazed if it is anywhere near as fast as binary arithmetic. From
memory it was written in Ada so it is probably not reusable for COBOL. If
anyone does have any good information on optimising packed decimal code (other
than Knuth's routines for converting to and from decimal) I would be interested
to hear about it.

Do you have any further information re your comment on going bits in parellel?

The relevance of this is, I need to

a) Warn people not to use PD if they want fast programs contrary to their
expectations from their mainframe work.
b) Try and find ways to turn packed decimal into binary eg for isolated data
items that are not aliased in any way.

I would draw an analogy of floating point support. On a machine without
FP support you could write emulator routines and so forth, but don't expect
your FFT to run too fast!

Anyway I am not complaining, it was just a side comment... I would not think
the silicon for packed decimal support is justified. If GCC native support for
packed decimal is justified, someone will no doubt contribute it!

Tim Josling

Robert Dewar wrote:

> > ... Modern CPUs and GCC have some
> > trouble with COBOLisms like packed decimal.
>
> It may be true that GCC has trouble with packed decimal, but it is plain
> wrong to say that modern CPUs have trouble with this. You can do packed
> decimal addition very efficiently on any modern RISC machine (the algorithms
> for doing multiple digits in parallel are non-trivial, the otherwise OT
> topic on counting bits is relevant here :-), but well known.
> ...
> In fact, going back to the original statement, it really is NOT true that
> GCC has trouble with packed decimal. No more than it has toruble in Ada
> with decimal fixed-point types. It is just that the generated code will
> have to call appropriate run-time routines. Big deal, so what?

Re: Algol Front end

[Tim Josling]

More documentation on writing a front end would be good. Joachim
Nadler's thesis cannot be included in the GCC manual for copyright
reasons. It is also out of date now.

I am working on a COBOL front end for GCC.
http://cobolforgcc.sourceforge.net. Modern CPUs and GCC have some
trouble with COBOLisms like packed decimal.

I need a good sort/merge implementation for COBOL if you are after
something interesting but not too large. I definitely don't recommend
starting a new language yourself unless you have a lot of tree time.

By the way the sample language treelang is now part of the GCC source
tree (gcc3.2 experimental - the detault checkout, not the weekly
snapshot). The manual needs some work but the code works.

Helping with Fortran could be useful too.

Tim Josling

> Tony,
>
> A Fortran 95 project already exists, although it seems a bit moribund at the
> moment:
>
> http://g95.sourceforge.net/
>
> As for other languages, I would be most interested in Modula-2, given that I
> used that language extensively back in the 1980s. I know it had some
> popularity in certain circles, especially in Europe.
>
> PL/I continues to have its adherents; some guy has reimplemented some of the
> C++ and Fortran code on my web site in PL/I. I know it was popular in
> certain government and Russian sectors.
>
> COBOL is... well, COBOL. ;) I made lots of money in COBOL way back when... I
> don't know if anyone is really hot for a free compiler in a Unix
> environment.
>
> ..Scott
>
> Scott Robert Ladd
> Coyote Gulch Productions
> http://www.coyotegulch.com
>
> -----Original Message-----
> From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org]On Behalf Of
> Tony Stratton
> Sent: Monday, May 06, 2002 19:54
> To: gcc@gnu.org
> Subject: Algol Front End
>
>
> I am interested in doing a front end project for one of the following
> languages list on your project page.
>         Algol 60, Algol 68, PL/I, Cobol, Fortran 90, Delphi, Modula 2, Modula 3,
> RPG,
>
> I am leaning toward Algol 60 and/or 68, but I will not start before I hear
> from you.  If you can help me find a "definitive" reference on either Algol
> version, I can start.
>
> I can also work on documentation similar to the "TOY language" front-end
> tutorial.
>
> Please let me know if this is worth while for you.
>
> Thanks,
> Tony Stratton
>
>
>

Re: Algol Front End

[Robert Dewar]

A full Algol-68 front end is a huge project. Several person years, it is
a large and complex language. The definitive reference is the Algol-68
revised report, published by IFIP (WG2.1). It is a difficult document,
requiring some considerable facility in reading W grammars.

An Algol-68-S subset is a more practical project, but still large.

Algol-60 is by comparison a fairly simple language (probably > C and < Pascal)

Re: Algol Front End

[Jose E. Marchesi]

   A full Algol-68 front end is a huge project. Several person years, it is
   a large and complex language. The definitive reference is the Algol-68
   revised report, published by IFIP (WG2.1). It is a difficult document,
   requiring some considerable facility in reading W grammars.

I would be happy volunteering with the VW grammars for that project. I already
use the Algol 68 'ctrans' implementation, but a gcc front-end would be 
definitly great.

-- 
Jose E. Marchesi    http://es.gnu.org
GNU Spain           http://www.gnu.org

Algol Front End

[Tony Stratton]

I am interested in doing a front end project for one of the following languages list on your project page.
	Algol 60, Algol 68, PL/I, Cobol, Fortran 90, Delphi, Modula 2, Modula 3, RPG, 

I am leaning toward Algol 60 and/or 68, but I will not start before I hear from you.  If you can help me find a "definitive" reference on either Algol version, I can start.

I can also work on documentation similar to the "TOY language" front-end tutorial.

Please let me know if this is worth while for you.

Thanks,
Tony Stratton

RE: Algol Front End

[Scott Robert Ladd]

Tony,

A Fortran 95 project already exists, although it seems a bit moribund at the
moment:

http://g95.sourceforge.net/

As for other languages, I would be most interested in Modula-2, given that I
used that language extensively back in the 1980s. I know it had some
popularity in certain circles, especially in Europe.

PL/I continues to have its adherents; some guy has reimplemented some of the
C++ and Fortran code on my web site in PL/I. I know it was popular in
certain government and Russian sectors.

COBOL is... well, COBOL. ;) I made lots of money in COBOL way back when... I
don't know if anyone is really hot for a free compiler in a Unix
environment.

..Scott

Scott Robert Ladd
Coyote Gulch Productions
http://www.coyotegulch.com

-----Original Message-----
From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org]On Behalf Of
Tony Stratton
Sent: Monday, May 06, 2002 19:54
To: gcc@gnu.org
Subject: Algol Front End


I am interested in doing a front end project for one of the following
languages list on your project page.
	Algol 60, Algol 68, PL/I, Cobol, Fortran 90, Delphi, Modula 2, Modula 3,
RPG,

I am leaning toward Algol 60 and/or 68, but I will not start before I hear
from you.  If you can help me find a "definitive" reference on either Algol
version, I can start.

I can also work on documentation similar to the "TOY language" front-end
tutorial.

Please let me know if this is worth while for you.

Thanks,
Tony Stratton

RE: Algol Front End

[Steven Bosscher]

Op di 07-05-2002, om 02:23 schreef Scott Robert Ladd:
> A Fortran 95 project already exists, although it seems a bit moribund at the
> moment:
> 
> http://g95.sourceforge.net/

It's still alive and kicking. It just seems that Andy Vaught has other
preoccupations right now, but I'm working on it almost every day, and so
are a handful other people. The parser mostly works, and right now we're
looking at how to interface with the back-end.

If you're interested in helping, you're welcome! We still have a few big
projects (most notably the runtime libraries and a scalarizer).

> As for other languages, I would be most interested in Modula-2, given that I
> used that language extensively back in the 1980s. I know it had some
> popularity in certain circles, especially in Europe.

It already exists, but I'm not sure how well it works.

http://floppsie.comp.glam.ac.uk/Glamorgan/gaius/web/GNUModula2.html
 
Greetz
Steven

Re: Algol Front End

[Paul Koning]

Excerpt of message (sent 6 May 2002) by Tony Stratton:
> I am interested in doing a front end project for one of the following languages list on your project page.
> 	Algol 60, Algol 68, PL/I, Cobol, Fortran 90, Delphi, Modula 2, Modula 3, RPG, 
> 
> I am leaning toward Algol 60 and/or 68, but I will not start before I hear from you.  If you can help me find a "definitive" reference on either Algol version, I can start.

Algol 60 is a rather small and very clean language.  Bob Dewar said
"probably > C" -- I would say smaller than C and certainly easier.
That would make a good starting point.  The reference is the "Revised
Report on Algol 60 (Backus, Naur, et al., 1962 or thereabouts)

One problem with Algol 60 is that the standard has NO I/O at all.
Various implementations have done their own extensions for this, in
very different ways.  There's the collections of procedures approach
in the THE implementation, and the vaguely Fortran-like one in
Burroughs Algol.

Algol 68 by contrast is a large and complex language -- still not as
nasty as PL/I but way above C and Pascal.  The rigorous reference is
the Revised Report; a very good starting point is the Informal
Introduction (revised edition).  Also, if you can get your hands on
the original Algol 68 Report (not the Revised one) that may help; its
formal description is slightly easier to cope with at first if you're
only going about half-way into the depths of the definition.  Then you
can switch to the Revised Report, that's the cleaned-up version of the
language.

	paul