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

[Fischlin Andreas]

Dear Gaius,

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). The considerations Benjamin listed are IMHO way more important and if adhered to in a clever manner, even no or at least tolerable performance penalty may be achieved. And if needed M2 offers sufficient methods, e.g. type overlaying with the variant facility (RECORD CASE) or a definition module without any implementation, to ensure type compatibility with costs only at compile time, but not at run time hereby supporting safe and efficient usage code without performance penalty.

Andreas

ETH Zurich

Prof. em. Dr. Andreas Fischlin

IPCC Vice-Chair WGII

Systems Ecology - Institute of Biogeochemistry and Pollutant Dynamics

CHN E 24

Universitaetstrasse 16

8092 Zurich

SWITZERLAND

andreas.fischlin@env.ethz.ch

www.sysecol.ethz.ch/people/andreas.fischlin.html

+41 44 633-6090 phone

+41 44 633-1136 fax

+41 79 595-4050 mobile

             Make it as simple as possible, but distrust it!

________________________________________________________________________

On 07/11/2022, at 16:04, Gaius Mulley <gaiusmod2@gmail.com> wrote:

"Fischlin  Andreas" <andreas.fischlin@env.ethz.ch> writes:

I fully concur with Benjamin’s arguments. gm2 developers please listen. ;-) Thanks.

Andreas

Hi Andreas,

yes indeed - thanks for the prod - I've been contemplating these ideas.

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

I've wanted to simplifiy m2expr.cc and also re-implement large sets -
and the above approach - would achieve both changes,

regards,
Gaius

smime.p7s
Description: S/MIME cryptographic signature