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.
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?
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.
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.
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).
Furthermore there shouldn't be a performance penalty
(if the hardware supports the datatypes) as the procedure functions
could be inlined.
Indeed.
regards
benjamin