[Oberon] FPGA - Simple OOP example

[Jan de Kruyf]

Jörg,

The difference is about 9 machine instructions between bit addressing and
read modify write on AVR.
depending on the context. Obviously in the middle of a routine it is less,
in an ISR it can be dramatic
since registers must be saved.

ARM on stm32 has the same bit address facility.

And readability of the Oberon way is not good. It was my motivation at the
time to change Oberon-0.

But I would much rather you helped with a bit of C++ decoding in the GCC
compiler. . . 🙄
I feel that is more important.

j.




On Thu, Aug 16, 2018 at 12:34 PM, Jörg <joerg.straube at iaeth.ch> wrote:

> 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
>
> --
> 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/a326e836/attachment.html>