[Oberon] Interfacing with Foreign Systems (was: Negative integer literals in Oberon)
chris at cfbsoftware.com
Wed Apr 29 03:23:31 CEST 2020
Those issues have been addressed many times in other Oberon-based systems so you should take the time to study the various ways in which they have previously been implemented. Some excellent references are:
1. Oberon-2 Programming with Windows, Mühlbacher, J.R., Leisch, B., Kirk, B., Kreuzeder, U., Springer 1997. ISBN 978-3-642-45762-3
In particular Chapter 7. 'Programming with the Windows API'.
2. "Compiling for the .NET Common Language Runtime (CLR)", John Gough, Prentice Hall 2002. ISBN-10: 0130622966
3. Blackbox Component Pascal > Help > Contents > Miscellaneous > Platform-Specific Issues
Those should be enough to get you started.
> -----Original Message-----
> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of Guy
> Sent: Wednesday, 29 April 2020 9:00 AM
> To: oberon at lists.inf.ethz.ch
> Subject: Re: [Oberon] Negative integer literals in Oberon
> I m following this thread with great interest.
> As I m building a compiler for the ESP32 IOT chip, I m facing issues as I
> m transforming the compiler to allow relatively easy integration with C
> functions present in the ESP-IDF framework (This is *the* framework
> needed to access some hidden part of the chip). For that, I ve defined
> new forms for arrays, records, procedures and pointers to be compatible
> with the C language syntax and semantic. I also need to add 16bits
> unsigned and 64bits signed integers. I may have to add unsigned integer
> depending on the needs. I already added bit-wise AND, OR and XOR standard
> functions that I may get rid of depending on the suitability of SETs to
> get good code readability. I miss a lot enumeration as the C enum is in
> used everywhere in the ESP-IDF framework (but I m not for now
> implementing it in Oberon). I m also considering variable number of
> parameter for C procedure calls
> I try to find ways to get the interaction with the ESP-IDF framework as
> easy as possible for the Oberon programmer (in occurence, me ) without
> loosing the sense of the language.
> What I wanted to show is the context of added functionalities required to
> get Oberon inter-operate with an existing framework. The most important
> aspect for me is the readability for the developer (and long term support
> readability) without loosing too much of the simplicity of the language.
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
More information about the Oberon