[Oberon] Can ETHO be ported to ARM?

[eas lab]

Well you blokes have really forked *MY* thread.
Despite the fact that I put the main point/query UP-FRONT.

It's about leveraging the PROVEN superb HCI of S3/V4 onto the improved
ARM hardware, which allows further freedom from the WinTel monopoly.

I'm much influenced by how the porting of S3 [& V4] to linux gave
massive advantages. Right now, eg: ->  pgrep oberon ==
3564
3865
5807
5833
6210
7582

Which shows that I've got 6 instances of linux.oberon.no running...
Why ?!. Well, eg. in one I'm trying to collaborate with a USEnet user
on the installation of the <festival text-to-speech> app.
And it requires me to read and paste between, email, USEnet & several
text files.  And I need to see all the texts together on the same screen.
Where is your WinTel application that can do that ?!
And the learning/remembering-effort & keystrokes required are a fraction
of eg. `vim` or `emacs`.

So let's move forward from the presently most superior and proven S3/V4.

I'd like to use/support: "Astrobe: Oberon for ARM Microcontrollers"
but I don't do Windows. And having oberon run on ARM is not enough.
It's the S3 or V4 HCI that's required.
-------------

Re. VM, in enquiring about <lack of const data arrays> on
<Newsgroups: comp.lang.oberon> recently, I described how in the 70's
I made an Augmented-finite-state-machine [P0-PASCAL] compiler, for
the Fairchild-F8 8 bit microprocessor, which I had wire-wrapped.

The AFSM compiler was based on 2 articles in BYTE, about a BASIC driven
compiler. But I *INVENTED* the idea of just-follow-the-train-lines
and-do-the-actions-at-the-appropriate-stations plus some extra stations.

It was originally for the HP-desktop-calculator, to be able to write
nice Pascalised code for driving instruments, instead of the original
difficult syntax HP-GPIB code.

Once the AFSM compiler existed, it was easy to port it to the F8, Motorolla,
Intel8 & 16 Bit, microprocessors, by just writing the appropriate
P-code interpreters..

So yes, a VM chip dedicated to the P-code interpreter is OK.
Perhaps good for a teaching item; but economically pointless these days.

The same way as S3/V4 got massive leverage by riding on top of the
linux-eco-system, so also ETHO should ride on top of the ARM-eco-system
instead of reinventing the stack-based architecture which was discussed
in the 60's Burrough's article?     Or?

== Chris Glur

PS. in this 3rd [going 4th] world country, buth my ISPs a dud and
forcing me to paste to this cursed gMailer. So I hope it works?