[Oberon] Interfacing with Foreign Systems

[Chris Burrows]

Before even thinking about embarking on a major project like that I would recommend spending a few months experimenting with GNU Modula-2 (a frontend to GCC) to get an idea of the effort involved in such an exercise and to gain some hands-on experience of how useful the end-product might be. 

 

http://nongnu.org/gm2/download.html

 

This work has been actively maintained by Gaius Mulley at the University of Glamorgan for many years now. The Modula-2 mailing list archives are evidence of this:

 

https://lists.nongnu.org/archive/html/gm2/

 

He has published some related papers on his website. e.g. “A report on the progress of GNU Modula-2 and its potential integration into GCC”

 

http://floppsie.comp.glam.ac.uk/

 

Regards,

Chris Burrows

CFB Software

https://www.astrobe.com

 

 

From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of Jan de Kruyf
Sent: Thursday, 30 April 2020 8:07 AM
To: ETH Oberon and related systems
Subject: Re: [Oberon] Interfacing with Foreign Systems (was: Negative integer literals in Oberon)

 

guy,

when I was young, and still thinking girls were stupid, I also did a hacked Oberon compiler for some micro controller.

It was a wonderful learning experience, but although the end result worked, I now would be 

ashamed to show it. It was ultimately a one off for a one off job.

Since then I have learned that girls are actually quite nice and worthwhile to spend some time on,

while computer fashions change like the weather.

 

Now for the bigger picture after this digression:

As you also did find out, I guess: 

Oberon is a niche language sitting somewhere in an obscure corner. I maintain that one of the causes is 

that there is no compiler like gcc that has an oberon front end but that could have many different back ends.

(Joerg does not agree with me I know 🙄)

If we would stick our heads together and see if an Oberon frontend to gcc is manageable then 

Oberon becomes a useful tool for many embedded controllers since there are already many back-ends.

And the building of a toolchain for cross-compilation is a well documented task, I have done it in Ada.

A binding with the hardware / libraries of a new controller can then be whipped up in a matter of days.

 

What you are proposing has been done in the past. People have constructed Oberon to C translators 

(but without modifying the language), but for one reason or another none of those made it into a 

productive tool that is used much. Lack of a well documented way to use foreign libraries and lack of 

an easy debugging mechanism come to mind.

 

hope this stimulates your grey matter a bit.

 

j.

 

 

On Wed, Apr 29, 2020 at 2:45 PM Guy T. <turgu666 at gmail.com <mailto:turgu666 at gmail.com> > wrote:

The approach I’ve taken so far is very similar to the "Oberon-2 Programming with Windows”. Here is the modifications to the language I’ve done (from the syntax definition of Oberon-07):

 

Module           = OberonModule | CModule.

OberonModule     = MODULE ident ";" [ImportList] DeclarationSequence

                   [BEGIN StatementSequence] END ident "." .           (* No change here *)

CModule          = MODULE "[" CDECL "]" ident ";" [ImportList]

                   CDeclarationSequence END ident "." .

CDeclarationSequence = DeclarationSequence =

                           [CONST {ConstDeclaration ";"}]

                           [TYPE {TypeDeclaration ";"}]

                           [VAR {VariableDeclaration ";"}]

                           {CProcedureDeclaration ";"}.

 

ArrayType        = ARRAY     ["[" CDECL "]"] length {"," length} OF type.

PointerType      = POINTER   ["[" CDECL "]"] TO type.

ProcedureType    = PROCEDURE ["[" CDECL "]"] [FormalParameters].

 

ProcedureDeclaration = OberonProcedureDeclaration | CProcedureDeclaration.

OberonProcedureDeclaration = ProcedureHeading ";" ProcedureBody ident. (* No change here *)

CProcedureDeclaration = CProcedureHeading ";" .

CProcedureHeading = PROCEDURE ["[" CDECL "]"] identdef [FormalParameters].

 

RecordType       = OberonRecordType | CRecordType.

OberonRecordType = RECORD ["(" BaseType ")"] [FieldListSequence] END.  (* No change here *)

CRecordType      = RECORD    ["[" CDECL "]"]   [FieldListSequence] END.

 

——

 

The only change to the syntax is the use of a "[CDECL]” for elements that need to be internally managed as C elements. Internally, new forms are created for module, pointer, array procedure and record declared with "[CDECL]”. All basic Oberon types (CHAR, BYTE, BOOLEAN, SHORTINT (16 bits), INTEGER (32 bits), LONGINT (64 bits)) are the same as their equivalent in C. SET is mapped to C 32bits integer for bit-wise manipulations (0: LSB, 31: MSB). The ESP32 is using little-endian for memory addressing.

 

A CModule is the equivalent of a header file in C. No code is produced so no statements are allowed in a CModule. All elements in a CModule are C related, so the use of [CDECL] for array, record, pointer and procedure is induced. A CModule can import other CModules.

 

A CRecordType is the equivalent of a C struc. No RECORD extension is allowed.

 

C Pointers can be declared to point to any simple types and C array, C record, C pointer and C procedure. They cannot be initialized through NEW() but can be initialized through assignation.

 

C Array can be declared to point to any simple types and C array, C record, C pointer and C procedure.

 

C Procedures don’t generate name mangling as for GCC and accept only parameters that are compatible (so no Oberon array, record, pointers and procedures but their [CDECL] equivalent).

 

Guy

 

--
Oberon at lists.inf.ethz.ch <mailto: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/20200430/901cdf96/attachment.html>