[Oberon] FPGA - Simple OOP example

[Jörg]

J.

 

I know it’s not perfect but:

1 and 2 can somewhat (not totally perhaps kind of) be covered with Oberon SETs.

3 I do with MODs and DIVs (the compiler converts those in simple shifts)

4 ARRAY OF SETs

5 is called “ofront”

 

Under the assumption that the underlying instruction set (assembler code) does not allow to access those single or multi-bit entities (e.g. only access BYTEs), the whole bit variables you request is “syntactical sugar”. The compiler would have to translate it in ANDs, ORs, RORs, Shifts and so. 

 

br

Jörg

 

Von: Oberon <oberon-bounces at lists.inf.ethz.ch> im Auftrag von Jan de Kruyf <jan.de.kruyf at gmail.com>
Antworten an: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
Datum: Donnerstag, 16. August 2018 um 11:53
An: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
Betreff: Re: [Oberon] FPGA - Simple OOP example

 

So let me be the devil's advocate:

 

I program embedded stuff. And for lack of integration of Oberon into main line engineering 

I am forced to use another language. I chose Ada because it is relatively easy to understand 

the syntax when you first start out.

At the same time it is bulky and slow in use. The paranoid security of it hampers the readbility and does

not really improve the bug situation.  The code is as efficient as GCC can make it. 

Which is pretty good, but at a price.

 

For Oberon to be a real alternative I would minimally need:

1. single bit variables.

2. packed arrays of those.

3. if at all possible multi bit variables (2, 3, 4, 5 etc.)

4. packed records of single and multi bit variables.

 

The single bit stuff I did many years ago in Oberon-0 for AVR and it was not difficult.

All the OOP stuff as in C++ and Ada only confuse me further so I have no use for them. 

There are other ways of sane thinking that give the same benefits. I am very

much in agreement with NW on that.

 

In any case: then there is item 5:

  An Oberon front end for GCC. so we have a proper Application Binary Interface and

can hang some libc onto it. And have an interface to other languages. AND use any 

controller for which GCC has a back end. And have industry standard load files that can 

used where ever.

 

To think that we must forever and in eternity use hand-crafted compilers that become, 

after time, most difficult to maintain is to me plain religious lunacy.

 

So I am open to suggestions from the group. The GCC stuff must be done first. 

The rest can be discussed over time.

 

Enjoy the summer holidays all.

 

j.

 

 

 

 

 

 

 

 

 

 

On Thu, Aug 16, 2018 at 10:02 AM, Diego Sardina <dsar at eml.cc> wrote:

On Thu, Aug 16, 2018, at 9:23 AM, Tomas Kral wrote:
> On Thu, 16 Aug 2018 08:38:04 +0200
> Jan de Kruyf <jan.de.kruyf at gmail.com> wrote:
> 
> > The spirit of Edsger Dijkstra is still haunting us. 😠 Rational
> > western man or not.
> 
> Modern trends usually are very complex, the spirit of Oberon is quite
> the opposite, keep it simple minimal, and leave out the fancy.
> 

Just some days ago I (casually) found in my old hard disk an interesting
paper by Hoare about language design, it's still available on the web:

http://web.eecs.umich.edu/~bchandra/courses/papers/Hoare_Hints.pdf

Briefly, Oberon fullfills all of Hoare's requirements:

"A good language design may be summarized in five catch phrases: simplicity, security, fast translation, efficient object code, and readability."

--
Diego Sardina

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

 

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20180816/27f0c7d6/attachment.html>