Hello, all.

According to Borland's official language guide to Turbo Pascal 7.0,

To be used as procedural values, procedures and functions must be declared with a 'far' directive or compiled in the '{$F+}' state.

whereas Free Pascal in -Mtp seems to accept any non- system procedure or function as a value of a proce- dural type. Is it an instance of TP incompatibilty or am I missing something?

That would probably be only relevant on i8086. All the other targets don't have the distinction in "near" and "far", so it's not necessary to artificially restrict everything.

Regards,
Sven

Sven Barth to Anton Shepelev:

But this is from the Language guide -- a document that descrbes the language in a platform-agnostic way, except when the contrary is explicitly inidi- cated. Where Turbo Pascal did not accept a proce- dure without the 'far' modifier, one should expect Free Pascal to reject it also in 'TP' mode.

I have cross-checked in my excellent Russian manual for Turbo Pascal 7.0, which confirmed the require- ment to declare with 'far' any procedure or function that is intended as a value of a procedural type.

Hi,

It's documented, that Free Pascal ignores far and near directives because they were for 16bit code, and have no meaning in 32bit or 64bit code:

https://www.freepascal.org/docs-html/user/usersu82.html

Therefore it's logical that the compiler also ignores their absence.

Although this documentation should probably be updated, because we now support some 16bit and 8bit systems as well. But I'm pretty sure you can find a bunch of other things, which FPC allows even in TP mode, but TP disallows/doesn't support, just because the amount of extra features in the language since TP was out...

Charlie

Karoly Balogh to Anton Shepelev:

Ignoring them in the sense of not affecting the gen- erated machine code is perfectly OK, but not requir- ing their presence in the source, to make the pro- gram compilable in Turbo Pascal, seems wrong when Free Pascal is in Turbo Pascal mode. A program that Free Pascal compiles successfully in TP mode should work with the actual Turbo Pascal compiler. Is it not the purpose of these modes? Do they guarranty only forward-compatibility?

Although this documentation should probably be up- dated, because we now support some 16bit and 8bit systems as well.

There is more to correct, e.g.:

In Free Pascal, you need to use the address @ opera- tor when assigning procedural variables.

This is not true of TP mode.

I think such features should be available in Delphi and FPC modes, but not in TP, which should implement and enforce Pascal in exactly the way it was sup- ported in the historical Turbo Pascal compiler.

Hi,

Yes. We won't stop you allocating more than 64K RAM with GetMem() in one go, or restrict how much stack you use, how big is your code, how long your source lines are for example, which are also all TP incompatible. The size of the real type is also incompatible, you can still use ansistrings and a bunch of managed types, or 64bit integers, in fact you can even do that on i8086 with Free Pascal. To use Port[] you need to add unit Ports to your uses clause, even in TP mode. I could go on and on... So no, our TP mode was never designed with the promise that whatever you write in it will be compilable by TP, but we try to be as close as reasonably possible, without compromising our compiler integrity. And for that, ignoring far/near was perfectly fine.

Yes, the use of @ operator is compiler mode specific. This is actually documented here (at the @ operator page):

https://www.freepascal.org/docs-html/3.0.2/ref/refse83.html

As I said, we won't enforce all the limits with TP enforces on you, simply because we can't, and we don't want either, and it's not the purpose of Free Pascal.

Anyway, if you still think this needs to be fixed in TP mode, feel free to come up with a patch, and open a bugtracker entry about it. But it's highly unlikely we'll ever try to enforce all TP limits, especially ones which don't make sense on modern processors.

Charlie

The modes are for the case have code written for other compilers (TP, MacPas, Delhi, ISO) work in FPC (as good as reasonably possible). We do however *not* guarantee that code written in one of these modes with FPC compiles or runs with the corresponding compiler.

Regards,
Sven

In our previous episode, Anton Shepelev said:

But this is from the Language guide -- a document that descrbes the language in a platform-agnostic way....

Then you have a very different TP manual than me. Mine is really only for the specific 16-bit case, and there is no platform agnostic allowance how it would work on 32/64-bit in that manual. (or even in different 16-bit models than implemented, e.g. huge, something they did know, since Turbo C++ has it)

Karoly Balogh to Anton Shepelev:

I used this one:

http://turbopascal.org/files/Turbo_Pascal_Version_7.0_Language_Guide_1992.pdf

and the built-in TP documentation:

http://putka.upm.si/langref/turboPascal/

Neither source makes any exceptions about the 'far' and 'near' reserved words. Thence I concluded that even though on some platforms these concepts may be useless, they are still part of the Turbo Pascal language and shall be used as described regarldess of architecture even if for cross-platform compati- bility.

I now see from other replies that the -Mtp mode helps compile TP programs in FPC but not vice versa, which makes me wonder why pointer arithmetics is so limited in -Mtp that one must use Inc and Dec in- stead of the direct '+' and '-' operators.

I mis wrote

Karoly Balogh to Anton Shepelev:

Beg your pardon for the misattribution, Marco.

Because this is disabled by default in that mode. You can change that with {$PointerMath On} (
https://freepascal.org/docs-html/current/prog/progsu112.html#x120-1210001.3.29 ), like you can enable many other features in the more restricted modes, but you need to do that explicitly, as there might be code breakages due to this.

Regards,
Sven

In our previous episode, Anton Shepelev said:

The BP manuals (the language bits of which I have read several times)does not make ANY exceptions and only describes what is implemented, and maybe an occasional reference to win3.11 models or TC++.

Thus I include it is not a platform independent language description at all, but an implementation reference.

And FPC does correctly document the deviations in case it is not already clear.

Moreover, near and far could get meaning in some cases again, and going your way would seriously hurt implementation freedom (requiring FAR to be default, while it might not be the default of the platform, thus requiring many codechanges to get existing codebases running). So while it sounds like a futility, it is not.

Sven Barth:

Thank you and others for your explanations. I have a related question which seems unworthy of a new thread. I can't compile this program with -Miso:

  Program Test;
  var object: integer;
  begin
  end.

Free Pascal tells me that

  test.pas(2,5)  Fatal:  Syntax  error,   "identifier"
  expected but "OBJECT" found.

According to the documentation, in this mode

the compiler complies with the requirements of level 0 and level 1 of ISO/IEC 7185.

but ISO/IEC 7185 does not list 'object' as a re- served word. I have also failed to find an -M fea- ture responsible for the support of stack-based ob- jects. How can I disable it?

In our previous episode, Anton Shepelev said:

Works fine here with 3.0.0 and trunk with -Miso (I tested by issuing fpc -Miso test.pp on copy and paste code above)

Afaik hiding reserved words was a 3.x feature, so it might not work with older versions.

Marco van de Voort to Anton Shepelev:

That explains it. I have 2.6.4 and will upgrade now. I am not an enthusiast of adding lots of new features, as C# and Java do in every new release, but the hiding of reserved words where they have no meaning is certainly a good idea. Thank you.