[Oberon] Large Displays / 64 bit...

[Charles Perkins]

On Jun 19, 2014, at 3:35 AM, greim <greim at schleibinger.com> wrote:

> Hi,
> 
> each enhancement of the emulator should keep the existing FPGA RISC 
> processor in mind!
> Otherwise we are opening the next fork of the fork of the fork...
> 

I agree. 

> I am just trying to port the Spartan 3 design with static RAM to a 
> Spartan 6 with dynamic SDRAM. Thats because Spartan 3 is at the end of 
> lifetime and all newer reference designs of Xilinx (and all the open or 
> cheap boards are following this reference designs) are using SDRam (or 
> better said, one special chip, the MT48 from Micron).
> 

Which Spartan 6 board are you using?

> Regarding the SDRAM refreshing etc. i fear it will be hard to realize a 
> much bigger resolution then the actual one.
> 
> 64 bit could be possible with Spartan-6 but not with Spartan-3.
> But is this really necessary?
> 

I don't think 64 bits is useful in an FPGA if one doesn't have the large 
memory to go with it. 

One of the advantages of an emulator however is that it provides a 
convenient sandbox for systems experiments. What are the minimum
changes required to Oberon in order to support 64-bits? I argue that
it is easier to discover that in an emulator where you can ignore 
extraneous details. One can add those details back in when porting the
emulated 64-bit system to a 'real' 64-bit system, e.g. x86_64 or 64-bit ARM.

An important goal of building a 64-bit system would be to keep it at least
source code compatible with the 32-bit system.

A related question: What are the minimum changes required to support
multiple processors? 

The multiple processor question is one that might be attractive to explore
in an FPGA. I think that a compare-and-swap opcode, an IO address 
that one can write to to interrupt peer processors, and another IO
address registering which processor(s) will accept hardware interruptions, 
and a third IO address that reflects which processor is reading it (for CPU 
identity -- we don't want to use up opcodes unnecessarily) would be sufficient.

System changes to support multiple processors will require much more
thought. Can you embrace multiprocessing without abandoning the simple
architecture of the current V5 Oberon?  Aos and Bluebottle show one
way to go. But how about incorporating CSP (Communicating Sequential
Processes) instead? It might be fun to find out.

> I am not sure how the actual situation is, but for me, on the software 
> side, a smooth out of the box boot image generator, based on the 
> emulator, would be more important. Also a tool writing the Oberon File 
> system directly to a SD-Card and a real PC-Link using the RS232 
> RISC<->PC would be nice to have, as a stable, easy to use infrastructure.
> 

I also want a boot image generator and a file system creator, and also 
interfaces to other file systems. I would also like to re-introduce other 
architecture targets, including Intel and ARM for native-speed operation.

I would like to see compatibility maintained between these architectures. 

Other operating systems are built to multiple targets from one source tree,
I believe Oberon can do it too. 

> Also the license situation is not finally clarified!
> (Maybe because the ETHZ is realizing similar things in cooperation with M$)
> 

Can you tell us more about what is not clarified about the license?

> Regards
> 
> Markus Greim
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon

Regards,
Chuck