system.pas_(re)

Fri, 20 Jun 1997 01:08:15 +0200 (MET DST)

According to Frank Heckenbach:
> According to The African Chief:
> > According to Frank Heckenbach:
> > >
> > > (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?)

What about `__BORLAND_PASCAL__' and `__DELPHI__' (and `__EXTENDED_PASCAL__'
and `__STANDARD_PASCAL__' etc. which are of course useless because these
dialects don't allow conditional defines anyway;-)?

> > 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.

This was one of the very first things I did to GPC.  It was in version
1.1-turbo-alpha-1.0, aka turbo-gpc-2.6.3.tar.gz, aka turbo11b.zip.

Everybody, PLEASE check what GPC can already do and what it cannot BEFORE
you post to this list.  You are confusing possible GPC newcomers!  ;-)

> 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.

Ignoring a function's return value *is* a risky thing, because it
switches off an error-checking rule which is important for teaching.
Programmers who want to use this feature usually (should;-) know what
they are doing, and won't be hit by the other "risky" things.  For
instance:  A beginner might unintentionally increment a pointer instead
of the value pointed to.  An expert probably won't - he produces much
uglier bugs.

> So I'm asking the asm experts here:

I am not an asm expert, but here are my guesses.

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

It won't change.  To much GCC stuff depends on the asm syntax as it is
now, and GPC will stay compatible to GCC.  Maybe, somebody will implement
an alternative Borland-compatible asm syntax, but this will be an extension.
(And, since I now know the advantages of GPC's asm syntax, I won't even
vote for doing that.)

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

No.  (Note:  That's only for iX86-platforms.)

> - Is calling the Dos interrupt like I did it ok, or is there a better way
>   (perhaps some DPMI calls

Praxis has shown for me that interrupts which don't pass pointers work
without any DPMI magic.  But take care of clobbered registers!

>   -- perhaps even without any asm, that would be better).

No.  This would be *very* system-dependent, so it should not be a GPC
built-in.

> > >  As a preliminary solution for the overloading problem, one could use
> 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?)

It does work.

> Would it seem reasonable (and feasible) to propagate defines
> (either all of them, or only those that are specially marked) through
> .gpi files?

No.  Defines are C.  We do Pascal.

However, it would be desireable to allow inline functions transported through
GPI files which have the same functionality (including translating C macros)
but are *much* cleaner.  To achieve this, somebody would have to extend my
`store_tree()' (in `gpc-module.c') to store function bodies in GPI files, too.

    Peter

 Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer
peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201]
 maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

Peter Gerwinski (peter@agnes.dida.physik.uni-essen.de)