October 2013 - Oberon - mailman3.inf.ethz.ch

Re: [Oberon] WITH removal in Oberon-07
by Paul Reed 13 Mar '14

13 Mar '14

> Date: Thu, 21 Feb 2013 22:52:05 +0100 > From: "Frans-Pieter Vonck" <fp(a)vonck.nl> > Subject: Re: [Oberon] WITH removal in Oberon-07 Hi Frans-Pieter, > i watched your presentation at MEDIA OberonDay2011. > Am I right that you made an ARM emulator first. No. The virtual machine is RISC, as in Prof. Wirth's Compiler Construction book (published in English in 1996 and updated on his home page http://www.inf.ethz.ch/personal/wirth/) > And did you use this emulator to ran Oberon System07 on top of it? It's not called System07, but it's basically the original system in the Project Oberon book, modified to compile under Oberon-07, run inside a RISC virtual machine executing on a bare-metal PC. > You showed a Spartan FPGA. I scanned through the Verilog ARM code. But > that seems a to big leap to me. I don't know what Verilog code you are referring to here. The Spartan-3 board only has 500K gates and 1MB of external static RAM, so it's much smaller and simpler than a typical ARM system. But ideal for Oberon. > Do you think it is possible to run [The Oberon System, compiled in Oberon-07] on an of the shelf > board with a Cortex M3 processor? I don't see why not, but most small ARM boards don't have a video framebuffer. The Raspberry Pi does, but it's a complicated board, as I've said before. The Oberon inner core (Kernel, FileDir, Files, Modules) and even the text system do not actually require a framebuffer display, so you could build a hybrid system. Using a simple FPGA board allows us to avoid the vast and irrelevant complexity inherent with most ARM System-on-Chip (SoC) systems; but since field-programmable gate arrays are so flexible, they will never be as cheap or as fast as a dedicated ARM. That's life. :) HTH Paul

4 5

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

Format in http://www.oberon.ethz.ch/silva_ethz/ETH/infk/oberon/oberon/bibliography/publications#Diss
by peasthope＠shaw.ca 31 Oct '13

31 Oct '13

Hello ETH Staff, Following the citation to [Mul02] there should be a line break before the citation to [Osw00b]. Regards, ... Peter E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +13606390202 Bcc: peasthope at shaw.ca http://carnot.yi.org/

1 0