Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!leah!bingvaxu!sunybcs!bowen
From: bowen@cs.Buffalo.EDU (Devon E Bowen)
Newsgroups: comp.lang.modula2
Subject: Re: Modula2 front end for gcc?
Message-ID: <7943@cs.Buffalo.EDU>
Date: 14 Jul 89 18:39:20 GMT
References: <8728@pyr.gatech.EDU> <7894@cs.Buffalo.EDU> <944@gould.doc.ic.ac.uk>
Reply-To: bowen@sunybcs.UUCP (Devon E Bowen)
Organization: SUNY/Buffalo Computer Science
Lines: 54

In article <944@gould.doc.ic.ac.uk> dcw@doc.ic.ac.uk (Duncan C White) writes:
>I am still testing this translator out, but if anyone would like to look at
>it, I'd be happy to send them the source code & documents.  On a strictly
>as-is basis!!

I'm very interested. Please let me know where I can get a copy.

>>As far as its characteristics, it will have all the feature described
>>by Wirth (yes, even coroutines).
>
>May I ask how it does this?  setjmp()/longjmp() ?  or assembly-support.

This is, of course, OS/architecture dependent. We pan to implement it as
such by leaving it in the separate Processes module. We will then write
the module according to the OS/architecture. We plan to support true
parallel processing on the Encore Multimax and coroutines on BSD and SunOS.
The Multimax port will be simple since the OS already provides for shared
memory and semaphores. For the BSD and SunOS modules, we'll probably use
assembly to save and rewrite the call frame as needed. This is the last
of our concerns at this stage, though. I am very interested in talking to
Peter about his setjmp/longjmp ideas. Can I get an address for him?

>>	2) variable number of parameters passed to a function.
>
>Presumably when you pass a variable no of parameters to a function, type-
>checking goes out of the window?

Right. This is being included to take advantage of the variable parameter
C I/O like printf, etc. The cleanest way to do this is to define a new
procedure type (maybe "cprocedure") that tells the system to just accept
any parameters with no type checking. This still leaves it as an extension
that will not break the standard language.

>I like the assertion function built into the language.

Thanks. This will initially only be included as an external module. It
can then be added as a compiler-known function later. This is needed in
case our compiler eventually ends up used in introductory classes (which
are currently taught on Macs).

>As to linking with C, that's absolutely essential IMHO..

Couldn't agree with you more (expecially since I'm primarily a C hack).

>If you want any beta-testers, let me know...

I'll be posting here when ready. I've gotten a lot of interst by mail
as well.


Devon Bowen (KA2NRC)		FAX:	   (716) 636-3464
University at Buffalo		BITNET:    bowen@sunybcs.BITNET
				Internet:  bowen@cs.Buffalo.EDU
UUCP: ...!{watmath,boulder,decvax,rutgers}!sunybcs!bowen