Hi,

I have some source code i'm trying to compile. The problem is, that it (the compiler) seems to be completely ignoring the $F+ compiler flags.

Here are the commands i'm using to compile the source (Linux IA32):

ppc386 -FWwpo1.wpo -Mtp -OWall -CX -XX -Xs- -al -Tlinux imp
ppc386 -FWwpo2.wpo -Mtp -OWall -Fwwpo1.wpo -Owall -CX -XX -Xs- -al -Tlinux imp

ppc386 -Fwwpo2.wpo -Mtp -Owall -CX -XX -al -Tlinux imp

Does anyone know why it's behaving this way?

Thanks,

|09ignatius |07(|15cia|07)

--- DayDream BBS/UNIX (Linux) 2.15a
* Origin: catch22bbs.com >>> >> > (1:340/800)

30 Jun 16 23:39, you wrote to All:

I have some source code i'm trying to compile. The problem is, that it (the compiler) seems to be completely ignoring the $F+ compiler flags.

quoting from http://www.freepascal.org/docs-html/prog/progsu21.html

===== snip =====

1.2.21 $F : Far or near functions

This directive is recognized for compatibility with Turbo Pascal. Under the 32-bit and 64-bit programming models, the concept of near and far calls have no
meaning, hence the directive is ignored. A warning is printed to the screen, as
a reminder.

As an example, the following piece of code:
{$F+}

Procedure TestProc;

begin
Writeln ('Hello From TestProc');
end;

begin
testProc
end.

Generates the following compiler output:
malpertuus: >pp -vw testf
Compiler: ppc386
Units are searched in: /home/michael;/usr/bin/;/usr/lib/ppc/0.9.1/linuxunits Target OS: Linux
Compiling testf.pp
testf.pp(1) Warning: illegal compiler switch
7739 kB free
Calling assembler...
Assembled...
Calling linker...
12 lines compiled,
1.00000000000000E+0000

One can see that the verbosity level was set to display warnings.

When declaring a function as Far (this has the same effect as setting it between {$F+} ...{$F-} directives), the compiler also generates a warning: testf.pp(3) Warning: FAR ignored

The same story is true for procedures declared as Near. The warning displayed in that case is:
testf.pp(3) Warning: NEAR ignored

===== snip =====



with that said, what compiler mode are you using?


quoting from http://www.freepascal.org/docs-html/user/userse33.html

===== snip =====

7.1 Free Pascal compiler modes

The Free Pascal team tries to create a compiler that can compile as much as possible code produced for Turbo Pascal, Delphi or the Mac pascal compilers: this should make sure that porting code that was written for one of these compilers is as easy as possible.

At the same time, the Free Pascal developers have introduced a lot of extensions in the Object Pascal language. To reconcile these different goals, and to make sure that people can produce code which can still be compiled by the Turbo Pascal and Delphi compilers, the compiler has a concepts of 'compiler
modes'. In a certain compiler mode, the compiler has certain functionalities switched on or off. This allows to introduce a compatibility mode in which only
features supported by the original compiler are supported. Currently, 5 modes are supported:

FPC
This is the original Free Pascal compiler mode: here all language constructs except classes, interfaces and exceptions are supported. Objects are
supported in this mode. This is the default mode of the compiler.
OBJFPC
This is the same mode as FPC mode, but it also includes classes, interfaces
and exceptions.
TP
Turbo Pascal compatibility mode. In this mode, the compiler tries to mimic the Turbo Pascal compiler as closely as possible. Obviously, only 32-bit or 64-bit code can be compiled.
DELPHI
Delphi compatibility mode. In this mode, the compiler tries to resemble the
Delphi compiler as best as it can: All Delphi 7 features are implemented. Features that were implemented in the .NET versions of Delphi are not implemented.
MACPAS
the Mac Pascal compatibility mode. In this mode, the compiler attempts to allow all constructs that are implemented in Mac pascal. In particular, it attempts to compile the universal interfaces.

The compiler mode can be set on a per-unit basis: each unit can have its own compiler mode, and it is possible to use units which have been compiled in different modes intertwined. The mode can be set in one of 2 ways:

On the command line, with the -M switch.
In the source file, with the {$MODE } directive.

Both ways take the name of the mode as an argument. If the unit or program source file does not specify a mode, the mode specified on the command-line is used. If the source file specifies a mode, then it overrides the mode given on the command-line.

Thus compiling a unit with the -M switch as follows:
fpc -MOBJFPC myunit

is the same as having the following mode directive in the unit:
{$MODE OBJFPC}
Unit myunit;

The MODE directive should always be located before the uses clause of the unit interface or program uses clause, because setting the mode may result in the loading of an additional unit as the first unit to be loaded.

Note that the {$MODE } directive is a global directive, i.e. it is valid for the whole unit; Only one directive can be specified.

The mode has no influence on the availability of units: all available units can
be used, independent of the mode that is used to compile the current unit or program.

===== snip =====


)\/(ark

Always Mount a Scratch Monkey

... A man without a God is like a fish without a bicycle.
---
* Origin: (1:3634/12.73)

with that said, what compiler mode are you using?

-Mtp (Turbo Pascal)

Thanks,

|09ignatius |07(|15cia|07)

--- DayDream BBS/UNIX (Linux) 2.15a
* Origin: catch22bbs.com >>> >> > (1:340/800)

01 Jul 16 23:25, you wrote to me:

with that said, what compiler mode are you using?

-Mtp (Turbo Pascal)

and none of the source files have anything else?

remember, too, that this will be a 32bit or 64bit compile where (i hope) the documentation points out that the old paged memory access stuff is now obsolete... FAR and NEAR calls don't do anything any more in the (very large) flat memory model used today...

is there an explicit problem with your test builds that relies on FAR (AND maybe NEAR) calls?

)\/(ark

Always Mount a Scratch Monkey

... You! Kidney failure! -Death
---
* Origin: (1:3634/12.73)

is there an explicit problem with your test builds that relies on FAR (

I don't know why my quotation doesn't work. But, anyway. Here are the
commands I compile the source with:

ppc386 -FWwpo1.wpo -Mtp -OWall -CX -XX -Xs- -al -Tlinux imp
ppc386 -FWwpo2.wpo -Mtp -OWall -Fwwpo1.wpo -Owall -CX -XX -Xs- -al -Tlinux imp

ppc386 -Fwwpo2.wpo -Mtp -Owall -CX -XX -al -Tlinux imp

As you can see, the "-Mtp" is at every iteration of the compiler command(s). Doing things this way, decrease the binary by about 300KiB. I know I should probably use the IDE, but I don't.

What i'm thinking, maybe i'm wrong, is that the $F directive will solve some problems i'm having with the code. Like the garbled message headers for example. And, hopefully, the allowance of replying to messages. Maybe this is far fetched, I don't know. But i'm crossing my fingers.

Thanks,

|09ignatius |07(|15cia|07)

--- DayDream BBS/UNIX (Linux) 2.15a
* Origin: catch22bbs.com >>> >> > (1:340/800)

02 Jul 16 02:46, you wrote to me:

is there an explicit problem with your test builds that relies on FAR (

I don't know why my quotation doesn't work.

me either...

But, anyway. Here are the commands I compile the source with:

those do not override what may be specified in each source file...

[trim]

What i'm thinking, maybe i'm wrong, is that the $F directive will
solve some problems i'm having with the code.

to reiterate what the documentation says, $F is recognized in TP mode but there
is no such thing as FAR or NEAR calls in 32bit and 64bit flat memory models...

Like the garbled message headers for example. And, hopefully, the allowance of replying to messages. Maybe this is far fetched, I don't know. But i'm crossing my fingers.

no, NEAR and FAR calls won't help with that... there is a flaw in the code that
leads to misalignment of the data in some instances... it is either that or memory corruption which should not be happening if you are building with debugging enabled...

)\/(ark

Always Mount a Scratch Monkey

... Good customers are as rare as latinum.
---
* Origin: (1:3634/12.73)