system.pas_(re)

Thu, 19 Jun 1997 15:36:20 +0200

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.
-- 
Frank Heckenbach, Erlangen, Germany
heckenb@mi.uni-erlangen.de
Turbo Pascal:   http://www.mi.uni-erlangen.de/~heckenb/programs.htm
Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

Frank Heckenbach (heckenb@mi.uni-erlangen.de)