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

[Joerg]

Jan

No, no I don‘t disagree with you.
If the aim is to „just“ have an Oberon compiler on a lot of backends, then Ofront is a good way to go.
If I think of it, what I personally really like is actually not the Oberon language but the Oberon OS.
No heaviy IDE with thounds of parameters, no lengthy compile and link phases, fast development due to dynamic loading, System.Free and just execute the new command, the OS API is not as heavy as Linux. Android or Windows (admittedly not as powerful as well, but enough for embedded systems)

But indeed the crux of the Oberon OS is the not existing driver eco system for HW!

br
Jörg

> Am 30.04.2020 um 00:37 schrieb Jan de Kruyf <jan.de.kruyf at gmail.com>:
> 
> 
> 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
> --
> 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/37413f6b/attachment.html>