November 2012 - Oberon - mailman3.inf.ethz.ch

Can ETHO be ported to ARM?
by eas lab 13 Jan '14

13 Jan '14

No, not the <language>, but the unique interface of S3/V4. What matters is the human-interface. That's what determines your productivety [maximum gain for minimum pain]. Not needing to switch between awkward F-keys and the screen, and having easy access to multiple text-files together, and each text-view having <what the bottle does, written on the bottle, instead of in the filing cabinet>. Porting ETHO to linux [both S3 & V4] was a killer app:. you get the Inet capability of *nix together with the superior human-interface of ETHO, plus you can view *pdf, LaTex..etc. on the same screen. For tricky problems, needing simultaneous views of: email/s, USEnet/s, your test-logs EHO is unbeaten, especially with the text colouring facilities, which help extract the meaning of difficult explanations. Because opeing/closing a new ETHO-for-linux takes a second, it's viable to have several copies running in the various dirs, which are handling current problems. Real life doesn't allow fixing one problem at a time. Can those of us who want to escape the WinTel monopoly, hope to use ARM based CPUs with an ETHO-like interface, by a porting of the existing/proven code? == Chris Glur. PS. LNO's inability to easily navigate the dir-tree, limits its utility.

3 7

Inron task server vs. VNC.
by peasthope＠shaw.ca 04 Dec '12

04 Dec '12

Years ago, once comfortable working with NO, I put TightVNC in the adjacent Debian Linux and made some use of the combination. Responsiveness was poor and the screen "real estate" in Oberon was a constraint. Consequently the VNC combination of Oberon and Linux wasn't distinctively helpful. More recently I happened to find incron in Linux and based a simple task server on it. It's effective and I use it frequently. In Web page developement for example, I edit in Oberon send the document to Debian by FTP. Immediately the rendered page appears. Documentation is here. Desktops.OpenDoc "http://142.103.107.138/NetworksPage.html#incron" Regards, ... Peter E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +13606390202 Bcc: peasthope at shaw.ca http://carnot.yi.org/ "http://members.shaw.ca/peasthope/index.html#Itinerary "

3 2

Re (2): Re (2): RISC / Can ETHO be ported to ARM?
by peasthope＠shaw.ca 13 Nov '12

13 Nov '12

Jrg & everyone, > I like your analogy with the book. Thanks. "Introducing the Book" is insightful. > Actually, the existing eReaders do not behave like a book > although they should! > Today, you have to turn an eReader on and after reading you turn it off (like a computer) My HP 41 calculator from 1981 must be turned on but turns itself off after some minutes of idleness. Usually I don't bother to switch it off. An eReader also must do that to save the battery. Regards, ... Peter E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +13606390202 Bcc: peasthope at shaw.ca http://carnot.yi.org/ "http://members.shaw.ca/peasthope/index.html#Itinerary "

2 1

Oberon on ARM/Pi
by Mike McGaw 06 Nov '12

06 Nov '12

This thread struck a nerve for me, as I have been an advocate of a virtual machine implementation for the Oberon compiler (see the end of the presentation I made at the last Oberon Day) for some time, now. I can appreciate the Ngaro VM idea; I have spent considerable time with the Lilith M2 interpreter and the KRONOS 32-bit version of this architecture, and I can appreciate the benefits of a stack-machine-based interpreter, so when I took a look at the Ngaro link, I smiled a bit. I suspect the point of this link in the previous post was not the architecture per se (although stack machines make certain aspects of code generation a bit easier), but rather its implementation in several target languages that are in broad use today. And, the point may be made that a stack architecture based VM, with suitable instruction choice can be implemented more efficiently as a VM than say, a RISC architecture (generated sizes for code that will run ON the VM will rule here, I would guess, as to overall execution speed, as the VM goes). However, Wirth has been at work, along with Reed, in the development of a clean RISC-style implementation directed at a XILINX FPGA. This, I am hoping, will be featured in a re-release of the now classic Project Oberon book in the not too distant future. What is desperately needed, though, is a VM for the compiler that is set up for at least one (easily implemented) commonly available target. Toward that end, I would argue for a VM that is implemented very cleanly and in an elemental manner. This means a VM source implementation (in Oberon) that can be directly and easily machine translated into most any target language to enable easy and direct porting of the core VM. Keeping the reference VM source implementation elemental will contribute to confident source translation and target language compilation. In this way, for example, on the Pi, one can (with a C translation of the VM) directly link the C source that manages the niggling driver libraries that take so much time to develop, and yet are key to rapid deployment of Oberon on a new architecture or implementation. The libs are linked with a machine translated VM, for which suitable hooks are made to enable the calling of these libraries. Some may argue about performance, but I would submit that performance matters are probably not as much of a concern as most might suggest, depending on what the target application may be. I do this type of thing, right now, with the Lilith M2 VM. It is relatively easy and straight forward to move this wherever I wish. Quickly. And with reliable results. This is what is needed for Oberon, in order to sustain this language and system's viability. From that basis, most of us would be able to take this remarkable language and system wherever we wish, to almost any end we desire. -Mike

10 15

Re (2): [OT] Computer system utility; was, "RISC / Can ETHO be ported to ARM?"
by peasthope＠shaw.ca 04 Nov '12

04 Nov '12

From: Jrg_Straube <joerg.straube(a)iaeth.ch> Date: Sat, 3 Nov 2012 09:28:59 +0100 > ... existing eReaders do not behave like a book although they should! Thanks for the explanation. I've never used an eReader but have an OLPC XO-1.5 which does a decent job of displaying a public document. The XO weighs about 1500 g whereas the various Kindles are 170 to 540 g. So the XO, although portable, is a burden compared to a Kindle. Redeeming aspects of the XO are the number in existence and the opernness of hardware and software. I also have a Sony Mylo. It's the size of a large cell phone and displays a public document well. Sony has discontinued support and not released enough information for third party installation of another OS. Salient observations. * OLPC and Mylo systems each is bigger than ETHNO by a factor of at least 100. * ETHNO on an old PC laptop, boots in about 22 s; the XO-1.5 in 45 s; the Mylo in a second or two. * Wireless capability of the XO is excellent; of the Mylo is useable; of ETHNO is non-existent. * None of these has F-RAM. Mylo saves the system state automatically. OLPC Gnome prompts to save an open document before shutdown or reboot. Conclusion: many good ideas and technologies are available but no system has succeeded to integrate them to make a computer which competes with a paper book in convenience, has the additional capabilities of a computer and has open specifications. Regards, ... Peter E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +13606390202 Bcc: peasthope at shaw.ca http://carnot.yi.org/ "http://members.shaw.ca/peasthope/index.html#Itinerary "

1 0

Re: [Oberon] RISC / Can ETHO be ported to ARM?
by Paul Reed 03 Nov '12

03 Nov '12

> From: Peter Matthias <PeterMatthias(a)web.de> > Subject: Re: [Oberon] Can ETHO be ported to ARM? Hi Peter, > Interesting interview. I hope the new books will be out soon. His RISC > processor will be only for education purposes with 1MB RAM... Prof. Wirth's RISC processor has a full 32-bit address space. It's just that the Xilinx/Digilent Spartan-3 Starter FPGA board we are using happens to have 1MB RAM. BTW anyone who thinks that 1MB is not a lot of memory probably doesn't belong on this list ;-) Also you might upset many embedded programmers, who still *dream* of having 1MB RAM! :) > Personally I would like to see an Oberon like system on the Raspberry Pi. > I > will check for a compiler. However, if I do it, it would be a fun project It's fun until you try to implement USB, which is necessary for the keyboard and mouse (I have GPIO and framebuffer working nicely in Oberon, didn't take too long). The Broadcom GPU+ARM system-on-chip has a USB IP block licensed from Synopsys which is a highly-configurable (aka incredibly complicated) USB 2.0 On-The-Go host-and-device-capable design, with several functions disabled or hardwired by the Raspberry Pi Foundation. Cambridge University/Alex Chadwick's "Baking Pi" tiny bare metal ARM assembler tutorial programs, are linked with his library of nearly 7000 lines of C code, if they need to access USB. And because USB interrupt transfers are not yet supported (only control transfers), only about 6 out of the 12 keyboards he's tried work so far... This is not a problem with the Raspberry Pi, per se: all USB libraries are huge and complicated. The Pi actually looks pretty simple compared with a BeagleBoard or a Freescale i.MX (simpler ARM boards don't tend to have framebuffer video), and you can't argue with the price. :) Cheers, Paul

3 2

Re (2): RISC / Can ETHO be ported to ARM?
by peasthope＠shaw.ca 02 Nov '12

02 Nov '12

From: Paul Reed <paulreed(a)paddedcell.com> Date: Fri, 2 Nov 2012 13:29:15 +0000 > BTW anyone who thinks that 1MB is not a lot of memory probably doesn't > belong on this list ;-) Also you might upset many embedded programmers, > who still *dream* of having 1MB RAM! :) Yes! ... So is there any reason not to use F-RAM? http://www.ramtron.com/products/nonvolatile-memory/parallel.aspx As discussed some months back, almost instantaneous startup and absence of the ongoing need for Store are obvious benefits. Persistent memory is the last ingredient in Wirth's vision of escape from the old hegemony of the filesystem. Read or edit a text in persistent memory with no "file" involved; aside from legacy data access of course. That's how a book works(*). You pick up a book, open it and read. No need to wait for "boot up". When finished with the current reading, just close the book with no need for Store. A computer should be the same with the additional capabilities of editing and calculating. Regards, ... Peter E. * http://www.youtube.com/watch?v=xFAWR6hzZek -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +13606390202 Bcc: peasthope at shaw.ca http://carnot.yi.org/ "http://members.shaw.ca/peasthope/index.html#Itinerary "

3 2