Re: Partial success building the trunk on MSYS2/Windows platform

[Gaius Mulley]

Benjamin Kowarsch <trijezdci@gmail.com> writes:

> Dear Andreas and Gaius,
>
> On Tue, 8 Nov 2022 at 01:02, Fischlin Andreas <andreas.fischlin@env.ethz.ch> 
> wrote:
>
>  Yes, having such types in SYSTEM I would strongly argue against, not the 
> least for all the reasons Benjamin has already given. In addition I think 
> performance penalties are often overrated or expected in the "wrong
>  place" (as several studies showed).
>
> I wholeheartedly agree.
>
> Language extensions that are not unsafe do not belong in module SYSTEM.
>
> Wirth added a pseudo-library for unsafe facilities to Modula-2 in response to 
> having experienced the Mesa language of which Modula-2 is a derivative when 
> he spent a sabbatical year at Xerox PARC. In Mesa, the cast
> function was called LOOPHOLE(). Wirth wrote about this and he liked and 
> promoted the idea of stigmatising unsafe operations. This is what led him to 
> add a pseudo-module for unsafe facilities in Modula-2. Unfortunately,
> the name he chose doesn't really come with a stigma though. It should have 
> been called UNSAFE instead.
>
> Then you get that stigmatisation, Wirth wrote about ...
>
> foo := UNSAFE.CAST(Foo, bar);
>
> This is the path we took in our revision. We also changed
>
> PROCEDURE Foo ( VAR anything : ARRAY OF WORD );
>
> PROCEDURE Bar ( VAR anyPointer : ADDRESS );
>
> to 
>
> PROCEDURE Foo ( VAR anything : CAST ARRAY OF BYTE );
>
> PROCEDURE Bar ( VAR anyPointer : CAST ADDRESS );
>
> and UNSAFE must be imported for that syntax to be available.
>
> https://github.com/m2sf/m2bsk/wiki/Language-Specification-(11)-:-Low-Level-Facilities
>
> It is ironic that although Wirth liked the Mesa way of naming the cast 
> function LOOPHOLE() for its stigmatising effect and it inspired him to invent 
> the SYSTEM module, neither did he put his cast function into SYSTEM, nor
> did he make its syntax stigmatising.
>
> But make no mistake, SYSTEM is there for unsafe facilities. That's its 
> purpose.
>
> Types like CARDINALnn, INTEGERnn etc, shouldn't be in SYSTEM, they do not 
> belong there.
>
> As for performance penalties, there shouldn't really be any.
>
> First, if the approach is used I had explained earlier, that is to say 
> multiple implementations for different underlying hardware and then select 
> the one that is targeted at build/link time, then the optimal implementation 
> for
> the given platform will always be used, UNLESS there is no such specific 
> implementation and the build process had to fallback on a generic 
> implementation that isn't optimal.
>
> Second, as Gaius mentioned, function calls can be inlined, thus even the 
> minor performance hit of a function call can be avoided.
>
> BTW, Gaius, if you are adding non-PIM and non-ISO types, you are no longer 
> compatible with neither PIM nor ISO anyway, you already created a dialect of 
> sorts. And if you do that, why not just borrow the respective
> facilities from our specification?
>
> https://github.com/m2sf/m2bsk/wiki/Language-Specification
>  
>  It does make sense to move the sized types (CARDINAL8 et al) out of
>  SYSTEM and place them to their own definition module, say gcc_CARDINAL8.
>  The gcc_CARDINAL8 implementation module could implement the range
>  checking found in gcc/m2/m2expr.cc and also draw upon the gcc internal
>  datatypes (and ranger functions) if they are supported and if not then
>  execute modula-2.
>
> First, there should be a type LONGCARD in addition to LONGINT. And
> LONGCARD should be native, just like LONGINT, available without any
> import. Since it constitutes a language extension, it can be enabled
> with a compiler switch, and turned off by default.

Hi Benjamin,

ah thank you for spotting this - I will change them to be enabled with a
switch -fm2-long (?).  I propose moving the gcc supported sized types
into GCCTypes.def now and longer term implement non hardware/gcc
supported types via the mechanism shown below.  Not least because it
makes it easier to maintain and debug range checking - single stepping
the overloaded procedure functions below would be very useful.

> The types LONGCARD and LONGINT should be guaranteed to match the largest 
> register size of the target platform.
>
> This is what we have done in our revision, BTW.
>
> https://github.com/m2sf/m2bsk/wiki/Language-Specification-(9)-:-Predefined-Identifiers
>
> This alone would already be sufficient in a large number of use cases where 
> one might otherwise want to use CARDINALnn and INTEGERnn types. But if they 
> are still desired as built-in types, they could be put into another
> pseudo-module, just not SYSTEM.
>
> If they are library types though, then I would plead for using clean proper 
> Modula-2 identifiers for those libraries.
>
> DEFINITION MODULE CARDINAL8;
>
> TYPE CARDINAL8 = ...;
>
> And if you must have inline operators for library defined numeric types, 
> there is always ...
>
> PROCEDURE [+] sum ( n1, n2 : CARDINAL8 ) : CARDINAL8;
> PROCEDURE [-] diff ( n1, n2 : CARDINAL8 ) : CARDINAL8;
>
> where
>
> n := n1 + n2
>
> is replaced by the compiler with
>
> n := CARDINAL8.sum(n1, n2)
>
> given
>
> VAR n, n1, n2 : CARDINAL8;
>
> which is what we do in our full spec, but omitted in the bootstrap kernel 
> (BSK).

yes very clean - and I look forward to moving some of the lispy C++
overflow detection code from m2expr.cc into the above :-)

regards,
Gaius