[Oberon] Oberon Text and new systems for education

[Skulski, Wojciech]

Peter:

Since you posed two topics, my comment will be in two parts.

> Two use cases can be visualized.  One, a system where the programming
content of computer science can be taught.  For that, I understand
that V5, Text included, works beautifully.

An excellent point. Let me pose a few questions, and then provide my subjective answers to be shot down by the community.

1. Can we teach C.S. with Oberon System? At what scope?
2. How much of the C.S. teaching can be done with the emulator?
3. Do we need a new board for this? What should it improve upon?
4. Can we adopt existing commercial boards?
5. How good is the existing Oberon firmware framework?
6. How good is the existing Oberon software framework?
7. Should we learn, or should we preach?

1. Can we teach C.S. with Oberon System? At what scope?
=====================================

The OS was meant for teaching C.S., so definitely yes. The scope is probably "basic". The basic C.S. curriculum exists, though it may be a bit scattered. Intermediate C.S. scope is possible. For example multicore systems with several RISC5 cores on one chip. Some elements of such intermediate topics can be found in NW papers on computer architecture and probably elsewhere. The "advanced modern curriculum" is unlikely (various hypervisors, containers, or whatever buzzwords were fashionable last week). The lack of enthusiasm of NW and followers towards the "bells, whistles, and embellishments" is the main deterrent against absorbing such topics into the OS, even if it was possible. Fashionable topics may not be possible without breaking the OS architecture. I think it could be a fascinating research area, if someone wanted to dig into this within the OS rather than Linux. But I am not looking in this direction. 

2. How much of the C.S. teaching can be done in the emulator?
=======================================

The OS has three parts: HW, FW, and SW. I think that most if not all SW part can be taught within the emulator. I think that these emulators are amazing. However, the motivation for the emulator is provided by the FPGA implementation. So while the emulator is great, the HW/FW components must exist as well. Otherwise the emulator will seem hollow.

3. Do we need a new board for this? What should it improve upon?
==========================================

The FPGA Oberon cannot exist without the FPGA. Since the previous boards are obsolescent, we need a new board capable of significant enhancement of the OS. Roughly speaking, the FPGA should be 2x to 5x more capable. We need a few times more RAM. The board should be capable of running a graphically rich OS such as System 3. While I am not planning to use S3, the HW platform should be capable of doing so. It would be a mistake to limit the development goals by adopting an inadequate platform. The custom board will not be cheap. You can expect $300 to $500 per board if a significant segment of the community buys into it. "Significant segment" means five or more.

4. Can we adopt existing commercial boards?
=============================

If the custom baord is too expensive for you, then you can adopt some commercial boards, for example Digilent or others. It is unlikely that we will all agree on a particular board. Most likely we have some of these in our drawers. So anyone will want to use his inventory. The problem is that these boards are all different. If we this this approach then we are losing a common HW platform. The cheap remedy is to use the emulator and to resign from using any FPGA board. It is not an ideal solution for teaching because the FW is one of central parts of the FPGA Oberon.

5. How good is the existing Oberon firmware framework?
====================================

The original FW was very frugal due to severe limitations of the Spartan-3 200k. This FPGA was filled to 95% with the original FW. We see these limitations in the way the FW was designed. For example, there was no significant buffering in the communication interfaces. The buffering was assigned to the SW, which is not the necessarily the way such FW is usually designed. I would certainly welcome an up front discussion of these design limitations in PO.Computer. Such a thorough discussion should be a part of the teaching with this board, because such a frugal design is not necessarily typical. A new board (see above) would not impose such limitations. So the limitations should be discussed and pointed out rather than adopted as the way of writing FW.

Since the FPGA was filled to the rim, there was no prospect of adding any application firmware. The 2013 FW was a closed ended microcontroller with a few typical peripherals. Such a thing is known as System on Chip (SoC). We need to recognize that the FPGAs are not meant to implement substitutes of hardware SoCs. If you need a microcontroller CPU with some peripherals, then you will probably adopt a hard silicon chip. The soft SoC is motivated by its openness. That is, you can add your own application peripherals to the SoC in the same FPGA. This was not possible, so it was not provided for. Consequently, this FW was not designed as an extensible framework, because extensions would not fit anyway. Teaching such a closed-end design is not a good proposition. In order to be teachable, this FW should be replaced with an extensible framework. Here again we see how important it is to adopt a larger FPGA.

Another feature of the Oberon FW is the coding style, which is not very good in comparison with established textbooks such as P.P.Chu. Frugality of the design decisions should not lead to using short and meaningless names, lack of comments, or very "expert" way of coding the cascaded conditional statements. Reading the Oberon FW brings to my mind a well obfuscated C program. This is not the way the FW should be taught. I can understand that this code was probably generated with LOLA. Most likely the Verilog was meant to be relegated to the low level machine code. But this is not realistic. In practice, Verilog or VHDL are the main implementation tools to be taught to students. LOLA is not even marginal. Unless I am proven wrong, I see no point in teaching LOLA, whose time is gone for a couple decades now.

6. How good is the existing Oberon software framework?
====================================

I spent enough time on criticizing the inline numerical constants in the 2013 code. There is a general consensus that SW should be parametrized with named constants. Even NW agrees on this, despite his own practice. I circulated the remedy, that is SysDef.Mod. While my particular file has been disputed, the need to fix the present approach is obvious. The present code should not be taught to anybody. It should get fixed. 

7. Should we learn, or should we preach?
==========================

In science, and I believe that in CS too, we do not preach. We learn and we improve upon the predecessors. Just like Kepler learned and improved upon Copernicus, and Newton improved upon Kepler, we should improve upon NW. We need to adopt the strengths, recognize the weaknesses, and improve upon the shortcuts and limitations. This community is somewhat hesitant to do it. I think that we are doing a disservice rather than service by preaching rather than improving upon NW design legacy.

w.