[Oberon] Interfacing with Foreign Systems (was: Negative integer literals in Oberon)

[Jan de Kruyf]

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