Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Lilith M2 compiler
19 views
Skip to first unread message
Michael McGaw
Oct 20, 2011, 9:55:35 AM10/20/11
to
Hello all:
I have been working on a port of the Lilith multipass M2 compiler, and
have accomplished this, having an associate linker and M-code
interpreter with which to link and run programs.
However, as I look at moving this whole environment from platform to
platform, what I am really interested in, is the so-called Single Pass
M2 compiler that generates M-Code. This should make the problem of
moving the compiler much simpler, and improve the overall performance
of compilation as well.
I have corresponded with Prof. Wirth regarding this, and
unfortunately, he discarded all of the old 5-1/4 diskettes he had from
this era, some time ago. I have also been in contact with Jos
Dreesen, who made the excellent Lilith emulator, but again, have found
a dead end.
I am wondering if there is anyone who reads this discussion group who
might either have the sources for this compiler and would be willing
to share them with me, or who might know and have contact information
for any of the original Lilith project collaborators, including any
from the U.S. (Modula Corporation) who might be able to lend a hand
locating this single pass M-code generating compiler.
I would greatly appreciate any feedback.
Thanks,
Mike
I have been working on a port of the Lilith multipass M2 compiler, and
have accomplished this, having an associate linker and M-code
interpreter with which to link and run programs.
However, as I look at moving this whole environment from platform to
platform, what I am really interested in, is the so-called Single Pass
M2 compiler that generates M-Code. This should make the problem of
moving the compiler much simpler, and improve the overall performance
of compilation as well.
I have corresponded with Prof. Wirth regarding this, and
unfortunately, he discarded all of the old 5-1/4 diskettes he had from
this era, some time ago. I have also been in contact with Jos
Dreesen, who made the excellent Lilith emulator, but again, have found
a dead end.
I am wondering if there is anyone who reads this discussion group who
might either have the sources for this compiler and would be willing
to share them with me, or who might know and have contact information
for any of the original Lilith project collaborators, including any
from the U.S. (Modula Corporation) who might be able to lend a hand
locating this single pass M-code generating compiler.
I would greatly appreciate any feedback.
Thanks,
Mike
Rugxulo
Oct 20, 2011, 2:31:43 PM10/20/11
to
Hi,
On Oct 20, 8:55 am, Michael McGaw <mikemt...@gmail.com> wrote:
>
> I have been working on a port of the Lilith multipass M2 compiler,
>
on here that MacMETH derived from that compiler.
http://www.sysecol.ethz.ch/RAMSES/MacMETH.html
Possibly others too (M2Amiga), dunno. Chris Burrows is probably the
guy who would know (at least more than I do).
Sorry I can't help further. However, if all you want is faster speed,
just put the compiler on a RAM disk. That's the only reason for extra
speed anyways, right? It keeps it in RAM instead of constantly dumping
back and forth between slow storage (HD).
Just curious, what systems are you trying to get it working on?
On Oct 20, 8:55 am, Michael McGaw <mikemt...@gmail.com> wrote:
>
> I have been working on a port of the Lilith multipass M2 compiler,
>
> what I am really interested in, is the so-called Single Pass
> M2 compiler that generates M-Code. This should make the problem of
> moving the compiler much simpler, and improve the overall performance
> of compilation as well.
>
> M2 compiler that generates M-Code. This should make the problem of
> moving the compiler much simpler, and improve the overall performance
> of compilation as well.
>
> I am wondering if there is anyone who reads this discussion group who
> might either have the sources for this compiler and would be willing
> to share them with me
>
> might either have the sources for this compiler and would be willing
> to share them with me
>
> I would greatly appreciate any feedback.
I'm probably the wrong person to ask, but I think I remember reading
on here that MacMETH derived from that compiler.
http://www.sysecol.ethz.ch/RAMSES/MacMETH.html
Possibly others too (M2Amiga), dunno. Chris Burrows is probably the
guy who would know (at least more than I do).
Sorry I can't help further. However, if all you want is faster speed,
just put the compiler on a RAM disk. That's the only reason for extra
speed anyways, right? It keeps it in RAM instead of constantly dumping
back and forth between slow storage (HD).
Just curious, what systems are you trying to get it working on?
Michael McGaw
Oct 21, 2011, 8:49:23 AM10/21/11
to
overall project of Ramses.
Chris and I have been in conversation about this, also. In fact, I
have been in conversation with a great many about this, and my post
here is sort of a 'last ditch, casting of a net' type of approach to
see if there's anyone who reads this list who might be able to point
me to where the single pass M-code generating version of this compiler
might be.
As for the systems on which I wish to use this: that's just it. With
the port done reasonably well, it could be used just about anywhere.
Right now, I have an acceptable and working system, but, the porting
of the multipass compiler is not for the faint of heart, as pointers
and CARDINALs are presumed the same size and passed this way on the
interpass files. There are many consequences of this meandering
through the compiler. Takes a while to tease through all that.
Moreover, one needs to focus on hosting of the compiler on a specific
target, whereas the linker and interpreter are much easier to move
around. The single pass compiler ought to make the portabilty problem
go away almost completely.
Lastly, again as to why do this: such a setup I think would be quite
useful for being able to continue to run M2 regardless what comes in
terms of computing targets.
-M
George
Oct 21, 2011, 9:27:55 AM10/21/11
to
On 21/10/11 8:49 a, Michael McGaw wrote (in part):
[...]
68k code directly.
>
> Chris and I have been in conversation about this, also. In fact, I
> have been in conversation with a great many about this, and my post
> here is sort of a 'last ditch, casting of a net' type of approach to
> see if there's anyone who reads this list who might be able to point
> me to where the single pass M-code generating version of this compiler
> might be.
The P-System had a Modula-2 compiler (although it produced a version of
P-code, rather than M-code). Whether anyone on the list can help is
moot. (You may have already considered this.)
>
> As for the systems on which I wish to use this: that's just it. With
> the port done reasonably well, it could be used just about anywhere.
A worthy goal -- the community would thank you.
> Right now, I have an acceptable and working system, but, the porting
> of the multipass compiler is not for the faint of heart, as pointers
> and CARDINALs are presumed the same size and passed this way on the
> interpass files. There are many consequences of this meandering
> through the compiler. Takes a while to tease through all that.
> Moreover, one needs to focus on hosting of the compiler on a specific
> target, whereas the linker and interpreter are much easier to move
> around. The single pass compiler ought to make the portabilty problem
> go away almost completely.
Three other compilers come to mind but they also involve substantial
work. (Again, you may have already considered them.)
1. The ULM compiler is a multi-pass compiler (with versions producing
68k and Sparc code -- it runs well on Solaris 10 albeit in 32-bit mode).
The intermediate pass file structure is very well documented, though.
2. John Gough released source to a very specific version of the GPM
compiler a few years ago. (I understand that he is unable to release
other back-ends due to licensing issues.) I am informed that the front
end emits D-code (an enhanced M-code and well-documented). They wrote
several back-ends (not released in source) and source to their
almost-ISO libraries is available. The Linux binaries do not run on
recent Linux distributions and the Sparc version only runs on Solaris 8
and 9.
3. Mocka was written to be portable via BEG. Unfortunately, the only
files released by BEG are for Intel and IBM 360 (and a BEG binary only
runs on an old version of Linux). I understand that attempts to contact
the author of BEG to release the source to this early version have
failed. (BEG is now private and their sales people do not seem to
interested.)
>
> Lastly, again as to why do this: such a setup I think would be quite
> useful for being able to continue to run M2 regardless what comes in
> terms of computing targets.
Again, a worthy goal and thank you from all of us who use multiple
platforms.
G.
[...]
> Thanks- I have the MacMeth sources, and am somewhat familiar with the
> overall project of Ramses.
Yes, a difficult choice to start from, given that it calculates binary
> overall project of Ramses.
68k code directly.
>
> Chris and I have been in conversation about this, also. In fact, I
> have been in conversation with a great many about this, and my post
> here is sort of a 'last ditch, casting of a net' type of approach to
> see if there's anyone who reads this list who might be able to point
> me to where the single pass M-code generating version of this compiler
> might be.
P-code, rather than M-code). Whether anyone on the list can help is
moot. (You may have already considered this.)
>
> As for the systems on which I wish to use this: that's just it. With
> the port done reasonably well, it could be used just about anywhere.
> Right now, I have an acceptable and working system, but, the porting
> of the multipass compiler is not for the faint of heart, as pointers
> and CARDINALs are presumed the same size and passed this way on the
> interpass files. There are many consequences of this meandering
> through the compiler. Takes a while to tease through all that.
> Moreover, one needs to focus on hosting of the compiler on a specific
> target, whereas the linker and interpreter are much easier to move
> around. The single pass compiler ought to make the portabilty problem
> go away almost completely.
work. (Again, you may have already considered them.)
1. The ULM compiler is a multi-pass compiler (with versions producing
68k and Sparc code -- it runs well on Solaris 10 albeit in 32-bit mode).
The intermediate pass file structure is very well documented, though.
2. John Gough released source to a very specific version of the GPM
compiler a few years ago. (I understand that he is unable to release
other back-ends due to licensing issues.) I am informed that the front
end emits D-code (an enhanced M-code and well-documented). They wrote
several back-ends (not released in source) and source to their
almost-ISO libraries is available. The Linux binaries do not run on
recent Linux distributions and the Sparc version only runs on Solaris 8
and 9.
3. Mocka was written to be portable via BEG. Unfortunately, the only
files released by BEG are for Intel and IBM 360 (and a BEG binary only
runs on an old version of Linux). I understand that attempts to contact
the author of BEG to release the source to this early version have
failed. (BEG is now private and their sales people do not seem to
interested.)
>
> Lastly, again as to why do this: such a setup I think would be quite
> useful for being able to continue to run M2 regardless what comes in
> terms of computing targets.
platforms.
G.
tbreeden
Oct 21, 2011, 10:10:24 AM10/21/11
to
On Oct 21, 12:49 pm, Michael McGaw <mikemt...@gmail.com> wrote:
>
> > > I have been working on a port of the Lilith multipass M2 compiler,
> ...
>
> > > I have been working on a port of the Lilith multipass M2 compiler,
> Lastly, again as to why do this: such a setup I think would be quite
> useful for being able to continue to run M2 regardless what comes in
> terms of computing targets.
A worthy goal!
> useful for being able to continue to run M2 regardless what comes in
> terms of computing targets.
In case you could use more info, I have copies of two dissertations
giving detailed information about the M-code compiler.
"Code Generation and the Lilith Architecture", Christian Jacobi,
ETH No 7195, 1982
"Separate Compilation in Modula-2 and the Structure of the
Modula-2 Compiler on the Personal Computer Lilith", Leo Geissman, ETH
7286, 1983
They were written w/r/t the multi-pass one, but would probably still
be invaluable in working with the single pass one. Don't remember
where I got them, but maybe from ETH itself, but I could donate them
to you.
Alternatively, I have written a frontend - backend Modula-2 compiler
(ultimately developed from the ETH M68000 single pass compiler) that I
designed with an intermediate code that I hope could make it portable.
I've not yet tried to branch out from my original IC -> PPC code
generation back end, though. I'd be glad to share it with you if you
wanted to think about starting from this one.
I'm not a compiler professional, so it is not the most advanced
techniques (to say the least), but it is pretty straightforward.
It runs on the current Amiga OS4 PowerPc systems, but if you are
interested in just looking at the sources, let me know.
regards,
Tom
Michael McGaw
Oct 21, 2011, 1:00:22 PM10/21/11
to
I have looked at many M2 compilers for which sources can be found, and
I keep coming back to the simplicity and clarity of the ETH work.
This is why I am focused on finding the single pass M2 compiler that
generates M-code. Possibly the closest thing I have found is the M2
compiler for KRONOS, but that would take things in a different
direction altogether.
The dissertations that Tom points to are essential to understanding
the multipass M2 compiler of Lilith, and I could not have done the
port without them. I appreciate the offer of those.
Quite interesting work, Tom, on the M68K compiler. I'd be interested
in a look at that. Have collect various Amiga and Atari ST
implementations, too, but, as I said, the object of my interest is in
the original ETH single pass M-code generating compiler.
I am glad to know you guys can see the utility of this project, and I
appreciate the time you've taken to respond.
-M
jan272
Oct 22, 2011, 5:23:51 AM10/22/11
to
very neat and compact code.
http://fruttenboel.verhoeven272.nl/ack/index.html
http://fruttenboel.verhoeven272.nl/ack/getit.html
And here is the bonus. Ceriel Jacobs (together with AST the major
author) is on the ACK mailing list. And he will answer any question.
He may be your last chance....
-- jan
Chris Burrows
Oct 22, 2011, 8:46:11 AM10/22/11
to
>
> I read the discussion. Have you seen the (Minix) ACK? The ACK produces
> very neat and compact code.
>
ACK is written in C. Wirth's single-pass Modula-2 compiler and the original
> I read the discussion. Have you seen the (Minix) ACK? The ACK produces
> very neat and compact code.
>
ETH 4/5 pass compilers are written in Modula-2.
Chris Burrows
CFB Software
http://www.cfbsoftware.com/modula2
jan272
Oct 22, 2011, 1:49:41 PM10/22/11
to
worked on (good) compilers in the early 80's. And he's alive and
responding. http://www.cs.vu.nl/~ceriel
0 new messages