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.
Great. But don't forget to rename CARDINAL8 to OCTET ;-)
<shameless-plug>
Greetings from Mitwitz, Upper Franconia, in Germany where I am running a village bakery during the Christmas season for the owner who is out of action due to hip replacement surgery. Anyone interested in artisanal Stollen, a German Christmas bread with dried fruits and spices, we'll ship certainly within Germany, but also elsewhere within the EU/EEA. Contact me by email.
</shameless-plug>
regards
benjamin