Example of handling "mixed" end-of-line characters in text files (ISO m2)

[c***@gmail.com]

Hello:

I previously created a Google Code page to attempt a simplified end-of-line processing of text files in ISO m2.
See "m2-text-filters - ISO Modula-2 Text Filters - Google Project Hosting"
<https://code.google.com/p/m2-text-filters/>

I attempted to emulate the approach of N. Wirth's "Programming in Modula-2". This simple approach is seen in Logitech's Modula-2 system and the Lilith, and probably other m2 systems who used the InOut library definitions from PIM2.

There, a single EOL character constant is returned on reading the end-of-line in a text file, so end-of-line does not appear to require special treatment. After you read the end-of-line, you are ready to read the first character of the next line.

But in ISO m2, SkipLine is generally needed when an end-of-line is encountered.
On the Google Code site, I hid the call to SkipLine and returned a single character constant, EOL. I wanted to emulate PIM2's simplicity.

But where I failed was in treating end-of-line (eol) more generally as a CR LF pair or a single LF or a single CR. The programs on the Google Code site are only tested on text lines terminated with the single eol character of the p1 Modula-2 system, the LF character.

I created a blog, Modula2Squad DOT com, to present a possible solution to this problem.
<http://www.modula2squad.com/>

My second blog entry presents an example program, CountLinesChars, which uses RawIO and StreamFile libraries and is supposed to handle any end-of-line (eol), which is defined by the EBNF rule, eol = cr [ lf ] | lf.

It has been tested only on p1 Modula-2.

I welcome testing the 2 example programs on other ISO m2 systems such as ADW m2 and gm2.

Modifications will probably be needed to get the programs to run correctly on these other ISO m2 systems. The end-of-line handling by RawIO.ReadChar itself might need modification.

Another possible modification is in the calls to ProgramArgs.NextArg().
ProgramArgs.NextArg() is first called in these examples to skip the programname, so the next argument read is a named input text file. Other m2 systems already skip the programname, so there you would need to remove the extra call to ProgramArgs.NextArg().

Carl

[j***@gmail.com]

The other day I needed to convert an Oberon source into Linux processable format. Oberon uses a single CR as EOL, so I created the following Ob2Unix source:

MODULE ob2unix;

(* Convert Oberon format text files to Unix format.
Copyleft ***@gmail.com

This is GPL software

version 0.15 Jan 2009 *)

IMPORT InOut;

VAR ch: CHAR;

BEGIN
LOOP
InOut.Read (ch);
IF InOut.EOF () THEN EXIT END;
IF ch = 15C THEN ch := 12C END;
InOut.Write (ch)
END;
InOut.WriteLn;
InOut.WriteBf
END ob2unix.

It is used as ob2unix <source >dest

ob2unix is written for the Mocka M2 compiler. In essence, the last WriteBf is not required.

[c***@gmail.com]

Hello Jan:

I wish I had real experience with Oberon.
I have some experience with Oberon microsystems Component Pascal.

Q1. What version of Oberon do you use, jan?

Q2. a.) Does it use the traditional Oberon interface with 3-button mouse?
b.) If so, would if work well with a trackpad?

Your example shows how much better it is if the end-of-line on input is just 1 character.

The example on my blog, CountLinesChars only reads characters. If anyone is thinking of writing to the terminal or a file, the characters read using Modula2's RawIO, I recommend further processing of the raw input before writing.

Carl
---

Post by c***@gmail.com
I previously created a Google Code page to attempt a simplified end-of-line processing of text files in ISO m2.
See "m2-text-filters - ISO Modula-2 Text Filters - Google Project Hosting"
<https://code.google.com/p/m2-text-filters/>
I attempted to emulate the approach of N. Wirth's "Programming in Modula-2". This simple approach is seen in Logitech's Modula-2 system and the Lilith, and probably other m2 systems who used the InOut library definitions from PIM2.
There, a single EOL character constant is returned on reading the end-of-line in a text file, so end-of-line does not appear to require special treatment. After you read the end-of-line, you are ready to read the first character of the next line.
But in ISO m2, SkipLine is generally needed when an end-of-line is encountered.
On the Google Code site, I hid the call to SkipLine and returned a single character constant, EOL. I wanted to emulate PIM2's simplicity.
But where I failed was in treating end-of-line (eol) more generally as a CR LF pair or a single LF or a single CR. The programs on the Google Code site are only tested on text lines terminated with the single eol character of the p1 Modula-2 system, the LF character.
I created a blog, Modula2Squad DOT com, to present a possible solution to this problem.
<http://www.modula2squad.com/>
My second blog entry presents an example program, CountLinesChars, which uses RawIO and StreamFile libraries and is supposed to handle any end-of-line (eol), which is defined by the EBNF rule, eol = cr [ lf ] | lf.
It has been tested only on p1 Modula-2.
I welcome testing the 2 example programs on other ISO m2 systems such as ADW m2 and gm2.
Modifications will probably be needed to get the programs to run correctly on these other ISO m2 systems. The end-of-line handling by RawIO.ReadChar itself might need modification.
Another possible modification is in the calls to ProgramArgs.NextArg().
ProgramArgs.NextArg() is first called in these examples to skip the programname, so the next argument read is a named input text file. Other m2 systems already skip the programname, so there you would need to remove the extra call to ProgramArgs.NextArg().
Carl

[j***@gmail.com]

Post by c***@gmail.com
I wish I had real experience with Oberon.

Oberon is just M2 without the LOOP/END, WITH acts differently and you don't need the caret in dynamic memory. And it has type inherancy builtin.

Post by c***@gmail.com
Q1. What version of Oberon do you use, jan?

obc version 2.9.3 It is cross platform and works very neat. And Spivey still maintains it.
http://spivey.oriel.ox.ac.uk/corner/Installing_OBC_release_2.9

http://fruttenboel.verhoeven272.nl/obc/

Post by c***@gmail.com
Q2. a.) Does it use the traditional Oberon interface with 3-button mouse?

Nope, just a very nice oberon compiler for Win, Lin and Mac. It runs in GUI mode. obc generates something similar to JAVA byte code, but then without the JAVA.

Post by c***@gmail.com
b.) If so, would if work well with a trackpad?

obc is a compiler, not an OS.

Post by c***@gmail.com
Your example shows how much better it is if the end-of-line on input is just 1 character.

That is hardly a problem.... You can make constructs a la

IF ch = CR THEN
Nextchar (ch);
IF ch = LF THEN <replace CR/LF by whatever you like> END
END

But if that is a problem you could use my approach as explained in

http://fruttenboel.verhoeven272.nl/obc/obc9.html

where I buffer a full 6 MB data file in memory and walk across using pointers. Therefore I can also easily unread characters simply by changing the index pointer.

Post by c***@gmail.com
The example on my blog, CountLinesChars only reads characters. If anyone is thinking of writing to the terminal or a file, the characters read using Modula2's RawIO, I recommend further processing of the raw input before writing.

I would be in favor of just using InOut since a filter is more flexible than a program that uses file I/O.

[c***@gmail.com]

Hello Jan:

Are you still using Mocka Modula-2?
Does it have an InOut library?

I like InOut for it's simplicity and to do quick testing.
ISO Modula-2 doesn't provide an InOut library and that is why I have made an attempt to emulate InOut end-of-line handling.

I think some m2 programmers might not want to bother to convert their "PIM2"-style m2 programs to use ISO SkipLine.

However, there are excellent examples of direct use of SkipLine in ISO m2:

1. Rick Sutcliffe's book, "Modula-2: Abstractions for Data and Programming Structures (Using ISO-Standard Modula-2)", Chapter 8.
<http://www.arjay.bc.ca/Modula-2/Text/index.html>

2. Elmar Baumgart, ModulaWare,
The ModulaTor (Oberon-2 and Modula-2 Technical Publication)
Mar-1992
<http://www.modulaware.com/mdlt20.htm>

It might be an interesting project for someone to create an real InOut library emulation in ISO m2, but that is not something I probably am going to attempt now.

GNU Modula-2 (gm2) has an InOut library but I am not familiar with it.

Carl Glassberg
---

Post by c***@gmail.com
I previously created a Google Code page to attempt a simplified end-of-line processing of text files in ISO m2.
See "m2-text-filters - ISO Modula-2 Text Filters - Google Project Hosting"
<https://code.google.com/p/m2-text-filters/>
I attempted to emulate the approach of N. Wirth's "Programming in Modula-2". This simple approach is seen in Logitech's Modula-2 system and the Lilith, and probably other m2 systems who used the InOut library definitions from PIM2.
There, a single EOL character constant is returned on reading the end-of-line in a text file, so end-of-line does not appear to require special treatment. After you read the end-of-line, you are ready to read the first character of the next line.
But in ISO m2, SkipLine is generally needed when an end-of-line is encountered.
On the Google Code site, I hid the call to SkipLine and returned a single character constant, EOL. I wanted to emulate PIM2's simplicity.
But where I failed was in treating end-of-line (eol) more generally as a CR LF pair or a single LF or a single CR. The programs on the Google Code site are only tested on text lines terminated with the single eol character of the p1 Modula-2 system, the LF character.
I created a blog, Modula2Squad DOT com, to present a possible solution to this problem.
<http://www.modula2squad.com/>
My second blog entry presents an example program, CountLinesChars, which uses RawIO and StreamFile libraries and is supposed to handle any end-of-line (eol), which is defined by the EBNF rule, eol = cr [ lf ] | lf.
It has been tested only on p1 Modula-2.
I welcome testing the 2 example programs on other ISO m2 systems such as ADW m2 and gm2.
Modifications will probably be needed to get the programs to run correctly on these other ISO m2 systems. The end-of-line handling by RawIO.ReadChar itself might need modification.
Another possible modification is in the calls to ProgramArgs.NextArg().
ProgramArgs.NextArg() is first called in these examples to skip the programname, so the next argument read is a named input text file. Other m2 systems already skip the programname, so there you would need to remove the extra call to ProgramArgs.NextArg().
Carl

[j***@gmail.com]

Hello Carl,

Post by c***@gmail.com
Are you still using Mocka Modula-2?

For all Modula-2 I use Mocka. A very stable compiler producing excellent results.

Post by c***@gmail.com
Does it have an InOut library?

Of course. It is 100% PIM compatible.

Post by c***@gmail.com
I like InOut for it's simplicity and to do quick testing.
ISO Modula-2 doesn't provide an InOut library and that is why I have made an attempt to emulate InOut end-of-line handling.

I never use M2's builtin EOL constant. I just hunt for LF or CR and then act accordingly.

Post by c***@gmail.com
I think some m2 programmers might not want to bother to convert their "PIM2"-style m2 programs to use ISO SkipLine.

SkipLine is definitely the result of a committee. After they all included their favorite procedures, Dopey still was in a 'virgin' state: none of his proposed procedures was included in the standard, so they all agreed that his 'SkipLine' was adopted, just to give Dopey the feeling his efforts were not in vein.

Post by c***@gmail.com
1. Rick Sutcliffe's book

There are excellent examples of any procedure or function in any book. If you want to study M2, just use the KN King book or one of Wirths books. Skipline essentially is:

REPEAT
InOut.Read (ch)
UNTIL (c=CR) OR (c=LF) OR InOut.EOF ()

It is arguable whether this kind of 'procedure' needs a place in a high level library. Unless it was to prevent Dopey from starting to cry.

Remember: ISO killed Modula-2.

Post by c***@gmail.com
GNU Modula-2 (gm2) has an InOut library but I am not familiar with it.

GNU M2 is also the result of a committee so it should not be considered as Modula-2 but more Integral-2. It uses Modula-2 syntax and that's where all similarities end.

GNU M2 needed me to install loads of outdated C libraries to get compiled and then still the compiler was slow a turd in a funnel. A real programming language needs a dictator. Not a groupm of people who decide democratical way what should be the properties.
That's why I stick to Mocka. It may be old but it is good. And for modern application I use obc because Spivey still maintains it.

[Nemo]

Post by j***@gmail.com
For all Modula-2 I use Mocka. A very stable compiler producing excellent results.

It is a good compiler but only works on Intel. No cgd was ever released
for others (such as ARM, MIPS, Sparc, or PPC). Even so, the only Beg
released (1.75) requires rather old Linux libraries.

Post by j***@gmail.com
Remember: ISO killed Modula-2.

So true... I really wish that they had released their rationale. Many
of their of decisions border on the lunatic.

Post by j***@gmail.com
GNU M2 is also the result of a committee

Gm2 is the work of Gaius Mulley, not a committee.

Post by j***@gmail.com
GNU M2 needed me to install loads of outdated C libraries to get compiled

I do not understand your comment. Gm2 is attached to gcc-4.7.1. At
least it has a chance of being portable to something else besides Intel.

N.

[j***@gmail.com]

Post by Nemo
It is a good compiler but only works on Intel. No cgd was ever released
for others (such as ARM, MIPS, Sparc, or PPC). Even so, the only Beg
released (1.75) requires rather old Linux libraries.

That is because the compiler stopped being further developed before these new architectures were introduced.
I recently installed Mocka on a Slackware 14 system and it just runs fine.
The cgd is closed source since the compiler was commercially marketed, just like all other software in those days.

If you have both time, experience and brains (I lack two of these 3) you can take the ACK and tidy up the sources. The ACK has been upped lately and it can be compiled from source. Some people are trying to make it 64bit ready. The ACK is a very good compiler. It produces small executables for many architectures. It has a C, Modula-2 and Pascal FrontEnd and the Pascal frontend produces the smallest code.

Post by Nemo
Gm2 is the work of Gaius Mulley, not a committee.

Sometimes I get the idea he IS a committee.... ;)

Post by Nemo

Post by j***@gmail.com
GNU M2 needed me to install loads of outdated C libraries to get compiled

I do not understand your comment. Gm2 is attached to gcc-4.7.1. At
least it has a chance of being portable to something else besides Intel.

The last time I tried to install GNU M2 I had to download 300 MB of sources, install a lot of backdated libraries and a very outdated gcc compiler. Otherwise I could not build the GNU M2. When I had it installed it was very slow and not PIM compatible (If my memory serves me well).

Let's face it. Modula-2 died in 1988. It is a very nice language with lots of potential. But no comemrcial users and no active development anymore. Even Wirth quit M2 in favor of his Oberon (what a silly name for a compiler).

Spivey's obc is still being maintained. It comes very close to Modula-2. It is fast, portable, relatively modern. It runs on ARM and Intel. On Win and Lin.

The ACK is good but needs a lot of work to get it in a decent shape.

Mocka is good but closed source and only for LinTel.

Perhaps the best project would be to make not a source level port but an object level port: make a program that translates Intel opcodes into ARM opcodes. Sounds like a nice project for Mocka or obc.

[Christoph Schlegel]

Post by j***@gmail.com

Post by Nemo

Post by j***@gmail.com
GNU M2 needed me to install loads of outdated C libraries to get compiled

I do not understand your comment. Gm2 is attached to gcc-4.7.1. At
least it has a chance of being portable to something else besides Intel.

The last time I tried to install GNU M2 I had to download 300 MB of sources, install a lot of backdated libraries and a very outdated gcc compiler. Otherwise I could not build the GNU M2. When I had it installed it was very slow and not PIM compatible (If my memory serves me well).

You do not have to build gm2 by yourself as there are binaries available for Debian Linux which should also work under similar and derived systems like Ubuntu. Experimental binaries for Cygwin32 are also available. Note that it is always a bit tricky to utilize an additionally installed gcc which is not the original gcc of your system. And of course, building gcc with a new frontend is no trivial task. But this should not be interpreted as a problem of gm2.

The development branch of gm2 is currently grafted onto gcc 4.7.4.

The compiler understands all the PIM dialects and ISO. You can use your preferred M2 by using the -fiso, -fpim2, -fpim3 and -fpim4 command line switches.

While everybody who wants can declare this or that programming language dead I don't think it is ok to talk about ongoing projects one does not even know enough to judge about status and success. This is a newsgroup to exchange knowledge and therefore not to be misused for expressing personal believes which damage the reputation of ongoing open source projects based on anything but facts. If gm2 is not the tool for your job - just skip it.

Sorry Jan, I had to.

Christoph

[a***@drrob1.com]

On Wed, 4 Mar 2015 04:33:21 -0800 (PST), Christoph Schlegel

Post by Christoph Schlegel

Post by j***@gmail.com

Post by Nemo

Post by j***@gmail.com
GNU M2 needed me to install loads of outdated C libraries to get compiled

I do not understand your comment. Gm2 is attached to gcc-4.7.1. At
least it has a chance of being portable to something else besides Intel.

The last time I tried to install GNU M2 I had to download 300 MB of sources, install a lot of backdated libraries and a very outdated gcc compiler. Otherwise I could not build the GNU M2. When I had it installed it was very slow and not PIM compatible (If my memory serves me well).

You do not have to build gm2 by yourself as there are binaries available for Debian Linux which should also work under similar and derived systems like Ubuntu. Experimental binaries for Cygwin32 are also available. Note that it is always a bit tricky to utilize an additionally installed gcc which is not the original gcc of your system. And of course, building gcc with a new frontend is no trivial task. But this should not be interpreted as a problem of gm2.
The development branch of gm2 is currently grafted onto gcc 4.7.4.
The compiler understands all the PIM dialects and ISO. You can use your preferred M2 by using the -fiso, -fpim2, -fpim3 and -fpim4 command line switches.
While everybody who wants can declare this or that programming language dead I don't think it is ok to talk about ongoing projects one does not even know enough to judge about status and success. This is a newsgroup to exchange knowledge and therefore not to be misused for expressing personal believes which damage the reputation of ongoing open source projects based on anything but facts. If gm2 is not the tool for your job - just skip it.
Sorry Jan, I had to.
Christoph

I tried, really tried, to use gm2. I found and reported at least a
dozen bugs in its libraries. These were never acknowledged. And then
it did not install on ubuntu 14.04. I beleive that was only recently
fixed.

By that time I moved on.

Totally useless experience for me.

[a***@drrob1.com]

Post by a***@drrob1.com

Post by Christoph Schlegel

Post by j***@gmail.com

Post by Nemo

Post by j***@gmail.com
GNU M2 needed me to install loads of outdated C libraries to get compiled

I do not understand your comment. Gm2 is attached to gcc-4.7.1. At
least it has a chance of being portable to something else besides Intel.

The last time I tried to install GNU M2 I had to download 300 MB of sources, install a lot of backdated libraries and a very outdated gcc compiler. Otherwise I could not build the GNU M2. When I had it installed it was very slow and not PIM compatible (If my memory serves me well).

You do not have to build gm2 by yourself as there are binaries available for Debian Linux which should also work under similar and derived systems like Ubuntu. Experimental binaries for Cygwin32 are also available. Note that it is always a bit tricky to utilize an additionally installed gcc which is not the original gcc of your system. And of course, building gcc with a new frontend is no trivial task. But this should not be interpreted as a problem of gm2.
The development branch of gm2 is currently grafted onto gcc 4.7.4.
The compiler understands all the PIM dialects and ISO. You can use your preferred M2 by using the -fiso, -fpim2, -fpim3 and -fpim4 command line switches.
While everybody who wants can declare this or that programming language dead I don't think it is ok to talk about ongoing projects one does not even know enough to judge about status and success. This is a newsgroup to exchange knowledge and therefore not to be misused for expressing personal believes which damage the reputation of ongoing open source projects based on anything but facts. If gm2 is not the tool for your job - just skip it.
Sorry Jan, I had to.
Christoph

I tried, really tried, to use gm2. I found and reported at least a
dozen bugs in its libraries. These were never acknowledged. And then
it did not install on ubuntu 14.04. I beleive that was only recently
fixed.
By that time I moved on.
Totally useless experience for me.

I learned c++. But added a bunch of macros to give it a much more
modula-2 flavor. This works for me. I wanted to use ncurses w/ gm2,
and that was essentially impossible for me. I even tried Ada and
TextTools but could not get that going.

After I learned c++ w/ my macros-crutch, ncurses was an easy library
to get working.

But I must add that the obc 2.9 comments got my attention.

How easy is it to interface obc 2.9 w/ ubuntu c++, or a library like
ncurses which is in C?

--rob

[j***@gmail.com]

Post by a***@drrob1.com
I learned c++. But added a bunch of macros to give it a much more
modula-2 flavor. This works for me.

Essentially you made a new front-end for the c++ compiler....

Post by a***@drrob1.com
But I must add that the obc 2.9 comments got my attention.
How easy is it to interface obc 2.9 w/ ubuntu c++, or a library like
ncurses which is in C?

http://spivey.oriel.ox.ac.uk/corner/Installing_OBC_release_2.9

I would post that question to Mike Spivey. He may be interested . obc heavily relies on a C-ish language. Here's an excerp from Math.m:

PROCEDURE Sqrt*(x: REAL): REAL IS "*Math_Sqrt";
(* CODE ob_res.f = sqrt(args[0].f); *)

PROCEDURE Sin*(x: REAL): REAL IS "*Math_Sin";
(* CODE ob_res.f = sin(args[0].f); *)

PROCEDURE Cos*(x: REAL): REAL IS "*Math_Cos";
(* CODE ob_res.f = cos(args[0].f); *)

PROCEDURE Tan*(x: REAL): REAL IS "*Math_Tan";
(* CODE ob_res.f = tan(args[0].f); *)

Just like Oberon, Modula and Pascal, obc is more of a language used for academic education than a 'production compiler'. But you can do a lot with it and it is faster than expected, for an interpreted language.

[Borge Glymfaeths]

Post by j***@gmail.com

Post by Nemo
It is a good compiler but only works on Intel. No cgd was ever released
for others (such as ARM, MIPS, Sparc, or PPC). Even so, the only Beg
released (1.75) requires rather old Linux libraries.

That is because the compiler stopped being further developed before these
new architectures were introduced.

That's hard to believe. Was development stopped in 1975?

Post by j***@gmail.com
I recently installed Mocka on a Slackware 14 system and it just runs fine.

Hmm this means something! :-) Pointers, please!

Post by j***@gmail.com
Let's face it. Modula-2 died in 1988. It is a very nice language with lots
of potential. But no comemrcial users and no active development
anymore. Even Wirth quit M2 in favor of his Oberon (what a silly name for a
compiler).

If you're interested in another dead-yet-still-actively-maintained language
then what about Modula-3?

Post by j***@gmail.com
Perhaps the best project would be to make not a source level port but an
object level port: make a program that translates Intel opcodes into ARM
opcodes. Sounds like a nice project for Mocka or obc.

It should probably be self-hosting and bootstrappable. That would fix a lot
of problems and give people who like M2 something juicy to bite on.

[j***@gmail.com]

Post by Borge Glymfaeths

Post by j***@gmail.com

Post by Nemo
It is a good compiler but only works on Intel. No cgd was ever released
for others (such as ARM, MIPS, Sparc, or PPC).

That is because the compiler stopped being further developed before these
new architectures were introduced.

That's hard to believe. Was development stopped in 1975?

Mocka is/was available for Sparc, Mips, etc but only at commercial rates. Something like 1200 euro's or DM per compiler. The predecessor of the ARM was introduced around 1983 in the Acorn Archimedes and it has long been a rather obscure CPU. And the ARM still is. PPC is also from the late 80's since it's a beefed up 68k.
The Karlsruhe guys made their compiler for serious computers, not for nerdy processors like ARM and PPC.

Post by Borge Glymfaeths

Post by j***@gmail.com
I recently installed Mocka on a Slackware 14 system and it just runs fine.

Hmm this means something! :-) Pointers, please!

Just download the 0608m compiler and install it. http://fruttenboel.verhoeven272.nl/mocka/setup.html

Post by Borge Glymfaeths
If you're interested in another dead-yet-still-actively-maintained language
then what about Modula-3?

Modula-3 is Modula-2 with OOP. And that's exactly why Oberon was created. Wirth still works on Oberon, mainly for the current ARM processors. But it's a one-man operation. I would call it a hobby project but downunder some people will disagree.

If going for OOPed Modula I would concentrate on obc. Spivey has (unlike Wirth cs) released full sources. There are versions of obc for Win, Lin, Raspberry, but, given the fact there is a full source tree, you can build a working (and portable) obc for any system that has a camel and a gcc compiler. Intel Galileo? BananaPi? It should all be possible in a snap. And an executable made on Win can be run on Raspy... (with some minor textmode modifications).

[Nemo]

Post by j***@gmail.com
Mocka is/was available for Sparc, Mips, etc but only at commercial rates. Something like 1200 euro's or DM per compiler. The predecessor of the ARM was introduced around 1983 in the Acorn Archimedes and it has long been a rather obscure CPU. And the ARM still is. PPC is also from the late 80's since it's a beefed up 68k.
The Karlsruhe guys made their compiler for serious computers,
not for nerdy processors like ARM and PPC.

What is your definition of "serious computers"? Almost every cellphone
runs on an ARM core and every vehicle has numerous Freescale MPC
processors. This is a much, much larger number than Intel-based PCs.

N.

[j***@gmail.com]

Post by Nemo
What is your definition of "serious computers"?

In the days when Mocka was developed and introduced, the ARM was the CPU of the Acorn Archimedes (follow up of the Acorn BBC computer http://en.wikipedia.org/wiki/Acorn_Archimedes) and it was so sophisticated that only the nerdiest of nerds got an Archimedes. Then, ARM was a niche processor. If you owned an Archi, you programmed in BBC Basic. Period.

Nowadays, ARM is the 8051 of CISC processors. It has a small RISC core (a kind of bicycle shed) to which each year a new CISC set is added (each year a palace is built on top of the bicycle shed.

ARM is so complex that the R of RISC should be stripped.

PPC was the CPU of the Mac and the Mac audience (at least in Europe) is best described as avant garde hippies. Their computer was more lifestyle than processing platform.
Besides, big parts of the Mac OS were written in Modula-2 (If I am right) so it didn't make sense to write a backend for the Mac since a MacIntosh developer surely would favor the original Mac compiler over any other.

Post by Nemo
Almost every cellphone runs on an ARM core and every vehicle has numerous
Freescale MPC processors. This is a much, much larger number than Intel-based
PCs.

Yeah but the last Mocka release was 1996....

[Christoph Schlegel]

Post by j***@gmail.com

Post by Nemo
What is your definition of "serious computers"?

In the days when Mocka was developed and introduced, the ARM was the CPU of the Acorn Archimedes (follow up of the Acorn BBC computer http://en.wikipedia.org/wiki/Acorn_Archimedes) and it was so sophisticated that only the nerdiest of nerds got an Archimedes. Then, ARM was a niche processor. If you owned an Archi, you programmed in BBC Basic. Period.

http://en.wikipedia.org/wiki/ARX_%28operating_system%29
or
http://freepages.modula2.org/m2faq.html#faq03 (F) covers Acorn.

Post by j***@gmail.com
Nowadays, ARM is the 8051 of CISC processors. It has a small RISC core (a kind of bicycle shed) to which each year a new CISC set is added (each year a palace is built on top of the bicycle shed.
ARM is so complex that the R of RISC should be stripped.
PPC was the CPU of the Mac and the Mac audience (at least in Europe) is best described as avant garde hippies. Their computer was more lifestyle than processing platform.
Besides, big parts of the Mac OS were written in Modula-2 (If I am right) so it didn't make sense to write a backend for the Mac since a MacIntosh developer surely would favor the original Mac compiler over any other.

It was Pascal.

Christoph

[Nemo]

[...]

Post by Christoph Schlegel

Post by j***@gmail.com
PPC was the CPU of the Mac and the Mac audience (at least in Europe) is best described as avant garde hippies. Their computer was more lifestyle than processing platform.
Besides, big parts of the Mac OS were written in Modula-2 (If I am right) so it didn't make sense to write a backend for the Mac since a MacIntosh developer surely would favor the original Mac compiler over any other.

It was Pascal.

Large parts of OS/400 were written in Modula-2. IBM developed a
Modula-2 compiler for internal use. I read this some years ago (in IEEE
S/W, I think).

N.

[o***@gmail.com]

Post by j***@gmail.com

Post by Nemo
What is your definition of "serious computers"?

In the days when Mocka was developed and introduced, the ARM was the CPU of the Acorn Archimedes (follow up of the Acorn BBC computer http://en.wikipedia.org/wiki/Acorn_Archimedes) and it was so sophisticated that only the nerdiest of nerds got an Archimedes. Then, ARM was a niche processor. If you owned an Archi, you programmed in BBC Basic. Period.
Nowadays, ARM is the 8051 of CISC processors. It has a small RISC core (a kind of bicycle shed) to which each year a new CISC set is added (each year a palace is built on top of the bicycle shed.
ARM is so complex that the R of RISC should be stripped.

Yes it is something of a horror, but the 64 bit versions are much improved in that respect. Personally I still prefer MIPS though.

[o***@gmail.com]

Post by j***@gmail.com

Post by Nemo
What is your definition of "serious computers"?

In the days when Mocka was developed and introduced, the ARM was the CPU of the Acorn Archimedes (follow up of the Acorn BBC computer http://en.wikipedia.org/wiki/Acorn_Archimedes) and it was so sophisticated that only the nerdiest of nerds got an Archimedes. Then, ARM was a niche processor. If you owned an Archi, you programmed in BBC Basic. Period.

How wonderfully opinionated, are you related to Linus Thorvalds in any way.

Modula-3 was developed on an Archimedes, bottstrapped from a Modula-2 compiler running on an Acorn Workstation that used a Natsemi 32000 family chip, later ported to HP-PA, and later still to other architectures.

[Chris Burrows]

Post by j***@gmail.com
Wirth still works on Oberon, mainly for the current ARM processors.

Your information is several years out of date. Wirth completed his work on the Oberon compiler for ARM processors in 2008.

His most recent work, in collaboration with Paul Reed, is Project Oberon 2013, an operating system and compiler which targets the RISC5 CPU of his own design implemented on FPGA hardware. The latest (2015) development for this platform is Lola-2, an Oberon-like HDL compiler which generates Verilog code for FPGA development:

http://www.inf.ethz.ch/personal/wirth/

Chris Burrows
CFB Software
Astrobe: Oberon for ARM Cortex-M3 and M4 microcontrollers
http://www.astrobe.com

[o***@gmail.com]

Post by j***@gmail.com
Mocka is/was available for Sparc, Mips, etc but only at commercial rates. Something like 1200 euro's or DM per compiler. The predecessor of the ARM was introduced around 1983 in the Acorn Archimedes and it has long been a rather obscure CPU. And the ARM still is. PPC is also from the late 80's since it's a beefed up 68k.

The Power PC chips are derivatives of the POWER processor, the first ever RISC processor designed, the bus system on the PPC's is shared with the 88000 processor so they could take advantage of peripheral chips that had already been released. Despite the similar name the 88000 has no relation with a 68000, it was a grounds up design of a RISC processor.

PPC, POWER and 88000 have no relation to 68000 whatsoever except that Motorola made and sold PPC and 88000 chips, they collectively are about as different from a 68000 you can get conceptually