Oberon 07 compiler for Windows

[frrrstfn]

I'm trying to writet an Oberon 07 compiler for Microsoft Windows OS.

Cause Wirth removed SHORTINT and LONGINT integers a problem arise when
interfacing to Microsoft Windows API where some functions have short
integer parameters (8 and 16 bits).

A possible solution is to add new types to pseudo SYSTEM module,
something like SYSTEM.INT8 and SYSTEM.INT16, and add a procedure
SYSTEM.SHORT to convert Oberon 07 INTEGER when calling Windows API
functions requiring short integer parameters.

What do you think about it?

[Objective Modula-2]

Post by frrrstfn
I'm trying to writet an Oberon 07 compiler for Microsoft Windows OS.
Cause Wirth removed SHORTINT and LONGINT integers a problem arise when
interfacing to Microsoft Windows API where some functions have short
integer parameters (8 and 16 bits).
A possible solution is to add new types to pseudo SYSTEM module,
something like SYSTEM.INT8 and SYSTEM.INT16, and add a  procedure
SYSTEM.SHORT to convert Oberon 07 INTEGER when calling Windows API
functions requiring short integer parameters.
What do you think about it?

That is basically the approach taken in GNU Modula-2: Module SYSTEM
provides integer and cardinal types with guaranteed bitwidths from 16
to 128 bits:

http://www.nongnu.org/gm2/gm2.html#SEC29

For maximum portability of your code you might want to make SHORTINT
and LONGINT (and even LONGLONGINT) target dependent aliases that
resolve to whatever integer type best suits the target platform. An
example of this approach can be seen in Modula-2 R10:

http://bitbucket.org/trijezdci/m2r10stdlib/src/tip/Integers.def
http://bitbucket.org/trijezdci/m2r10stdlib/src/tip/INT16.def

[Chris Burrows]

Post by frrrstfn
I'm trying to writet an Oberon 07 compiler for Microsoft Windows OS.
Cause Wirth removed SHORTINT and LONGINT integers a problem arise when
interfacing to Microsoft Windows API where some functions have short
integer parameters (8 and 16 bits).
A possible solution is to add new types to pseudo SYSTEM module,
something like SYSTEM.INT8 and SYSTEM.INT16, and add a procedure
SYSTEM.SHORT to convert Oberon 07 INTEGER when calling Windows API
functions requiring short integer parameters.
What do you think about it?

Wirth typically uses CHAR where unsigned 8-bit quantities are needed.
Additionally, his ARM Oberon-07 compiler which we use in our Astrobe
(formerly known as Armaide) system has a SYSTEM.BYTE which is an eight-bit
data type. A variable of type SYSTEM.BYTE may be passed as a parameter to
the ORD or CHR functions to enable it to be used in expressions.

SYSTEM.BYTE has a special characteristic that makes it very useful. If a
formal parameter to a procedure is defined as ARRAY OF BYTE the actual
parameter may be of *any* data type. The parameter can then be accessed
byte-by-byte in the body of the procedure. Hence a 16-bit parameter can be
represented as an ARRAY 2 OF SYSTEM.BYTE.

Alternatively, we also use a user-defined data type e.g. when working with
16-bit quantities returned by an I2C temperature sensor:

TYPE
UInt16 = RECORD high, low: CHAR END;

Regards,
Chris Burrows
CFB Software

Astrobe: ARM Oberon-07 Development System
http://www.astrobe.com

[Chris Burrows]

Post by frrrstfn
I'm trying to writet an Oberon 07 compiler for Microsoft Windows OS.

I recall your previous work with POW! Is that what you are using as a
starting point? How are you going?

We implemented a Win32 Oberon-07 compiler which we use inhouse for
developing / testing some of the generic Astrobe libraries. POW! was one of
the compilers we considered basing it on but eventually chose the BlackBox
Component Pascal compiler. There were a few reasons for this:

a) Some of Oberon-07's features were already there (e.g. INTEGER is 32-bits)
b) We had already experimented with extending CP's IN parameters to apply to
all data types. It was a simple matter to change IN to CONST.
c) The post-mortem debugger in BlackBox can be very useful.

Regards,
Chris

Chris Burrows
CFB Software
Astrobe: ARM Oberon-07 Development System
http://www.astrobe.com