M2R10 collaboration

[trijezdci]

I split this off from the optimisation thread, again because the questions asked were off-topic there.

Thanks a lot for very interesting mails you write...however, I'd like to
see if you can write something about what are possibilities for people
to contribute to the R10 project at this moment, iow. something which
goes along with defined Goals on the web site?

There are four activities going on at this point in time:

(1) setting up a non-profit foundation in Switzerland
(2) update the spec while putting it on the wiki
(3) work on the non-spec part of the book
(4) work on the bootstrap compiler

#1 is mostly about collecting money for the fees we need to pay to set up the foundation.

There are two approaches. One is a custom set up supplying one's own board of trustees etc etc. One is to join an umbrella organisation as a sub-foundation and the umbrella foundation takes care of all administrative aspects in a package deal. The first approach is difficult to get exact pricing for because the companies who do this never give you a package price and the danger is that once you have gone half the way, they will tell you that there is something else you need to do and pay for. Quotes I got are hovering below 10.000 CHF. The second approach is 8000 CHF for set up and 6000 CHF annually with Fondation des Fondateurs (Foundation of Founders) and they take care of everything for that.

If we use the higher figure, 14.000 CHF just to be on the safe side, and find 10 individuals with income who can afford and are willing to pledge 1400 CHF for the purpose of setting up the foundation, we'd be there in an instant but these things are all too often "if you get 9 others, I am in as number 10". I have some pledges but thus far insufficient, yet I still haven't called everybody on my list.

This would be an area where people can help. Either by considering to donate themselves. Or if they have the talent to convince others, by helping in the fundraising effort.

#2 and #3 is something Rick and I work on, not really something that can be divided well, but people can read the wiki and report typos or comment if they think something is factually wrong or badly written.

#4 is collaborative work of course

The new compiler is written in PIM3 and we intend to use Sinuhe's fork of m2c for bootstrapping. Unfortunately, one of the team members reported back to me that he couldn't get it to build on Windows and he's only got a windows netbook at the moment. I got M2M working in a DOSbox, which may be a little inconvenient but it should work, although it is PIM2 so it needs explicit EXPORT which is a nuisance. Perhaps somebody can take a look and see what it takes to get m2c build on Windows.

Other than that, it needs some familiarity with PIM, perhaps a copy of PIM, and some familiarisation with the code I have already put into the repo at bitbucket. An important part is a portable simple FileIO and FileSystem library that abstracts the underlying file IO and file system away. I think I have already done the definition parts for that. This is something that doesn't need any knowledge about lexing, parsing and compilers.

Another task would be the verification of FIRST and FOLLOW sets. I used to use ANTLR to verify the grammar but for some reason it broke and I have wasted too much time on trying to figure out why it broke already. This is one reason why I would never use any parser generator for such a project, you become dependent on somebody else's work and may get stuck then. Those tools may change faster than your project evolves. Anyway, I have not been able to find any tool that can generate FIRST and FOLLOW sets from an EBNF grammar so I did this by hand, which means it would be a good idea if somebody else did the same and we compare the results for verification.

There will sure be more work further down the road that can be done in collaboration.

Let's hope there will be plenty of time to talk about optimizing and/or
tailoring compiler,

Do not underestimate the importance of discussions like the ones we have had in this usenet group. Consider it a mix of PR and relationship building. The wiki has a lot of info now about the rationale, the goals and the technical side of the project, but often it takes somebody doing a presentation or a discussion in an online forum to talk about specific examples from the project work and to present the mindset, the philosophy and school of thinking for people to become interested and further down the road join in or support the project in other ways. It is important to establish likemindedness.

but as you confirmed, having bootstrap compiler is
very important milestone to revive interest in (Modula-2) R10.

I think you meant to say "revive interest in Modula-2" or perhaps "build up interest in M2R10".

thanks again for your interest

[Gour]

On Thu, 8 Oct 2015 10:13:07 -0700 (PDT)

Post by trijezdci
This would be an area where people can help. Either by considering to
donate themselves. Or if they have the talent to convince others, by
helping in the fundraising effort.

(Un)fortunately, I'm not in the league to be able to help here, neither
by earning enough to donate nor having fundraising skills...

Post by trijezdci
#2 and #3 is something Rick and I work on, not really something that
can be divided well, but people can read the wiki and report typos or
comment if they think something is factually wrong or badly written.

There is not much to do considering that it seems that Rick and yourself
know your job. ;)

Post by trijezdci
#4 is collaborative work of course
The new compiler is written in PIM3 and we intend to use Sinuhe's
fork of m2c for bootstrapping. Unfortunately, one of the team members
reported back to me that he couldn't get it to build on Windows and
he's only got a windows netbook at the moment.

I did spent some time chatting with Sinuhe on IRC and he confirmed
problem with build on Windows since m2c's build system does hardcore
(some) paths.

However, at the moment he does not have much time to fiddle with it
since he plans to fix some serious bugs in m2c first and does not have
much time; moreover he more interested in Oberon these days.

My suggestion was that maybe by re-writing m2c build system with
something like cmake/waf/scons/whatever...it would be possible to fix
build on Windows. What do you think about it?

I only have old winxp.iso which I can install under Virtualbox and it
was long time since I was fiddling with msys, but I can take a look if
you consider it will be helpful?

Post by trijezdci
Other than that, it needs some familiarity with PIM, perhaps a copy
of PIM, and some familiarisation with the code I have already put
into the repo at bitbucket.

Considering that Sinuhe used m2c for learning Modula along with King's
book which I also own, it looks as better option than gm2, especially
when m2c is going to be used for bootstrap compiler.

Post by trijezdci
Do not underestimate the importance of discussions like the ones we
have had in this usenet group. Consider it a mix of PR and
relationship building.

Not at all...I'm just aware that those emails require your time & energy, so
considered that it could be helpful to mention how *we* can also spend
some of *our* time energy in the same direction. ;)

Post by trijezdci
I think you meant to say "revive interest in Modula-2" or perhaps
"build up interest in M2R10".

I meant to say revive interest in Modula-2 as well in R10 revision.

I shortly visited some Oberon-related places, and it looks that its
community is much more alive than the Modula-2...


Sincerely,
Gour

[Martin Brown]

Post by trijezdci
I split this off from the optimisation thread, again because the questions asked were off-topic there.

Thanks a lot for very interesting mails you write...however, I'd like to
see if you can write something about what are possibilities for people
to contribute to the R10 project at this moment, iow. something which
goes along with defined Goals on the web site?

The new compiler is written in PIM3 and we intend to use Sinuhe's fork of m2c for bootstrapping.
Unfortunately, one of the team members reported back to me that he

couldn't get it to build on

Post by trijezdci
Windows and he's only got a windows netbook at the moment. I got M2M

working in a DOSbox, which

Post by trijezdci
may be a little inconvenient but it should work, although it is PIM2

so it needs explicit EXPORT

Post by trijezdci
which is a nuisance. Perhaps somebody can take a look and see what it

takes to get m2c build on Windows.

It might be worth using a pair of compilers for development (or which
for Windows I'd recommend the free XDS one but using a PIM3 subset). It
avoids getting caught out by some minor quirk or extension in a major
compiler. You might have to add a few shims here and there to obtain
exact code compatibility one with the other, but we have always found
that code written to run on multiple compilers ends up cleaner.

BTW Whilst developing the compiler spare a thought for debugging tools
(or will this compiler initially output C code rather than binary?).

I rather liked the way Topspeed did failure tracebacks for postmortems.

Post by trijezdci

but as you confirmed, having bootstrap compiler is
very important milestone to revive interest in (Modula-2) R10.

I think you meant to say "revive interest in Modula-2" or perhaps "build up interest in M2R10".

It is the most activity in this group for quite a while. Well done!

[Gour]

On Fri, 9 Oct 2015 09:17:30 +0100

Post by Martin Brown
I rather liked the way Topspeed did failure tracebacks for
postmortems.

When you're mentioning Topspeed Modula-2 compiler, I'm simply curious
what was the performance of Modula-2 compilers in general?

I see that R10 is meant to possibly replace C and wonder what was
situation in the past performance-wise? (E.g. Ada's GNAT is very fast,
according to benchmarks.)


Sincerely,
Gour

[Martin Brown]

Post by Gour
On Fri, 9 Oct 2015 09:17:30 +0100

Post by Martin Brown
I rather liked the way Topspeed did failure tracebacks for
postmortems.

When you're mentioning Topspeed Modula-2 compiler, I'm simply curious
what was the performance of Modula-2 compilers in general?

Of the ones I have used...

Logitech - robust 4 pass slow clunky naive code generation but with
incredibly good debuggers for its time (early 80's) realtime &
postmortem. Originally it had its own clunky overlay system using .LOD
Later versions could generate native executables.

Stoneybrook - faster on a PC but we never seriously used it. Because we
found that the JPI one was significantly better for our requirements.

JPI/Topspeed - stable fast 1 pass fast code generation - you could write
memory mapped graphics drivers in it and get acceptable (not stellar)
performance. Topspeed C was risible - you had to run code through lint
before risking it in the compiler for fear of it crashing. Minor snag
was that it was 16bit code generation emulating 32bit. It had a
traceback on crash trick that would normally point you reliably at the
failing line of code with a fault code. It had non standard libraries
and extensions - better in some ways but ties you to it. It had a
profiler, assembler and debugger capabilities similar to Logitech.

XDS global optimiser is a step up from JPI/Topspeed and has interesting
static code analysis that makes it worth compiling production M2 code
with it just to see if it can find any latent faults. It has a Topspeed
compatibility feature and libraries for modest values of compatible.

The papers I mentioned on their approach to practical static analysis
are still in the wayback machine at:

http://web.archive.org/web/20060130025540/http://www.iis.nsk.su/wasp/papers.html

68k OS9 one whose name escapes me. OK but had limitations where embedded
code in EPROM was concerned requiring some tricky assembler. I didn't
work directly on that project but reviewed some of the code especially
the dangerous bindings between M2 and ASM.

I expect the M2 FAQ will detail another take on the various compilers
although I cannot offhand think of any public benchmark comparisons.

Post by Gour
I see that R10 is meant to possibly replace C and wonder what was
situation in the past performance-wise? (E.g. Ada's GNAT is very fast,
according to benchmarks.)

We are talking of compiler technologies on PCs & VAXes dating from
around three decades ago here (XDS is more recent and smarter). Their
optimisations if any were quite rudimentary. JPI M2 was exceptional in
its day and v1.17 for DOS was a particularly good vintage from 1988.

Logitech & Topspeed were available on PCs for both DOS and OS/2.

Initially the M2R10 bootstrap compiler need only generate correct code
although it would be nice to be able to extend it later. Optimimising is
a luxury for the production compiler after you have the basic
functionality (for the same reason I'd suggest only supporting a minimal
required subset of types in the bootstrap compiler).

[Gour]

On Fri, 9 Oct 2015 11:55:31 +0100

Post by Martin Brown
We are talking of compiler technologies on PCs & VAXes dating from
around three decades ago here (XDS is more recent and smarter). Their
optimisations if any were quite rudimentary. JPI M2 was exceptional
in its day and v1.17 for DOS was a particularly good vintage from
1988.

Well, my curiousity was how is Modula-2 language, in general, easy/hard
for compiler writers and what can we expect from R10.

Considering that one of the R10's goals is "Fully compliant reference
compiler (post-bootstrap) generating C99 and LLVM IR." it has good
prospect to deliver good results.


Sincerely,
Gour

[Martin Brown]

Post by Gour
On Fri, 9 Oct 2015 11:55:31 +0100

Post by Martin Brown
We are talking of compiler technologies on PCs & VAXes dating from
around three decades ago here (XDS is more recent and smarter). Their
optimisations if any were quite rudimentary. JPI M2 was exceptional
in its day and v1.17 for DOS was a particularly good vintage from
1988.

Well, my curiousity was how is Modula-2 language, in general, easy/hard
for compiler writers and what can we expect from R10.

In principle M2 is good for compiler writers generating native code.

The JPI single pass compiler even with its limitations was a tour de
force. If you go via a C compiler to native code then a few speed up
tricks are not available. Basically because M2 is a cleaner language
certain more aggressive optimisations are safe in M2 but not in C.

Hopefully someone familiar with modern optimising compiler construction
will chime in here with what they were. I can remember this much but I
cannot remember any of the details from so far back.

That said more effort has been expended on optimising C compilers than
on any other language except perhaps Fortran.

Post by Gour
Considering that one of the R10's goals is "Fully compliant reference
compiler (post-bootstrap) generating C99 and LLVM IR." it has good
prospect to deliver good results.

The final native code generation step will depend critically on the
optimisation capabilities of the C99 compiler used as the backend. A
modern optimising compiler can do wonders if given the opportunity.

[trijezdci]

Post by Gour
My suggestion was that maybe by re-writing m2c build system with
something like cmake/waf/scons/whatever...it would be possible to
fix build on Windows. What do you think about it?

I think having a CMake based build system for m2c would be of great value.

Not only for building m2c on various targets for the bootstrap but also we may use the expertise gained from it to do a CMake based build system for the M2R10 compiler itself.

If you are willing to invest the effort, go for it.

Post by Gour
E.g. Ada's GNAT is very fast, according to benchmarks.

Last time I looked, GNAT was a front end for GCC, it generates an intermediate representation called SIMPLE which is common to all GCC compiler front ends. This intermediate code will eventually go through the very same optimisation that any GNU C source would go through assuming the same compilation settings.

For the most part, execution speed of the generated code is a product of the compiler back end, not a function of the language.

Languages like Python and Ruby are considered slow (and typically they are) because they forego native code generation. Their code is interpreted at some level and the performance is then a product of the virtual machine they run on, not a function of the language in and of itself.

Of course there are language features that just take more time. Late bound language features often take more time to execute regardless of whether there is intermediate code interpretation or compiled native code.

However, when you compare languages that lack most if not all these kinds of features such as most statically compiled languages like Ada, Modula-2, Pascal and C, then you will find that the execution speed is first and foremost a product of the compiler back end, not a function of the language.

Having said that, an optimiser can often do more and better optimisation work when it is passed extra information about the source it is processing. Some optimisers try to derive the extra information from extensive source code analysis, some have an IR that may be considered annotated.

If you have an annotated IR you could pass annotations to the back end that the back end can use to do a more thorough job at optimisation. In some cases certain optimisations can only reliably be done if certain information is available and the optimiser has to stand back if the information is unavailable.

LLVM IR is designed such that the back end gets a lot more information about the input source than what a compiler back end would usually see. This represents plenty of opportunity for very verbose languages like Ada and Modula-2 to pass information to the back end that would otherwise be hard to come by or unobtainable altogether. I expect us to be able to take advantage of that.

If GNAT has significantly improved their code output over GNU C or other GCC front ends, then I would suspect that they have gone deeper into the back end and bypassed the SIMPLE stage, or they may have written their own back end by now and only retain the GNAT name because it would be a pain to rename the product.

Post by Gour
Well, my curiousity was how is Modula-2 language, in general, easy/hard
for compiler writers

As a general rule of thumb, the things that make a language hard for compiler writers are

(1) large size
(2) quirky grammar
(3) lots of exceptional rules in the semantics

And the opposites make a language easier for compiler writers

(1) small size
(2) clean grammar, ideally LL(1)
(3) few exceptional rules in the semantics

As for the worst modern offenders, C++ is most likely the champion.

Modula-2 has always been in the small/clean/few exceptions camp. In classic Modula-2 the scoping rules for local modules were probably the biggest challenge in respect of #3 but in M2R10 we have removed local modules.

A lot of the syntax sugar we have in M2R10 is resolved into ordinary library procedure and function calls by substitutions on the syntax tree. I'd say this could potentially be a nightmare for a single-pass compiler but in a multi-pass compiler that will naturally build a syntax tree, this is straightforward.

[Gour]

On Fri, 9 Oct 2015 05:24:58 -0700 (PDT)

Post by trijezdci
I think having a CMake based build system for m2c would be of great value.

Good.

Post by trijezdci
Not only for building m2c on various targets for the bootstrap but
also we may use the expertise gained from it to do a CMake based
build system for the M2R10 compiler itself.
If you are willing to invest the effort, go for it.

OK. Will invest some time into it...

Post by trijezdci
Modula-2 has always been in the small/clean/few exceptions camp. In
classic Modula-2 the scoping rules for local modules were probably
the biggest challenge in respect of #3 but in M2R10 we have removed
local modules.

Sounds good.


Sincerely,
Gour

[tbreeden]

Post by Martin Brown
Stoneybrook - faster on a PC but we never seriously used it. Because we
found that the JPI one was significantly better for our requirements.

I want to put in a plug for StonyBrook. I used it pretty intensively for about ten+
years and I can't image a better platform for Windows M2 developement.

It's very stable, very fast compiling, with a very nice IDE,
good conditional compiling pragmas,
producing fast code with a sophistocated optimizing options.

Best of all is the Source Level Debugger integrated into it.

It follows ISO Specs, but includes some TopSpeed libraries for compatibility.
(ISO libr sources included, donated by Rick Sutcliffe et.al.) PIM3 code
should be easy to tweak if necessary.

I suspect that any trouble caused by needing to change
TopSpeed code would be more than repaid by ease of
continuing with StonyBrook.

Downside is, of course, that it is ended. It seems that the
ADW compiler is exactly a late StonyBrook one, but I
haven't tried it. StonyBrook works flawlessly in Win 7,
and I expect no problems in Win 8 (and probably Win 10),
but I'm not using much Windows just now.

Even if not used as a bootstrap compiler for Windows, it
might would be worth while for the Windows compiler
developer to study it's optimizing output.

Optimizations
Space verses Time optimization
Conditional common sub-expression elimination
Variable lifetime analysis and dead store elimination
IA-32 architecture register parameter passing
Cross module register usage
IA-32 Architecture cross module register parameter passing

I've got StonyBrook on Win 7 and can post or email more details
and text excerpts from the StonyBrook docs on TopSpeed
compatibility and SB compiler optimization if anyone wants.

Tom

[Martin Brown]

Post by tbreeden

Post by Martin Brown
Stoneybrook - faster on a PC but we never seriously used it. Because we
found that the JPI one was significantly better for our requirements.

I want to put in a plug for StonyBrook. I used it pretty intensively for about ten+
years and I can't image a better platform for Windows M2 developement.

Just for clarity I was talking about ancient pre Windows versions of
their compiler and we had a requirement of future OS/2 capability.

Windows3 was in the future at the point where we had to choose.

Post by tbreeden
It's very stable, very fast compiling, with a very nice IDE,
good conditional compiling pragmas,
producing fast code with a sophistocated optimizing options.
Best of all is the Source Level Debugger integrated into it.
It follows ISO Specs, but includes some TopSpeed libraries for compatibility.
(ISO libr sources included, donated by Rick Sutcliffe et.al.) PIM3 code
should be easy to tweak if necessary.
I suspect that any trouble caused by needing to change
TopSpeed code would be more than repaid by ease of
continuing with StonyBrook.
Downside is, of course, that it is ended. It seems that the
ADW compiler is exactly a late StonyBrook one, but I
haven't tried it. StonyBrook works flawlessly in Win 7,
and I expect no problems in Win 8 (and probably Win 10),
but I'm not using much Windows just now.
Even if not used as a bootstrap compiler for Windows, it
might would be worth while for the Windows compiler
developer to study it's optimizing output.
Optimizations
Space verses Time optimization
Conditional common sub-expression elimination
Variable lifetime analysis and dead store elimination
IA-32 architecture register parameter passing
Cross module register usage
IA-32 Architecture cross module register parameter passing
I've got StonyBrook on Win 7 and can post or email more details
and text excerpts from the StonyBrook docs on TopSpeed
compatibility and SB compiler optimization if anyone wants.
Tom

I had not intended to run their compiler down. I am pretty sure they
gave me their chess program in the dim and distant past.

[Chris Burrows]

Post by Gour
On Fri, 9 Oct 2015 09:17:30 +0100
When you're mentioning Topspeed Modula-2 compiler, I'm simply curious
what was the performance of Modula-2 compilers in general?

The following articles from the The Journal of Pascal, Ada and Modula-2 include benchmarks of various Modula-2 systems:

"Modula-2 Implementation Overview" by Pieter H Hartel and Dolf Starreveld, Vol 4, No 4 Jul / Aug 1985. A comparison of 35 Modula-2 / Pascal systems.

"Benchmark Test Results for Modula-2 Compiler" by Gunter Dotzel, Vol 4, No 2 Mar / Apr 1985. A comparison of 8 Modula-2 systems.

There are also some benchmark test results in ETH Dissertation No 7195 Code Generation and The Lilith Architecture by Christian Jacobi, 1982. This also includes a section titled 'Short aside on optimality and optimization'.

ETH Technical Report No 40. The Personal Computer Lilith By N Wirth, April 1981
A comparison of three systems.

You can download a copy of the above two documents from our website:

http://www.cfbsoftware.com/modula2

Diss. ETH No. 8477 Modula-2 auf einem RISC: Realisierung und Vergleich. 1988. The infamous Sieve benchmark is analysed with details of the code generated for three different Modula-2 systems.

Regards,
Chris Burrows
CFB Software

[trijezdci]

Post by Martin Brown
It might be worth using a pair of compilers for development (or which
for Windows I'd recommend the free XDS one but using a PIM3 subset).

Can you elaborate on "PIM subset"? I didn't think that XDS had any such option. I had assumed that this would fall back on the developer to write their own compatibility layers of libraries and for built-ins.

Post by Martin Brown
avoids getting caught out by some minor quirk or extension in a major
compiler. You might have to add a few shims here and there to obtain
exact code compatibility one with the other, but we have always found
that code written to run on multiple compilers ends up cleaner.

Fair enough, but I'd rather use a compiler of the same dialect then.

Post by Martin Brown
BTW Whilst developing the compiler spare a thought for debugging tools
(or will this compiler initially output C code rather than binary?).

For the bootstrap all we need is C99 output.

http://modula-2.net/m2r10/pmwiki.php?n=Implementation.Compiler

Post by Martin Brown
I'd suggest only supporting a minimal
required subset of types in the bootstrap compiler

Since the pre-bootstrap version is written in PIM, everything needed to bootstrap the compiler has to be written in PIM. This established the intersection of PIM and R10 as a kind of baseline from which to expand post-bootstrap.

However, the idea is to write parser rules already for the full grammar and simply emit a message for unsupported syntax. This way we will already have a syntax checker for R10 at the earliest possible.

[Martin Brown]

Post by trijezdci

Post by Martin Brown
It might be worth using a pair of compilers for development (or which
for Windows I'd recommend the free XDS one but using a PIM3 subset).

Can you elaborate on "PIM subset"? I didn't think that XDS had any such option.

Some PIM DEFs are there and I presume the library support them too.
The prehistoric RS232 support isn't there. TBH I have used TS for so
long that I can't remember what modules PIM3 includes.

InOut, LongInOut, MathLib0 and RealInOut are all in PIM.
FileSyst is their own and not the same as I recal for PIM
FIO for TS is closer and a shim might be possible.

Note capitalisation is not the same as PIM3 MATHLIB0 so shim needed.

Post by trijezdci
I had assumed that this would fall back on the developer to write
their own compatibility layers of libraries and for built-ins.

I think you might find it worth a look. Even if you only run code
through their compiler with fake PIM DEF/SYM pairs to satisfy module
boundary conditions it may still be worth it. I suspect a modest amount
of effort would allow DOS style PIM3 libraries to be emulated.

Post by trijezdci

Post by Martin Brown
avoids getting caught out by some minor quirk or extension in a major
compiler. You might have to add a few shims here and there to obtain
exact code compatibility one with the other, but we have always found
that code written to run on multiple compilers ends up cleaner.

Fair enough, but I'd rather use a compiler of the same dialect then.

Oh indeed. I suspect some PIM3 shims will be essential. My recollection
is that there were niggling differences from PIM here and there and
there might be a show stopper if you want absolute pin compatibility.

It might still allow someone working on Windows to do stuff that with
minimal rework could then be compiled with the production compiler.

One obvious niggle was it doesn't get on with long directory names or
being installed in a readonly directory. Mine is installed at:

C:/tools/xds

ISTR there was a trick to making the debugger fly as well.

If you let windows default install it the path length is already close
to overflowing before you start which makes compiling impossible.

Post by trijezdci

Post by Martin Brown
BTW Whilst developing the compiler spare a thought for debugging tools
(or will this compiler initially output C code rather than binary?).

For the bootstrap all we need is C99 output.
http://modula-2.net/m2r10/pmwiki.php?n=Implementation.Compiler

Post by Martin Brown
I'd suggest only supporting a minimal
required subset of types in the bootstrap compiler

Since the pre-bootstrap version is written in PIM, everything needed
to bootstrap the compiler has to be written in PIM. This established the
intersection of PIM and R10 as a kind of baseline from which to

expand post-bootstrap.

Understood.

Post by trijezdci
However, the idea is to write parser rules already for the full grammar
and simply emit a message for unsupported syntax. This way we will

already

Post by trijezdci
have a syntax checker for R10 at the earliest possible.

That makes perfect sense.

[trijezdci]

Post by Martin Brown

Post by trijezdci
Can you elaborate on "PIM subset"? I didn't think that XDS had any such option.

Some PIM DEFs are there and I presume the library support them too.
The prehistoric RS232 support isn't there. TBH I have used TS for so
long that I can't remember what modules PIM3 includes.

Ok, I seen now what you meant. There is no compiler support, just some libraries.

Well, the trouble is that the team member who wants to use Windows is not versed in Modula-2 yet, he's done compiler work but not Modula-2. If we let him use an ISO compiler, any bet that ISOisms will make it into the code which will then have to be removed again. This is not really what I have in mind to be honest.

Also, it will fall on me or Rick to write the compatibility layer then and neither I nor Rick use Windows. So, we'd have to go through the trouble of setting up a Windows box just for building a compatibility layer for ISO compilers on Windows which is not really a priority item at this point in time.

I think it will be less trouble to use M2M for DOS then, using DOSbox. I have tested that already.

M2M is PIM2 and therefore requires an explicit EXPORT directive for all identifiers you want to export which would need to be removed for compiling with a PIM3 compiler. This is an inconvenience but its less trouble than setting up a Windows environment to develop, build and test an ISO compatibility layer.

Post by Martin Brown
InOut, LongInOut, MathLib0 and RealInOut are all in PIM.
FileSyst is their own and not the same as I recal for PIM
FIO for TS is closer and a shim might be possible.

On m2c we are not likely to use any of that because we will use the C stdio library underneath our own FileIO and FileSystem libraries. We would need to port those two and cover all IO in the process.

Post by Martin Brown
I think you might find it worth a look. Even if you only run code
through their compiler with fake PIM DEF/SYM pairs to satisfy module
boundary conditions it may still be worth it. I suspect a modest amount
of effort would allow DOS style PIM3 libraries to be emulated.

The key modules are FileIO and FileSystem.

We have stripped down versions of those for the bootstrap compiler

https://bitbucket.org/trijezdci/m2r10/src/tip/bootstrap/m2bst/FileIO.def

https://bitbucket.org/trijezdci/m2r10/src/tip/bootstrap/m2bst/FileSystem.def

If we can port those to ISO, this might be most of the compatibility layer right there, but still I expect surprises along the way and extra effort. I'd feel more comfortable if we stick to PIM for now and tackle ISO compatibility later. My biggest concern is to have newcomers to the language start out on an ISO compiler when we are using PIM to write compiler for yet another dialect. All this adds cognitive load.

Post by Martin Brown

Post by trijezdci

Post by Martin Brown
avoids getting caught out by some minor quirk or extension in a major
compiler. You might have to add a few shims here and there to obtain
exact code compatibility one with the other, but we have always found
that code written to run on multiple compilers ends up cleaner.

Fair enough, but I'd rather use a compiler of the same dialect then.

Oh indeed. I suspect some PIM3 shims will be essential. My recollection
is that there were niggling differences from PIM here and there and
there might be a show stopper if you want absolute pin compatibility.

It is more likely that we recruit collaborators who have never used Modula-2 before than those who have. I want to avoid burdening them with unnecessary historic ballast where possible.

In 2010 when we had the first iteration of our revision to a point we thought we'd implement I started work on a compiler and I did it all in C99. A lot of our code for the present compiler is salvaged from that earlier effort. Back then we had folks who were interested to help but didn't know much C. Now it is the other way round. But the important difference is that thanks to Sinuhe's fork we now have m2c actually working even if it has a few bugs we must work around. Back then I was unable to get it to work. So, I am fine with the decision to write the compiler in PIM even if we receive interest from folks who don't know Modula-2. They'll have to learn it anyway, but I think they better start with PIM not ISO.

Post by Martin Brown
It might still allow someone working on Windows to do stuff that with
minimal rework could then be compiled with the production compiler.

Well, I think Gour's idea to add a CMake based build system setup to m2c has a lot of merit.

Not only will this make m2c more accessible, but we'd have a template how to do a CMake build system for a Modula-2 compiler and could use that to do a CMake based build system for our bootstrap compiler as well, so it can be easily built on different platforms for the bootstrap.

Post by Martin Brown
One obvious niggle was it doesn't get on with long directory names or
being installed in a readonly directory.

:-)

[Gour]

On Fri, 9 Oct 2015 10:58:05 -0700 (PDT)

Post by trijezdci
It is more likely that we recruit collaborators who have never used
Modula-2 before than those who have. I want to avoid burdening them
with unnecessary historic ballast where possible.

Iow, for someone like myself, wishing to learn Modula-2, you recommend
to stay with PIM dialect?

Post by trijezdci
Well, I think Gour's idea to add a CMake based build system setup to
m2c has a lot of merit.

I'll do my best, although I never used it, although was seriously
considering it in the past, but autoconf-izing was the only build
project which I did.

I also wonder if knowing CMake would be helpful for writing Modula-2
(R10) programs in the future or build systems are not really required
for Modula-2 apps?

Post by trijezdci
Not only will this make m2c more accessible, but we'd have a template
how to do a CMake build system for a Modula-2 compiler and could use
that to do a CMake based build system for our bootstrap compiler as
well, so it can be easily built on different platforms for the
bootstrap.

I'm glad that the attempt might yield even more fruits. ;)


Sincerely,
Gour

[trijezdci]

Post by Gour

Post by trijezdci
It is more likely that we recruit collaborators who have never used
Modula-2 before than those who have. I want to avoid burdening them
with unnecessary historic ballast where possible.

Iow, for someone like myself, wishing to learn Modula-2, you recommend
to stay with PIM dialect?

That's not what I wrote.

I was talking about new recruits to the project who want to help on the compiler but don't know Modula-2. Naturally they will need to learn it, but since we use PIM for the bootstrap compiler, they will need to know and work with PIM. At the same time they need to keep PIM and R10 apart. If they start out with an ISO compiler, they will also have to keep PIM and ISO apart. Clearly they'd be better of only having to worry about PIM at first.

Post by Gour
I also wonder if knowing CMake would be helpful for writing Modula-2
(R10) programs in the future or build systems are not really required
for Modula-2 apps?

The difference between CMake and Autotools is that of a Swiss Army knife and a huge pile of smelly garbage. You may find various things in the garbage pile that could be used instead of the Swiss Army knife, but it is not going to be easy nor is it going to be pleasant.

Knowing CMake means whatever project you are going to do where you make the decisions, you can use CMake instead of Autotools. That alone would be worth it.

Strictly speaking, a good Modula-2 development system has its own build system so to speak. However, CMake is not just a build system but also a configuration management system that will keep track of non-code resources, especially for GUI apps there may be many of those.

To give one example, on OSX you generally need Apple's IDE called Xcode to build apps, not just for linking and building but to put all those resources that GUI apps require into the right places, take care of different localised versions etc etc. Last time I looked which was several years back, CMake could build OSX apps without the use of XCode and it could build Windows and X11 GUI apps too, all from the same source tree managing different sets of source files, object files and resources.

Post by Gour

Post by trijezdci
Not only will this make m2c more accessible, but we'd have a template
how to do a CMake build system for a Modula-2 compiler and could use
that to do a CMake based build system for our bootstrap compiler as
well, so it can be easily built on different platforms for the
bootstrap.

I'm glad that the attempt might yield even more fruits. ;)

The only caveat I found about CMake was that you needed to buy the book to get up to speed.

Some folks have learned it by trial and error, but I didn't have time for that, nor do I have the nerve. The sale of the book funds the project which is fair enough, but it has the effect that there is little documentation available outside of the book. I am not sure if this has changed by now.

My book is for version 2.2 which is probably outdated by now, but if you have questions, I could take a look at the book and scan the most relevant page to get you unstuck. Even though it is probably advisable to buy the latest version of the book. I paid about 75 USD years ago.

good luck

[Gour]

On Fri, 9 Oct 2015 14:30:34 -0700 (PDT)

Post by trijezdci
That's not what I wrote.

OK, but do you recommend that considering that, afaik, R10 will be
closer to PIM than ISO dialect?

Post by trijezdci
Clearly they'd be better of only having to worry about PIM at first.

OK.

Post by trijezdci
Strictly speaking, a good Modula-2 development system has its own
build system so to speak. However, CMake is not just a build system
but also a configuration management system that will keep track of
non-code resources, especially for GUI apps there may be many of
those.

That's what I'm curious about? CMake in the context of working with
Modula-2 project?

Otherwise, I'm aware of CMake's merit over autotools and build systems
in general.

Post by trijezdci
The only caveat I found about CMake was that you needed to buy the book to get up to speed.

The present book seems to be a bit outdated, but I wonder if you like
the style & content of the book?

Post by trijezdci
Some folks have learned it by trial and error, but I didn't have time
for that, nor do I have the nerve. The sale of the book funds the
project which is fair enough, but it has the effect that there is
little documentation available outside of the book. I am not sure if
this has changed by now.

I do not mind buying the book if it is the good one - it's the habit I
got on the university and prefer having book over online docs when
possible.

Post by trijezdci
My book is for version 2.2 which is probably outdated by now, but if
you have questions, I could take a look at the book and scan the most
relevant page to get you unstuck. Even though it is probably
advisable to buy the latest version of the book. I paid about 75 USD
years ago.

Let me see how it goes..

Post by trijezdci
good luck

Thank you.


Sincerely,
Gour