-----Original Message----- From: Jan Verhoeven [mailto:jan@verhoeven272.nl] Sent: Sunday, 2 March 2014 10:21 PM To: greim@schleibinger.com; ETH Oberon and related systems Subject: Re: [Oberon] FPGA Oberon some news and a reply to F.P.

greim wrote:

...

Some news from my FPGA Oberon board:

Which board did you use?

I'm not Marcus, but I'm also running RISC Oberon. I'm using a Spartan-3 board with 1000k gates. I bought mine direct from Digilent: http://digilentinc.com/Products/Detail.cfm?NavPath=2,400,799&Prod=S3BOARD along with their JTAG-USB programming cable: http://www.digilentinc.com/Products/Detail.cfm?Prod=JTAG-USB

I read that the PO board needs 200K Spartan chips. Would the cheaper board

be

sufficient as well?

The cheaper board IS the one with 200K gates isn't it? I understand that ProjectOberon also works on the board with 200k gates. I doubt that you can use the Spartan-3E board that was first on your list as it doesn't appear to have a VGA port. If you are going to buy a Spartan-3 board you might need to be quick as Digilent state on the webpage above that they aren't going to produce any more of these boards. Paul Reed has listed all the requirements in the "Instructions" file on the ProjectOberon website: http://www.projectoberon.com I've designed and ordered a single 40-pin 2" x 1" daughterboard to mount the PS/2 mouse socket, RF module and a Micro-SDHC breakout board. I have been notified that the first batch of PCBs has been manufactured and am hoping they will arrive here in the next week or so. If they work OK I'll make the design available for others to use.

Can I program the boards with Linux?

I am using Windows 7 but it appears you can use Linux. I have used both the iMPACT tool of the Xilinx "ISE suite" and Digilent's "Adept 2" software to program the board. I found Adept to be simpler and it is all that you need if all you want to do is program the board using the files in the S3RISCInstall.zip file on the Project Oberon website. You only need the full Xilinx ISE if you want to modify or recompile the VHDL sources. Adept can be downloaded from: http://www.digilentinc.com/Products/Detail.cfm?Prod=ADEPT2 Regards, Chris Chris Burrows CFB Software Astrobe v5.0: Oberon for ARM Cortex-M3 http://www.astrobe.com

Coming from hardware: transistors -> registers -> 8bitUprocs ... I was uncomfortable with NativeOberon's clunky handling of bytes via <systemChar> and shiftLeft/Right stuff. PASCAL / Modula / Oberon were never intended to directly access bytes in absolute-addressed memory [yes Hex.Tool is nice]; but it would be good to build a little domain-language for this-project's Oberon. N-O has got a substantial <scheme based design/drawing program>, for example; compared to which a minimal assembler..etc. would be trivial. Decades ago, I needed an assembler for a Motorola CPU. So instead of using *THEIR* syntax eg. ldi A, #N load byte immediate into A register = #N -> A; I used: #N->A , directly as the syntax. Why write "seven" when "7" is more direct? The value of being able to 'extend' one OS/language with others, is well demonstrated by eg: Linux [which has the big community to make drivers which ETHZ can't afford to build] supports ETHO, which can call *nix utilties, and for really difficult problems that need 6 frames open on 1 screen, and ability to colour related text/concepts, only ETHO can do, the combination is powerful. ==Chris Glur. On 3/3/14, Aubrey.McIntosh@alumni.utexas.net <Aubrey.McIntosh@alumni.utexas.net> wrote:

The bitcoin miners used Spartan 6 units, and they are being abandoned now that ASICs are available. I wonder if these would be useful?

On Sun, Mar 2, 2014 at 4:20 AM, greim <greim@schleibinger.com> wrote:

...

Some news from my FPGA Oberon board:

Yesterday i was also able to compile the Verilog code from the source to the Bit-File. That was a big progress for me.

I really hope that several hundreds will follow up! Also guys who are more professional then i am. I thinks this Project Oberon, or i prefer FPGA Oberon is a real great and also NEW system! If we you are thinking about the success of Arduinio and Rasberry PI which are much less innovative, then i am not so pessimistic about the future of Oberon. Maybe the fathers of the project should communicate this to Xilinx or maybe Altera . I could imagine that a Oberondinio or a Garnetberry OB ;-) would be a realistic thing.

As first small project and proof of concept, i personally like to realize a kind of oscilloscope. This requires: - in Verilog: the ADC converter handling and a ring buffer, with some trigger mechanism. - in Oberon: line graphic and a small user interface for showing the signals.

...

Still; compare the readabilty of the code of the rs232 driver written in verilog with one written in vhdl

verilog

http://www.inf.ethz.ch/personal/wirth/ProjectOberon/SourcesVerilog/RS232R.v

...

VHDL

http://opencores.org/websvn,filedetails?repname=rs232_interface&path=%2Frs232_interface%2Ftrunk%2Fuart.vhd

...

Greets and happy coding, F.P.

mmm, if VHDL or Verilog in principle is better readable i can't evaluate in details. Both languages are hard to understand, at least for me, and VHDL for me is still more abstract then Verilog.

One general thing is, that the Verilog code as well as the Oberon code of ProjectOberon is "poor of comments" as everybody can see at your RS 232 examples. I know that Nicklaus Wirth says: "the code must explain itself", and also the book is explaining many things very well, but at some corners, some comments would be sometimes very helpful...

Markus

-- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon

-- Aubrey McIntosh, Ph.D. 211 E. 5th St. Morris MN 56267 (512)-348-7401

Dear All,

With the risk that an FPGA board maker halts production of the one board that the project is based on.

I feel sad that Spartan 3 is becoming obsolete. So, I think, if FPGAOberon is generic and not much dependent on specialties of Spartan 3, we should immediately make/port our FPGAOberon on/to a latest board. With thanks and best regards, Yours sincerely, Srinivas Nayak Home: http://www.mathmeth.com/sn/ Blog: http://srinivas-nayak.blogspot.in/ On 03/04/2014 03:04 PM, Jan Verhoeven wrote:

That's why I am still in doubt: why shell out an extra 200 eucks on FPGA gear, no matter how useful it may be for my education and ego? With the risk that an FPGA board maker halts production of the one board that the project is based on.

Hi all,

...

I feel sad that Spartan 3 is becoming obsolete. I agree. The more recent Spartan-3E based Nexys-2 board from Digilent

A few points of background about the Digilent Spartan 3 board which may help. First, don't be sad! ;-) Everything of course becomes obsolete in our world (tech); it's actually useful that Digilent have discontinued this board in a rather timely fashion (just after I released the binaries for it, bang!) as a reminder that sooner-or-later, they would have done so anyway. As in all things (like Windows XP!) support cannot (of course) go on forever. Around the time I started the project, the board was even better value for money at $109, and has gradually been creeping up in price ever since. A clue. :( Even though I noticed that the silk-screen says copyright 2004, I chose this board for the project to replace the Ceres because it is simple, and because ETH have over 200 of them which they currently use in several courses. They all seem to be the 200Kgate version, but (depending on whether you believe the tools) the current RISC5 machine only just fits. Hence I have tended to recommend that people buy the 1000Kgate version if they wish to experiment, as the additional cost was marginal, all things considered. The simplicity of the board means that it is 'just enough' (with the addition of a small and simple do-it-yourself-daughterboard for the SD-card hard disk, mouse and wireless network module) to implement the Oberon system in a nice resource-constrained and understandable way. Porting the simplicity, rather than the system, to another board would be quite hard. (The RISC processor itself is relatively easy to port to other FPGA boards. I have had it running in various guises on Xilinx FPGA boards made or not made by Digilent, and also on an Altera FPGA board, for example.) The real killer feature about the Spartan 3 board is the 1MByte (2x256Kx16) of extremely fast (10nS) static RAM (as in, real good old-fashioned SRAM, not pseudo-SRAM for example!). I haven't found a board which provides sustained, completely random-access cycles anywhere near as fast; anything else I have seen would imply a memory interface which would dwarf the rest of the whole design in its complexity. Of course, I'd be delighted to be proved wrong about this. :) HTH Paul

Dear All, Collected few points from our last discussions, that we should look at when we think of porting FPGA Oberon to a new board. - Verilog tool chain support needed. - Need to check native clock speed of board and clock divider code. - New mapping of names and location of the pins, if needed. - Small and simple do-it-yourself-daughter boards, for SD-card hard disk, mouse, wireless modules, needed if not found in-built on board. - Minimum 1MByte (2x256Kx16) of extremely fast (10ns) old fashioned static RAM; memory interfacing trouble should be minimum. - USB programability. - Cheaper. I am a novice. If missing anything, please add. Do we have any boards having all this? With thanks and best regards, Yours sincerely, Srinivas Nayak Home: http://www.mathmeth.com/sn/ Blog: http://srinivas-nayak.blogspot.in/ On 03/04/2014 06:40 PM, Paul Reed wrote:

Hi all,

...

...

I feel sad that Spartan 3 is becoming obsolete. I agree. The more recent Spartan-3E based Nexys-2 board from Digilent

A few points of background about the Digilent Spartan 3 board which may help.

First, don't be sad! ;-) Everything of course becomes obsolete in our world (tech); it's actually useful that Digilent have discontinued this board in a rather timely fashion (just after I released the binaries for it, bang!) as a reminder that sooner-or-later, they would have done so anyway. As in all things (like Windows XP!) support cannot (of course) go on forever. Around the time I started the project, the board was even better value for money at $109, and has gradually been creeping up in price ever since. A clue. :(

Even though I noticed that the silk-screen says copyright 2004, I chose this board for the project to replace the Ceres because it is simple, and because ETH have over 200 of them which they currently use in several courses. They all seem to be the 200Kgate version, but (depending on whether you believe the tools) the current RISC5 machine only just fits. Hence I have tended to recommend that people buy the 1000Kgate version if they wish to experiment, as the additional cost was marginal, all things considered.

The simplicity of the board means that it is 'just enough' (with the addition of a small and simple do-it-yourself-daughterboard for the SD-card hard disk, mouse and wireless network module) to implement the Oberon system in a nice resource-constrained and understandable way. Porting the simplicity, rather than the system, to another board would be quite hard.

(The RISC processor itself is relatively easy to port to other FPGA boards. I have had it running in various guises on Xilinx FPGA boards made or not made by Digilent, and also on an Altera FPGA board, for example.)

The real killer feature about the Spartan 3 board is the 1MByte (2x256Kx16) of extremely fast (10nS) static RAM (as in, real good old-fashioned SRAM, not pseudo-SRAM for example!). I haven't found a board which provides sustained, completely random-access cycles anywhere near as fast; anything else I have seen would imply a memory interface which would dwarf the rest of the whole design in its complexity. Of course, I'd be delighted to be proved wrong about this. :)

HTH Paul

-- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon

Srinivas Nayak wrote:

Do we have any boards having all this?

How about this: http://www.viaembedded.com/en/products/boards/1930/1/VAB-800_(Pico-ITX).html The question is: do you want Oberon? Or do you want Ceres? -- Groetjes Jan Verhoeven

-----Original Message----- From: Srinivas Nayak [mailto:sinu.nayak2001@gmail.com] Sent: Thursday, 6 March 2014 1:48 PM To: paulreed@paddedcell.com; ETH Oberon and related systems; joerg.straube@iaeth.ch Subject: [Oberon] Porting FPGA Oberon to new boards.

Dear All,

Collected few points from our last discussions, that we should look at when we think of porting FPGA Oberon to a new board.

- Verilog tool chain support needed. - Need to check native clock speed of board and clock divider code. - New mapping of names and location of the pins, if needed. - Small and simple do-it-yourself-daughter boards, for SD-card hard disk, mouse, wireless modules, needed if not found in-built on board. - Minimum 1MByte (2x256Kx16) of extremely fast (10ns) old fashioned static RAM; memory interfacing trouble should be minimum. - USB programability. - Cheaper.

I am a novice. If missing anything, please add.

AFAIK - VGA and (optionally) a PS/2 socket for the keyboard. JTAG (as on the Spartan-3 board) instead of USB is OK - maybe an extra cost. Chris.

On Tue, Mar 4, 2014 at 4:10 AM, Paul Reed <paulreed@paddedcell.com> wrote:

The simplicity of the board means that it is 'just enough' (with the addition of a small and simple do-it-yourself-daughterboard for the SD-card hard disk, mouse and wireless network module) to implement the Oberon system in a nice resource-constrained and understandable way. Porting the simplicity, rather than the system, to another board would be quite hard.

With all of the chatter about ports, I've been randomly Googling the Spartan 3-like boards, and it seems you're right, there's just not anything quite in the same category. But, out of curiosity, is there no facility to use a standard PS/2 Y cable to add the mouse?

The real killer feature about the Spartan 3 board is the 1MByte (2x256Kx16) of extremely fast (10nS) static RAM (as in, real good old-fashioned SRAM, not pseudo-SRAM for example!). I haven't found a board which provides sustained, completely random-access cycles anywhere near as fast; anything else I have seen would imply a memory interface which would dwarf the rest of the whole design in its complexity. Of course, I'd be delighted to be proved wrong about this. :)

Is that a design problem that would eventually have to be overcome anyway? I was looking at the older Altera boards, something like the DE0 with no SRAM, does a design like that make it easier or harder, or would something like the DE1 be a) more typical and b) the standard design challenge? -Jack

On 14-04-14 00:24, Chris Burrows wrote:

I would also be interested to know as I am also investigating how I can port it to other hardware. As far as I can see, the only issue with the Digilent Nexys-2 board is that the RAM access speed is 70ns instead of 10ns. Is that a show-stopper? If not what are the consequences of using the slower RAM?

It's too slow for the current design, isn't it? The CPU runs at 25 MHz = 40ns per cycle. But if you halve the frequency to 12.5 MHz, I guess it should work.

-----Original Message----- From: Peter De Wachter [mailto:pdewacht@gmail.com] Sent: Tuesday, 15 April 2014 4:40 AM To: ETH Oberon and related systems Cc: chris@cfbsoftware.com Subject: Re: [Oberon] Digilent Spartan 3 Board

On 14-04-14 00:24, Chris Burrows wrote:

...

I would also be interested to know as I am also investigating how I can port it to other hardware. As far as I can see, the only issue with the Digilent Nexys-2 board is that the RAM access speed is 70ns instead of 10ns. Is that a show-stopper? If not what are the consequences of using the slower RAM?

It's too slow for the current design, isn't it? The CPU runs at 25 MHz = 40ns per cycle. But if you halve the frequency to 12.5 MHz, I guess it should work.

It would be great if that is the only issue. I suspected there may be considerations other than that e.g. VGA timing. Running at 12.5 MHz is not a problem for me with what I want to do with the FPGA system. The compiler is super-efficient, modules are dynamically loaded only when needed, the SDHC access is fast etc. etc. Most of the time I use RISC Project Oberon the processor is waiting for me to catch up ;-) Regards, Chris -- Chris Burrows CFB Software http://www.cfbsoftware.com

Dear all who have enquired, (Some who emailed me directly, I've BCC'd - please try to ask on the list if you can - thanks)

On Tue, Mar 4, 2014 at 4:10 AM, Paul Reed <paulreed@paddedcell.com> wrote:

...

The simplicity of the board means that it is 'just enough' (with the addition of a small and simple do-it-yourself-daughterboard for the SD-card hard disk, mouse and wireless network module) to implement the Oberon system in a nice resource-constrained and understandable way. Porting the simplicity, rather than the system, to another board would be quite hard.

With all of the chatter about ports, I've been randomly Googling the Spartan 3-like boards, and it seems you're right, there's just not anything quite in the same category.

But, out of curiosity, is there no facility to use a standard PS/2 Y cable to add the mouse?

The PS/2 connector on the Spartan 3 Board is only wired for one PS/2 interface, see the schematic.

...

The real killer feature about the Spartan 3 board is the 1MByte (2x256Kx16) of extremely fast (10nS) static RAM (as in, real good old-fashioned SRAM, not pseudo-SRAM for example!). I haven't found a board which provides sustained, completely random-access cycles anywhere near as fast; anything else I have seen would imply a memory interface which would dwarf the rest of the whole design in its complexity. Of course, I'd be delighted to be proved wrong about this. :)

Is that a design problem that would eventually have to be overcome anyway?

What, that it's not complicated enough? I don't see that as a design problem, but many commercial operations would :) Seriously though, I'm not sure I understand your question (sorry!).

I was looking at the older Altera boards, something like the DE0 with no SRAM, does a design like that make it easier or harder, or would something like the DE1 be a) more typical and b) the standard design challenge?

-Jack

-- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon

The DE0 looks quite nice since it already has an SD-Card slot, which is most of the pain about a daughterboard; but still, no SRAM (see above). However, it is unusual in that it is quite a simple board, compared with, say the Nexys 3 and others, which only purport to be simple... I know that simplicity is often used as a relative term, but if something has to be explained completely and in detail then simple takes on an absolute meaning. That's the value in Project Oberon, from understanding it completely - but Chris Burrows expressed it much better. On another subject please note that ORG.Mod.txt and ORP.Mod.txt are back on Prof. Wirth's site, sincere apologies for any inconvenience caused by the short outage. Paul

On Mon, Apr 14, 2014 at 9:14 AM, Paul Reed <paulreed@paddedcell.com> wrote:

...

Is that a design problem that would eventually have to be overcome anyway?

What, that it's not complicated enough? I don't see that as a design problem, but many commercial operations would :) Seriously though, I'm not sure I understand your question (sorry!).

No apology necessary, I believe it's entirely me. What I'm pondering is that, say, two years from now, it might be impossible to source an FPGA board off the shelf that has 1 MB of SRAM, or perhaps one that has 1 MB of SRAM and all of the other features that make the Spartan 3 so attractive. If that is the likely outcome, and it's back either to building your own board or to porting to something with less than 1 MB of SRAM, what would you suggest?

From my basic understanding, it seems like:

a) we're likely headed towards the latter, and b) the outcome is not pretty But, if we're really are stuck there anyway, does it make sense to start designing the "new" least complex memory interface given the new realities? Or, in other words, if some benefactor had magically paid you to use the DE0 or DE1 as a requirement from the outset, what would you have done? -Jack

Why not just buy a Spartan 3 board? https://digilentinc.com/Products/Detail.cfm?NavPath=2,400,799&Prod=S3BOARD Cheers, Paul

Hi everybody,

in the mean time I've got two suggestions by Digilent and Numato.

Digilent suggest Nexys 4 in a very short mail (I guess this one: https://digilentinc.com/Products/Detail.cfm?NavPath=2,400,1184&Prod=NEXYS4).

Numato suggest this one: http://numato.com/waxwing-spartan-6-mini-module together with an development board, which is currently in pre-release state:

...

...

The development board (Minimudule needs to be installed on this board) has the following features.

* Power supply necessary for all logic and peripherals * FT2232 USB Communication * 4x PMOD compatible connectors * 1 HDMI connector (buffered) * 1 VGA connector * 16x2 alphanumeric LCD * 2x 7 segment LED displays * 8 general purpose LEDs * 8 Microswitches for user input * 1 dip switch * Onboard SPI flash programming support (No need of platform cable for configuration) * JTAG connector * SD card slot * PWM Audio out jack

Does somebody with more experience in FPGA have an opinion?

I am tempted to give Numatos Waxwing a try ...

regards -- Bernhard

...

-----Original Message----- From: Paul Reed [mailto:paulreed@paddedcell.com] Sent: Tuesday, March 04, 2014 2:11 PM To: ETH Oberon and related systems Subject: [Oberon] Digilent Spartan 3 Board

Hi all,

...

...

I feel sad that Spartan 3 is becoming obsolete. I agree. The more recent Spartan-3E based Nexys-2 board from Digilent

A few points of background about the Digilent Spartan 3 board which may help.

First, don't be sad! ;-) Everything of course becomes obsolete in our world (tech); it's actually useful that Digilent have discontinued this board in a rather timely fashion (just after I released the binaries for

[...]

...

(The RISC processor itself is relatively easy to port to other FPGA boards. I have had it running in various guises on Xilinx FPGA boards made or not made by Digilent, and also on an Altera FPGA board, for example.)

The real killer feature about the Spartan 3 board is the 1MByte (2x256Kx16) of extremely fast (10nS) static RAM (as in, real good old-fashioned SRAM, not pseudo-SRAM for example!). I haven't found a board which provides sustained, completely random-access cycles anywhere near as fast; anything else I have seen would imply a memory interface which would dwarf the rest of the whole design in its complexity. Of course, I'd be delighted to be proved wrong about this. :)

HTH Paul

-- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon

-----Original Message----- From: Frans-Pieter Vonck [mailto:fp@vonck.nl] Sent: Tuesday, 4 March 2014 10:30 PM To: ETH Oberon and related systems Subject: Re: [Oberon] FPGA Oberon some news and a reply to F.P.

For instance, the oberon compiler for the lpc2000 processors is no longer supported. (I just threw my three embedded artists boards in the garbage bin.)

That is absolutely NOT true. I made an announcement regarding support only yesterday: http://www.astrobe.com/forum/viewtopic.php?f=3&t=422 Regards, Chris Chris Burrows CFB Software http://www.astrobe.com

Hi,

FST Modula for DOS had the assembler built-in. It was very convenient. One of the better Modula-2 variants.

Though with M2Amiga I came to feel an integrated Assembler, as useful as it is in certain situation, can also distract a programmer of overusing it. At the time we prepared Version 4.0 a new author jumped into the team and implemented such integrated Assembler, and used it then in the compiler itself in the attempt to speed it up. After quite some effort he put in he had to admit, that the benefit he got out of the exercise was quite disappointing. On the other hand I liked very much the means of Modula-2 to have a "high-level" way to do assembler stuff like the absolute address for variables you mentioned. Thus we introduced a similar construct to define variables and arguments as being in a register. E.g. if you wrote something like (R is a module that symbolically exports the M68000 registers) IMPORT R; PROCEDURE Swap(VAR a{R.A0},b{R.A1}:LONGINT); VAR temp{R.D0}:LONGINT; BEGIN temp:=a; a:=b; b:=temp END Swap; The generated code for Swap would be MOVE.L (A0),D0 MOVE.L (A1),(A0) MOVE.L D0,(A1) RTS which meant that knowing a little about the compiler would give you exactly the assembler code you wanted. Again you shouldn't overdue because once you alias a variable with a register it is no more available to the compiler for storing its intermediate values and the compiler would complain with a "not enough registers" error message.

But it also means that Oberon remains an island in an ocean of PC hardware, no matter how ridiculous that PC hardware may be.

This is the always present double edged sword. Do you want to adapt to the world or do you want to create your own world. In the first case you benefit from many helping hands but the outcome is not exactly what you want it to be. In the second case you rule, but you can manage just as much as you can with your own resources. Do you create your own HW fulfilling exactly your needs or do you profit from Intels weird, but every year speedier processors. Do you write your own device drivers in Oberon or do you profit from Linux and just put your TUI on top of it. Do you write your applications in Oberon or do you switch to C because this gives you access to a lot of libraries so you need to write less yourself? And the answer to this question is that there is no general answer. It depends on each one's individual goals which approach is appropriate. claudio -- Claudio Nieder, Talweg 6, CH-8610 Uster, Tel +4179 357 6743, www.claudio.ch

http://www.inf.ethz.ch/personal/wirth/FPGA-relatedWork/RISC-Arch.pdf Br, Jörg

Am 05.03.2014 um 01:29 schrieb Jan Verhoeven <jan@verhoeven272.nl>:

Is there a list with the instruction set for the imaginary RISC processor?

I tried to go through the ORG module but it is not particularly polluted by comments and the structure (ie naming of objects) and the indentation were not what I was used to from the Grand Master.

-- Met vriendelijke groeten,

Jan Verhoeven http://www.verhoeven272.nl

-- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon

-----Original Message----- From: Jan Verhoeven [mailto:jan@verhoeven272.nl] Sent: Wednesday, 5 March 2014 8:37 PM To: ETH Oberon and related systems Subject: Re: [Oberon] FPGA Oberon some news and a reply to F.P.

And look at FML a, b, c: It seems to resemble R.a := R.a x R.c, but where's the b factor? Same goes for MUL a, b, n.

Good point! Looking at the source code indicates to me that they are typos. I believe they should be: FML a, b, c R.a := R.b х R.c MUL a, b, n R.a := R.b х n Regards, Chris -- Chris Burrows CFB Software Astrobe: Oberon for ARM LPC2000 & Cortex-M3 http://www.astrobe.com

Hi,

most traditional old fashioned, nostalgic kind of mnemonics. Easlab yesterday showed his own efforst from decades ago, with

#N -> Ra

What is the point of inventing something new just for the explanation of the CPU instruction set? It's not that you use it when programming. When programming you use Oberon all the time. claudio -- Claudio Nieder, Talweg 6, CH-8610 Uster, Tel +4179 357 6743, www.claudio.ch

Jan You are right the 6502 was a RISC processor. The chips evolved to CISC (most probably an error) and tend to return to RISC now (okay, nowadays highly parallelized but more RISC than CISC). Wirth's processor illustrates the features a CPU needs: - starting with a basic "Von Neumann architecture" (allowing for JIT compilers not possible with a "pure Harvard architecture") - adding indirect addressing - adding memory mapped IO But you are right the "Von Neumann bottleneck" is not covered. E.g. modern processors have instruction cache and branch predictors to alleviate this bottleneck a little bit. But who knows: Wirth started with RISCO0, is now at RISC5. Perhaps an upcoming RISC6 will introduce instruction cache making it a modern "modified Harvard architecture". br Jörg -----Original Message----- From: Jan Verhoeven [mailto:jan@verhoeven272.nl] Sent: Mittwoch, 5. März 2014 15:30 To: ETH Oberon and related systems Subject: Re: [Oberon] FPGA Oberon some news and a reply to F.P. Claudio Nieder wrote:

What is the point of inventing something new just for the explanation of the CPU instruction set? It's not that you use it when programming. When programming you use Oberon all the time. claudio

Yes you are right. We should have stuck to Cobol and Fortran. All the successors were just useless inventions just for the explanation of language keywords. -- Groetjes Jan Verhoeven -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon

-----Original Message----- From: eas lab [mailto:lab.eas@gmail.com] Sent: Tuesday, 4 March 2014 4:41 PM To: ETH Oberon and related systems Subject: Re: [Oberon] FPGA Oberon some news and a reply to F.P.

PASCAL / Modula / Oberon were never intended to directly access bytes in absolute-addressed memory

Oberon is (and always was) designed to enable you to directly access bytes in absolute-addressed memory using its SYSTEM features: SYSTEM.GET(a, v) is equivalent to v := Mem[a] and SYSTEM.PUT(a, x) is equivalent to Mem[a] := x where v and x are any basic type and a is an absolute address which can be obtained e.g. a := SYSTEM.ADR(v) where v is any type. Regards, Chris Chris Burrows CFB Software Astrobe: Oberon for ARM7 and Cortex-M3 Microcontrollers http://www.astrobe.com

]> PASCAL / Modula / Oberon were never intended to directly access bytes ]> in absolute-addressed memory

Modula-2 was. It can address hardware addresses, eg video RAM using VAR screen [0B000H:0] : ARRAY .. , .. OF RECORD ch, at : CHAR END; To mention just one. It also has low level functions that come close to assembler. From the trio Pascal / Modula / Oberon, Modula-2 is the one best suited for operating system design. It has all the potential and the functions. It also has the dreaded LOOP/END construct that is the heart of all operating system inner loops. compared to which a minimal assembler..etc. would be trivial. FST Modula for DOS had the assembler built-in. It was very convenient. One of the better Modula-2 variants.

Perhaps Modula-2 was the peak of 'or family', and the contiual name change lost followers? ]> I used: #N->A , directly as the syntax.

Why not " A := N " ? That would have been readable and understandable by all.

No! When you looked in the data-sheets, to see "what means: mov rA,N", They used the '#N->regA' notation. poplog uses "a + b -> c" instead of "a := b + c", which IMO is better: <ID> := <expression> is goal-directed/ declarative / top-down; whereas our Algol-family is imperative: NOT "let a = b + c". OTOH: <expression> ":=" <ID> loses the one-token-look-ahead parsing ability to identify an assignment statement [as I discovered when I made a FSM compiler based on the railway-diagrams]. ============

On the other hand I liked very much the means of Modula-2 to have a "high-level" way to do assembler stuff like the absolute address for variables you mentioned. Thus we introduced a similar construct to define variables and arguments as being in a register. E.g. if you wrote something like (R is a module that symbolically exports the M68000 registers) IMPORT R; PROCEDURE Swap(VAR a{R.A0},b{R.A1}:LONGINT); VAR temp{R.D0}:LONGINT; BEGIN temp:=a; a:=b; b:=temp END Swap; The generated code for Swap would be MOVE.L (A0),D0 MOVE.L (A1),(A0) MOVE.L D0,(A1) RTS

Vaguely I remember 'bracket' (A1) meaning 'indirect'? Following each manufaturer's copyrighted syntax, is as absurd as writing music in mock-english. ] Good point! Looking at the source code indicates to me that they are ] typos. ] I believe they should be: ] FML a, b, c R.a := R.b h R.c ] MUL a, b, n R.a := R.b h n You get typos when you think in terms of 'writing near-english notes to the little man in the box', instead of <symbolic>; like schematic diagrams or music noation.

And, worst of all, WHY would you want to fall back to mnemonics? Why do you need to use MOV 1, 2 (which looks stupid) when you can also use Load R1, 2 (which looks logical) or, even better: R1 := 2 (which leaves no doubt at all)

We 'know' it does NOT 'move' per english meaning. But the competition copyrighted "load" or "copy".

#N -> Ra

] This is more difficult to read (and parse) than a mnemonic followed by ] a fixed number of operands. You mean for the computer/parser-writer. ] Keep it simple... No, not simple for the parser-writer. Simple for the zillion readers. I haven't seen CPU data-sheets for a few decades, but even with the greatly increase compexity, I doubt that they've replaced the symbolic explanation with "poetry'.

Try to eliminate any sort of pre-conceived ideas that you may have from using other systems. It might be a subtle distinction but the specification is not describing any sort of assembly language - it is describing the behaviour and format of the 32-bit binary codes that are emitted by the code generator. The compiler does not generate assembler. Project Oberon does not use any assembly language - all the code is Oberon.

Well, unless it's new magic: * the subset of the 2^32 words are decoded by the hardware to give a vocabulary of useful instructions, which manipulate the hardware [eg. registers]. * when humans need to think about or exchange information on any specific 'instruction' [in the vocabulary] they need a label for it. * which leads to 'the assembly language'. When humans DISCOVERED the elements, they needed to be named. And the genes, also 'operated in the background' without being assigned an assembly language; until you want to analyse/discuss them. == Chris Glur.

Jan, Wow! That's neat! But X and Y must have TYPE compatible with XOR. -Doug Danforth On 3/15/2014 4:48 PM, Jan Verhoeven wrote:

Nothing beats

X := X XOR Y Y := X XOR Y X := X XOR Y