 |
| Is this how modern computers appear to users - even experts? |
It is becoming ever increasingly clear to me - and others, that computing platforms have become just too complex. In an attempt to be all things to all users they are built on a massive agglomerate of software, some which has it's roots in the 1960s, and most people have forgotten why it was there in the first place. Literally they have become a tower of Babel
Reading the Wikipedia entry - the Tower of Babel was a huge edifice - so big that no-one really knew how big it was. Ironically it was created, so that everyone living in Babel could speak the same language. According to the myth, the big chap upstairs didn't like this, and confounded the people's speech, so they could no longer understand each other. He then destroyed the tower and sent it's residents scattering to the four corners of the world, and this led to the diversification of language.
Loosely applying this myth - as an analogy of the current state of the computing industry - we are now trying to recreate a Tower of Babel, as a concretion or conglomeration of thousands of different software modules 20+ million lines of code, 1200 developers/contributors, loosely tied together in a Linux wrapper - in the hope that they somehow will fuse to form a unified entity.
Well just as Babel ultimately failed, I believe that our current strategy of building vast megalithic operating systems - then spending all our time worshiping them, is a road to ruin.
Like I might say to a historical resident of Easter Island "Keep on carving the stone heads, Dude, - just wait and see exactly where that gets you!".
Here's a breakdown of a recent image of the Debian distribution:
=============================================
Item Lines %
=============================================
./usr 845 0.0042
./init 5,739 0.0283
./samples 8,758 0.0432
./ipc 8,926 0.0440
./virt 10,701 0.0527
./block 37,845 0.1865
./security 74,844 0.3688
./crypto 90,327 0.4451
./scripts 91,474 0.4507
./lib 109,466 0.5394
./mm 110,035 0.5422
./firmware 129,084 0.6361
./tools 232,123 1.1438
./kernel 246,369 1.2140
./Documentation 569,944 2.8085
./include 715,349 3.5250
./sound 886,892 4.3703
./net 899,167 4.4307
./fs 1,179,220 5.8107
./arch 3,398,176 16.7449
./drivers 11,488,536 56.6110
=============================================Don't get me wrong, Linux plays a very important part of the modern digital infrastructure - but this colossal edifice may eventually collapse under it's own weight.
What about small embedded systems - traditionally coded in C and running from Flash? These high end microcontrollers are generally limited to 1Mbyte of Flash and 0.5Mbyte RAM and clock frequencies of <300mhz .="" p="">
So, if you, like me, are fed up dealing with 15 gigabytes of someone else's software in multiple non-compatible languages then this recent article from "The Register" may be of interest.
Project Oberon
This was an ambitious project started in 1985 to create a simple workstation with it's own lightweight language and operating system called Oberon - a successor to Pascal / Modula 2. The chief designer was Niklaus Wirth - who also was the creator of Pascal, Modula 2 and other languages. Here's Wirth's presentation of the historical perspectives of the project.
Oberon is not only a language, but an Operating System that includes a compiler. Remarkably the whole Oberon System, when loaded fits into 110kbytes - making it an ideal fit for smaller cpus with limited amounts of RAM.
Below are the line counts for the various Oberon System modules:
LOC. %
MenuViewers 208 4.89
Viewers 216 (outer core) 5.08
Modules (loader) 226 5.32
Edit 233 5.48
Kernel 271 (inner core) 6.38
FileDir 352 8.28
Oberon 411 9.67
System 420 9.88
Files 505 11.88
Texts 532 12.52
TextFrames 874 20.57
Total 4248
Adding these up we see that the whole Oberon System consists of 4248 lines of code! That's consideraby less than the Linux ./init code. and approximately 1/5000th of the Linux distribution. You will also notice that each module is roughly 5% to 20% of the total.
One reason why this is possible is that the Oberon System has been tailored for one particular - and very simple hardware platform and it is so it is not having to cater for every different processor or peripheral device on the planet.
The Oberon Platform
Originally (1988) the Oberon Platform (Ceres) was based on the NS32532 processor. This was a 25MHz 32bit processor - one of the first 32 bit devices commercially available. It had a performance roughly equivalent to twice that of an i386 for the same clock frequency.
Fast forwarding to 2013, Project Oberon has been recreated in the form of a low cost "OberonStation" using an inexpensive Xilinx Spartan 6 FPGA - accomplished by Paul Reed and Victor Yurkovsky - a regular FPGA Blogger.
In this Xilinx Journal "Xperiment", Niklaus Wirth writes about the FPGA implementation. He also describes a new hardware description language called "Lola 2" which allows FPGA hardware to be designed on a Oberon Workstation and then cross-compiled into Verilog - from where it can be imported into the usual FPGA development toolchain.
 |
| The Oberon Station - Spartan 6 FPGA plus 256Kx32bit SRAMS |
If you wish to look further at Project Oberon - a pdf of the 2013 Book is available - with html index here.
Thoughts- and Questions on OberonStation
Less is more - this hones down a workstation to the level of complexity where any one can understand the hardware. It is reminiscent of Chuck Moore/Jeff Fox's Ultratechnology Workstation in a mouse
The Oberon Station boots from the uSD in about a second - which is impressive. My laptop thinks for about 5 seconds before it even responds to it's power switch.
The monochrome video could be greatly extended - a Spartan 6 should be capable of generating 1024 x 768 resolution VGA in full 24bit colour, or even HDMI. Especially if it uses 32 bit wide SRAM.
The PS/2 keyboard and mouse are good old simple technology - but, in time may be difficult to get hold of.
Adding a FT2232 to act as virtual com port and the means to re-flash the FPGA would also be useful for development purposes.
The Network Port is intended to take a nRF24L01 2.4GHz transceiver. A couple of jumper links and it could take an ESP8266-01 WiFi module.
Want to democratise this? Re-lay it out using a Arduino MEGA footprint or add a Raspberry Pi style expansion header - so that it can use popular & standard forms of shields.
There appears to be a footprint for an SMT or FPC expansion header on the left side of the PCB.
With the right RAM this could be clocked at 100MHz++
What about an ARM Implementation?
The RISC5 appears to be a fairly simple cpu architecture, the Oberon System has been cross-compiled by Astrobe to ARM - so it can run on any ARM equipped device. Currently NXP Cortex M3 and M4 devices are supported with more to come.
This opens up the opportunity for a port to the Cortex M7 - which opens up opportunities for 200MHz + operation, with 400MHz promised for later in 2016. A port to the $50 STM32F7 Discovery platform would make for a portable, battery powered workstation.
Additionally the RISC5 has been ported to run on the $99 Xilinx Artix 7 "Arty" platform.
Astrobe Systems have recently released a cross compiler and development system to allow Oberon to be developed on a Windows platform.
No comments:
Post a Comment