Hi,

I have some old Pascal code that was compiled in a CPM environment using the Pascal/MT+ compiler from Digital Research. I'm trying to get this project to build in a modern environment, for a start using FreePascal.

First, is anyone aware of a tool for converting this dialect of Pascal to something that FreePascal will accept ?

Second, the old code contains a lot of:

var
foobar : external integer;

in sources that reference 'foobar', then there is a declaration in one of them:

var
foobar : integer;

As I understand it, in order to translate this to something that FreePascal understands, the variable needs to go in a "unit" and be part of its interface. Then, pascal sources that needs to reference the variable should use this unit. Is this the easiest way forward ?

I thought maybe I instead could adapt the syntax like:

var
foobar : integer; external;

but with this I still get undefined references when linking. Using units seems ok.

Bets regards
Jacob

On 2023-03-27 11:45, Jacob Kroon via fpc-pascal wrote:

Hi,

Sorry, no idea.

Yes, most likely.

Indeed - while using the keyword 'external' as outlined in your modified example would be possible (even for importing a variable from another FPC compiled unit), it's primary purpose is for importing variables coming from object files compiled using different compilers (e.g. C, etc.) and there's no reason for using it for variables declared in a FPC unit in most cases (let's put some special cases aside for now).

Tomas

Hi,

Jacob Kroon wrote

As I understand it, in order to translate this to something that FreePascal understands, the variable needs to go in a "unit" and be part of its interface. Then, pascal sources that needs to reference the variable should use this unit. Is this the easiest way forward ?

Probably yes, but there might be an alternative, see below. But as far as I understand, Unit is a Turbo Pascal concept, so any Pascal programming dialect that predates it, probably don't understand it.

Yes, because all symbols in a Pascal unit are stored as mangled names, which includes the Unit name. This way you can have "foobar" defined in two different units, and can still reference them as Unit1.foobar; and Unit2.foobar;. But of course it will cause linker errors, because the compiler has no way of knowing the right mangled name. External is normally used to link against C libraries, which don't use name mangling.

If you want to export a variable without name mangling, you must declare a public name for it, something like:

var
  foobar: integer; public name '_myfoobar';

Then reference it as:

var
  foobar: integer; external name '_myfoobar';

You might wanna consider this approach, because if units somehow end up cross-referencing each other, then you might run into difficulties restructuring the code to use Units. Also, it is possible to cross-reference units from eachother, but there are some caveats.

With the external way, you only need to change the declarations of variables, no need to restructure the code, although for long-term maintenance, that might be still beneficial.

Charlie

Karoly Balogh wrote

Probably yes, but there might be an alternative, see below. But as far as I understand, Unit is a Turbo Pascal concept, so any Pascal programming dialect that predates it, probably don't understand it.

True, and before units in Turbo Pascal(*) and Modules in Extended Pascal, nothing was standardized about breaking up the source into multiple parts.

Most dialects either adopted some form of C "extern" like handling, and the more advanced ones some form of Modula2 derived modules, either directly, or via the lengthy Extended Pascal standardization process.

(*) Turbo Pascal was strictly not a standard, but influential enough to
set one.

On 2023-03-28 11:33, Karoly Balogh via fpc-pascal wrote:

Hi,

.
.

Since some changes would be necessary anyway even if using imports (not only adding public names plus changing the external references, also some changes necessary to get multiple object files linked into the same final program), I'd suggest biting the bullet and changing the code to units, but yes, an alternative exists.

Tomas

Well, it is a very long time since I used Pascal MT+ the last time, and that was already on the x86 version (+30 years now), but the same things should still apply.

First of all, Pascal MT+ is more or less ISO7185 compatible, so you would have to use that mode in FPC if you don't want to change all those file reference (that's what's mostly different to a "real" Pascal :P )

As for the "external" vars (and possibly procedures/functions), it is not quite the same as the units in UCSD/Turbo/Delphi/FreePascal, but it had the possibility (due to source code size restrictions, you had only 64KB for OS, compiler and source code together) to compile different source files into separate object files, which then could be linked together with the linker. It is more of an "forward" declaration. In most cases, I would assume that you could actually copy all those source files that are being referenced into a single source file. Using units could work in a lot of cases, but which way to go might depend on your actual use case...

Ralf

Units was actually something that was taken over from UCSD Pascal, which had them for more than a decade before Anders Hejlsberg introduced them with Turbo Pascal 4.0. They were omitted from the earlier versions due to space constraints on CP/M, then the CP/M versions were translated more or less 1:1 from Z80 to 8086 code and they were added when Turbo Pascal 4.0 was pretty much rewritten from scratch...

Ralf

Hi Charlie, everyone,

On 3/28/23 11:33, Karoly Balogh wrote:

[cut]

[cut]

Thanks for the tip above.

I was able to write a couple of perl-scripts that are able to convert my old Pascal sources to something that fpc can parse. Amongst other things, the scripts inject the "public name"/"external name" annotations so that the program can link.

But I suspect I have a new problem: With the old Pascal/MT+ compiler it would appear that local variables declared in functions/procedures have a life-time that spans the whole program, like a "static" declared variable in C. With fpc, it looks like locally declared variables are automatic, put on the stack(?), and so they go out of existence once out of scope ?

The program depends on this feature in the old compiler. I did some googling and found that putting local variables in a "const" section instead of "var" would make them have a "whole-program" lifetime, but then I need to provide them with an initial value.

Do I have any other option besides changing from "var" to "const" everywhere, and provide initial values in all declarations ?

Regards
Jacob

IMO, this is not a feature of the old PASCAL compiler, but instead your Pascal programs "by error" depends on the local variables appearing at the same location on the stack at subsequent calls as before (if there are no other calls at the same level in between).

The local variables are not initialized when allocated, and so it is possible
that they still have the old value that they had when the same function was left the last time. I know (from the 1970s and 1980s) that some weird programs
used this effect. But as soon as another call was entered between the two calls
of the procedure, the stack at this location was overwritten, and the "clever" use
of the old value of the variable was not possible any more. And: it depends on the
stack being initialized to a known default value in the first time.

This said: the initial value of the local variables is UNDEFINED, and this is true
for every Pascal compiler. I cannot imagine a compiler which doesn't follow this basic rule.

So IMO: you should find the places in your program, where this weird technique is used
and not blame the old compiler for this.

Some compilers have an option which initializes every automatic variable on every allocation;
some compilers even allow the bit-pattern to be specified (for example: 0xff).
While this is a performance nightmare, this is very good to run the program once during program test,
because it will show if your program depends on such effects or if it produces different values,
depending on initialized or uninitialized local variables.

Kind regards

Bernd

On 2023-04-04 08:16, Jacob Kroon via fpc-pascal wrote:

Hi Jacob,

.
.

Yes, local variables are declared on stack and their lifetime is indeed equivalent to the time of processing the particular function/procedure.

You don't need to change "var" to "const" - if you want to ensure the variables to persist in between the function/procedure runs, you need to move them to the global level, i.e. outside of the functions/procedures. It is not advisable as a general practice (to keep all variables globally), because then you might e.g. access the same variable from multiple functions by mistake, but it would probably solve your issue. Obviously, you might need to solve potential conflicts if you use the same variable names in multiple functions/procedures (e.g. by prepending the function/procedure name to the variable name or something like that).

Tomas

Make them actually global variables.

procedure X;
Var
  y : integer;
begin
// Use y
end;

becomes

var x__y : integer;
procedure x;
begin
   // use x__y
end;

I did this operation manually for some programs that I had to update. Maybe perl can help.

Michael.

Michael.

Hi Bernd,

There is a programmers guide for the Pascal/MT+ compiler here:

http://www.bitsavers.org/pdf/digitalResearch/pascal_MT+/Pascal_MT+_Language_CPM_Programmers_Guide_Mar83.pdf

In chapter 4.1 it states that the "LOCAL VARIABLE STACK" is only used in programs compiled with the $S+ option set for recursion, and I don't see it set anywhere in my source code. So I think in my case, the local variables are actually not stored on the stack.

[cut]

Regards,
Jacob

Hi Tomas,

On 4/4/23 09:01, Tomas Hajny via fpc-pascal wrote:

[cut]

I could move them to global scope, and add a prefix to avoid name collisions, but using a "const" section seems more readable to me since I don't need to add a prefix.

The wiki page says (https://wiki.freepascal.org/Const):

"The declaration const in a Pascal program is used to inform the compiler that certain identifiers which are being declared are constants, that is, they are initialized with a specific value at compile time as opposed to a variable which is initialized at run time.

However, the default setting in Free Pascal is to allow const identifiers to be re-assigned to."

Then it says there is a flag to make reassigning to a const variable an error. But if I ignore that, it would seem this is just what I need, since this seems to make the variable have a whole-program lifetime, no ?

What is the technical downside to using "const", or is it just cosmetic ?

Regards,
Jacob

Hi Michael,

On 4/4/23 09:05, Michael Van Canneyt wrote:

[cut]

Ok, makes sense. I'll see if putting them in "const" sections makes more sense, otherwise I guess this is the route I'll have to take.

Regards,
Jacob

On 2023-04-04 09:43, Jacob Kroon wrote:

Hi Jacob,

If you read the documentation (wiki or the real documentation in PDF/HTML etc.) properly, you don't find there anything saying that constants declared locally within functions or procedures are guaranteed to keep their modified values across runs of that function/procedure. It might behave like that, but you shouldn't rely on it unless it's a const on a global level (and then renaming may still be needed in case of conflicts).

Tomas

Hi Tomas,

Fair enough, good point.

Regards
Jacob

Tomas Hajny via fpc-pascal schrieb am
Di., 4. Apr. 2023, 09:51:

It *is* documented (the remark at the end):
https://www.freepascal.org/docs-html/current/ref/refse10.html#x22-210002.2

Regards,
Sven

Sven Barth wrote

Tomas Hajny via fpc-pascal schrieb am Di., 4. Apr. 2023, 09:51:

.
.

OK, my bad. :-( Thanks for this correction.

Tomas

What is the technical downside to using "const", or is it just cosmetic ?

If your local "writeable constant" is of type string, and strings are longstrings, and the writeable const is assigned a value that is the result of a string concatenation, then you'll have a memory leak.

Well, managed types are not very likely in code imported from a Pascal compiler not knowing units...

Tomas

Well, managed types are not very likely in code imported from a Pascal compiler not knowing units...

Well, his fpc.cfg might define string to be ansistring...

I'm not positive, because I've never used them, but I'm pretty sure variables configured as const, can't be changed once they're defined.  If that's your intent, then feel free to use them, but it sounds like you're trying to make variables (not constant values) last for the whole program, with manipulation being allowed.  In that, case, simply define them in the var section before you do any of the functions and procedures.  That will make them visible for the whole program, and they won't go out of scope.  I know many folks contend that global variables should be kept to a minimum, and scope should be carefully evaluated, and only allow variables to be usable when they're actually needed, and to some degree, I agree, but there's times when it's just too darned convenient to have something accessible for the whole program over multiple functions/procedures, and in those cases, I see nothing wrong with having as many globals as you need.

Often, when I'm doing a quick and dirty program, (I.E. one to change a data file from one format to another), I won't even bother with functions and procedures, just write the whole program as one big main procedure, since it's only being run once or twice, then never used again, I see nothing wrong with this approach either, and in that case, all variables are global.

No reason you can't do the same, and not depend on quirks of the compiler to keep your items in scope especially when they clearly shouldn't be.

Didn't know that either:

"It should be stressed that typed constants are automatically initialized at program start. This is also true for local typed constants and initialized variables. Local typed constants are also initialized at program start. If their value was changed during previous invocations of the function, they will retain their changed value, i. e. they are not initialized each time the function is invoked."

described here: https://www.freepascal.org/docs-html/current/ref/refse10.html#x22-210002.2

Bart wrote

If your local "writeable constant" is of type string, and strings are longstrings, and the writeable const is assigned a value that is the result of a string concatenation, then you'll have a memory leak.

That does not matter in practice (*), since when the program terminates all memory gets released to the OS anyway. And before that, the memory would never be released, even if that bug got fixed.

Jonas

(*) unless you are using heaptrc to hunt for other, non-benign memory
leaks, since then it will be a bit harder to identify those.

Travis Siegel via fpc-pascal schrieb am
Di., 4. Apr. 2023, 20:34:

I'm not positive, because I've never used them, but I'm pretty sure variables configured as const, can't be changed once they're defined.

For typed constants that depends on the $WritableConsts directive.

Regards,
Sven