[Oberon] Commercial system

[Chris Burrows]

 -----Original Message-----
> From: eas lab [mailto:lab.eas at gmail.com]
> Sent: Sunday, 9 February 2014 4:12 AM
> To: ETH Oberon and related systems
> Subject: Re: [Oberon] Commercial system
> 
> Is the X86 instruction set 'superior'?
> Or is it like 'english': just got established first by the luck of
history?
> 

The latter IMHO. The endian / segmentation issues of the X86 always jarred
with my sense of logic. They were a result of retaining backward
compatibility during the evolution from 8-bit systems. My first 16-bit home
computer (a 1983 Sage II/IV running UCSD Pascal and later, Modula-2) was
introduced at about the same time as the IBM-PC. The Sage had a powerful
24-bit 8Mhz MC68000 processor when the PC only had a puny 1.4MHz 16-bit
8086. I have always preferred the linear addressing scheme of the 68000
instruction set and regret that Motorola didn't succeed over Intel in the
switch from 16 to 32 bits. 

> IMO WinTel is technically a mess, because of the commercial need to evolve
on
> their sub-optimal historical path. But therefore a great commercial
success;
> until a competitor, who is free from the baggage of history, beats them.
> 

ARM started off very well but their designs have gradually convoluted into a
technical mess as the instruction set has 'evolved' - the scourge of
backward-compatibility strikes again! Have a close look at the encoding
formats they use in the ARM Cortex-M3 instruction set - particularly the
bizarre schemes they use in an attempt to shoehorn 32-bit constants into a
32-bit instruction.

Wirth's RISC instruction set is a real breath of fresh air, like his
compiler designs. Dogmatic backward-compatibility considerations have never
been allowed to stifle progress in his software / hardware designs.

> Will ARM-android over run WinTel?
> 

It is not about instruction sets it is about power consumption. There are
two different conflicting attributes: low power consumption vs. high clock
rates. ARM has the low power, Intel has the high speeds. ARM is primarily
dominant in portable / battery-powered devices.

> 
> Has ETHZ's FPGA device got any debugging LEDs [like rPi], or will the
victim
> need an oscilloscope...etc, to confirm?
> 

The FPGA device that Wirth's Oberon system is implemented on is an off-the
shelf Spartan-3 development board. It has 8 LEDs that are used by Oberon to
indicate progress through the boot sequence. 

Regards,

Chris Burrows
CFB Software
http://www.astrobe.com
Astrobe v5.0: Oberon for ARM Cortex-M3