The African Chief wrote:

I am not sure I understand what you mean. However, the idea is this. GPC is a 32-bit compiler that wants to support the BP syntax; so we try to do support the *syntax* - thereby helping BP folks to move their programs to 32-bit.; so we keep the data structures in their 32-bit format - but, if, for some reason, a person who wants to move his 16-bit programs to 32-bit with GPC still wants his data types to be exactly as they are in a 16-bit compiler, then he has to remove a dot on one line in the unit wherein the data types are defined, and recompile his program.

Yes, I see the problem. So your defaults are to use the bigger types. I don't think that's a problem for most programs (though I just saw one that wanted to write a LongInt, and gpc can't yet write 64 bit variables -- but, of course, it would make more sense to implement this feature into the RTL than to restrict the size for that reason :-).

I'm not sure I really understood how your declaration looks like. Is it the following:

{.$ifdef borland-16-bit}

In this case, one would have to remove the dot, and to define "borland-16-bit", wouldn't one? I think you can just remove the dot always. Then programs compiled without "borland-16-bit" would still use the long types, and the short types if compiled with that define (which can be put into the source if one wants to use it always, or given on the command line ("-Dborland-16-bit") for one-time use).

...

(Is there a way to test in a program, if "--borland-pascal" or "--delphi" was given?)

I know of none.

If there isn't, could you make one, Peter? (Perhaps just some predefined symbols?)

True enough. In BP, when {$X+} is used, you can use functions just like procedures. Perhaps Peter can add this to GPC as well, so that no warning is generated in such instances? If this happens, then we don't need to turn off warnings.

Perhaps (additionally) a separate switch for those who want to use functions as procedures, but without the "risks" implied by "{$X+}" in other aspects? I guess, most of my units would use such a switch.

...

• If you want to use my random functions in System, you're welcome to

include them, of course. (Perhaps one day we can claim "100% BP compatibility -- even the random numbers are the same..." ;-).

Okay, thanks. I will see if I can add it. AFAICR your unit uses some ASM statements. Are we sure that ASM code in GPC will stand the test of time?

I'm not ;-(

So I'm asking the asm experts here:

- First, the asm syntax -- can it change, or will it always work like that?

- Could using 8 and 16 bit registers ever be a problem (note: that's only for __DJGPP__ and __EMX__)?

- Is calling the Dos interrupt like I did it ok, or is there a better way (perhaps some DPMI calls -- perhaps even without any asm, that would be better). If so, could someone please provide the code to do so?

...

As a preliminary solution for the overloading problem, one could use the (case-sensitive!) preprocessor, as by defining "{$define random RandReal}". Then "random" would be for real types, and all other cases for integers. (Or perhaps vice versa? Or all-caps?) At least, programs could be the same for BP and gpc in this respect. :-)

The problem with $define is that it does not export from units. Will this be a problem?

Yes! :-(

The only way to do it (AFAICS) are include files, or defines on the command line. (BTW: does "-Drandom=RandReal" or such work, or could it be made to work?) Would it seem reasonable (and feasible) to propagate defines (either all of them, or only those that are specially marked) through .gpi files? At first sight, I'd think so.