🚀 go-pugleaf

In article <8026@sunybcs.UUCP> kumard@sunybcs.UUCP (Deepak Kumar) writes:
>	We just got an installation of the Modula2 compiler for
>	the Encore. I think it is a port of the ETH compiler. But

This compiler is called "ETH/IIT Modula-2". It is a third party package
based on a heavily modified version of the ETH single pass compiler, and a
port of the OSSI runtime libraries. This is distributed with full source code
by Illinois Institute of Technology. Licenses from Modula Corp (for the
compiler) and the OSSI authors must be executed. Both the ETH compiler and
OSSI libraries were used because they were available and could be distributed
with source code for next to nothing. The compiler produces horrible native code
in no time flat. For example, the compiler recompiles itself on a Multimax 120
(the slowest Multimax model) in 45 seconds. Runtime performance is about 1/4 as
good as that of equivalent C programs compiled with Encore C, based on the
Hennessey/Nye benchmarks. There was a plan to have proper user documentation
but so far this hasn't worked out and documentation consists of two man pages
and the source code. A source level debugger is also hoped for, but this
hasn't happened yet either.

>	it does not have the standard set of library modules, instead
>	we have the OSSI library with names begining with SIBlah.def
>	etc. Does anybody have the standard interface? One can

What standard set of library modules? There are many, many different sets of
runtimes for M2 systems. The thing to notice is that OSSI includes routines
to do all the usual things you are likely to want to do and most of the ROUTINE
names discussed in the Wirth book are present. The module names are as they
came from the OSSI authors and cannot be changed (e.g. from SITerminal to
Terminal) without violating their license.

>	Also, it has an older version of the parralel programming
>	interface 'libu'. Does anybody know if the newer version
>	'libpp' has been ported?

A libpp interface has not been made, as far as I know. All of the source
code for the libu module is provided, however, and it is absolutely trivial.
An interface to libpp made out of the libu module would be just as trivial.

Sorry to be long winded about this, but it's not like we have to wade through
a lot of traffic in this news group.

Pete Soper writes:

>Runtime performance is about 1/4 as good as that of equivalent C
>programs compiled with Encore C, based on the Hennessey/Nye
>benchmarks.

Is this typical of modula-2?  Is C usually 4 times faster for
equivalent programs?

Rion Cassidy
Ford Aerospace
rion@ford-wdl1.arpa
...{sgi,sun,ucbvax}!wdl1!rion

All opinions stated here are my own, not my employer's.

In article <3740001@wdl1.UUCP> rion@wdl1.UUCP (Rion Cassidy) writes:
>Pete Soper writes:
>
>>Runtime performance is about 1/4 as good as that of equivalent C
>>programs compiled with Encore C, based on the Hennessey/Nye
>>benchmarks.
>
>Is this typical of modula-2?  Is C usually 4 times faster for
>equivalent programs?

The third party Modula-2 that runs on
Multimax is based on the Wirth one pass compiler with its
naive code generator virtually unmodified except for what was needed
to generate Unix object files and decent runtime checking code. The
Encore C compiler on the other hand uses many state of the art
global optimization techniques to generate fast code. So the four to
one difference is a statement about compiler technology, not about
something inherent in one language or the other. If and when there is
an "Encore Modula-2" you could expect the code quality gap to be
eliminated or greatly reduced.

******************************
I have a question. Who would I write to and what exactly would I ask
for to get a copy of the currently proposed BSI Modula-2 standard?
If there is a charge I can send a Bank of Scotland check. Thanks.
******************************
-- 
--------------------------------------------------------
Pete Soper, Encore Computer Corp         (919) 481-3730)
arpa: soper@multimax.arpa (192.5.63.14)
uucp: {necntc,talcott,ihnp4,decvax,allegra}!encore!soper

In article <3740001@wdl1.UUCP>, rion@wdl1.UUCP (Rion Cassidy) writes:
> 
> Is this typical of modula-2?  Is C usually 4 times faster for
> equivalent programs?
> 
No.  Given a good M-2 compiler, they are about the same.

-- 
Robert Marti                    Phone:       +41 1 256 52 36
Institut fur Informatik
ETH Zentrum/SOT                 CSNET/ARPA:  marti%ifi.ethz.ch@relay.cs.net
CH-8092 Zurich, Switzerland     UUCP:        ...uunet!mcvax!ethz!marti

In article <2562@encore.UUCP>, soper@encore.UUCP (Pete Soper) writes:
> In article <8026@sunybcs.UUCP> kumard@sunybcs.UUCP (Deepak Kumar) writes:
> >	it does not have the standard set of library modules, instead
> >	we have the OSSI library with names begining with SIBlah.def
> >	etc. Does anybody have the standard interface? One can

> What standard set of library modules? There are many, many different sets of
> runtimes for M2 systems.

Bingo. I admire Modula-2, but I'm going to keep using 'C' until such time as
this situation changes.

I can write portable 'C' programs that do a reasonably efficient job at system
level utilities, and can be recompiled without change on a variety of systems.
I don't know of any other language for which that's true. Perhaps if some of
you Modula hotshots got together and rammed a non-proprietary standard library
(that at least provided the equivalent of the 'C' stdio library) through,
Modula would become a real alternative for people who need to work on more
than one processor/compiler pair.

(Perhaps you could co-ordinate with Henry Spencer on his UNIX libraries
project...)
-- 
-- Peter da Silva  `-_-'  ...!hoptoad!academ!uhnix1!sugar!peter
-- Disclaimer: These U aren't mere opinions... these are *values*.

In article <2562@encore.UUCP>, soper@encore.UUCP (Pete Soper) writes:
> source code for next to nothing. The compiler produces horrible native code
> in no time flat. For example, the compiler recompiles itself on a Multimax 120
> (slowest Multimax model) in 45 seconds. Runtime performance is about 1/4 as
> good as that of equivalent C programs compiled with Encore C, based on the
> Hennessey/Nye benchmarks. There was a plan to have proper user documentation

We are working with the MC68000 version of ETH's compiler and are pleased with
the code generated. What processor does an Encore have? Do you know any reasons
for this poor performance?

-- 
     //	Markus Schaub		uunet!nuchat!sugar!schaub      (713) 523 8422
    //	M2Amiga Developer	trying to get back the money I  paid  for  my
\\ //				Amiga by selling a few M2Amiga.
 \X/	c/o Interface Technologies Corp, 3336 Richmond #323, Houston Tx 77098

In article <3740001@wdl1.UUCP> rion@wdl1.UUCP (Rion Cassidy) writes:
>Pete Soper writes:
>
>>Runtime performance is about 1/4 as good as that of equivalent C
>>programs compiled with Encore C, based on the Hennessey/Nye
>>benchmarks.
>
>Is this typical of modula-2?  Is C usually 4 times faster for
>equivalent programs?

The difference between different compilers for the SAME language on the
SAME machine running the SAME operating system can vary by more than a
factor of five.  This makes it very difficult to get objective
measurements of the difference in speed a language makes (assuming 
all the languages being compared use the same execution technology:
all are compiled or all are interpreted).  The parse tree that is
generated by a C compiler and the one generated by a Modula-2 compiler
are extremely similar.  They can pretty much share the same code
generator.  In those systems where they do share the same code
generator, they produce very similar benchmark results.

--alan@pdn

In article <2270@pdn.UUCP> alan@pdn.UUCP (0000-Alan Lovejoy) writes:

>The difference between different compilers for the SAME language on the
>SAME machine running the SAME operating system can vary by more than a
>factor of five.  This makes it very difficult to get objective
>measurements of the difference in speed a language makes (assuming 

  Right. I was making a statement about compiler technology and the
actual performance of a few compilers, so people would know what to
expect. Nothing more.
-- 
Pete Soper, Encore Computer Corp          (919) 481-3730
901 Kildaire Farm rd., bldg D  Cary, NC  27511       USA
arpa: soper@multimax.arpa (192.5.63.14)
uucp: {necntc,talcott,ihnp4,decvax,allegra}!encore!soper