Doing C-like linking of multiple Pascal files

[david.given]

I have a very old program (1983, probably) which I'm trying to build with FreePascal. Unfortunately, it seems to want to be structured into multiple Pascal files which get compiled separately, and then linked together, like C does.

Code: [Select]

$ ack -c -o out1.o out1.p
$ ack -c -o out2.o out2.p
$ ack -c -o out3.o out3.p
$ ack -o program out1.o out2.o out3.o
Is there any way to replicate this with FreePascal? I think I've figured out how to make it generate just an object file from single source file, but FreePascal doesn't like taking .o files on the command line for the linking stage. I do know about {$L} but would like to avoid it due to not wanting to change the historical source files unless absolutely necessary.

[TRon]

Just some observations:
- These kind of archaic actions are usually only necessary when there is no source-code. You have the source-code so looks to me like trying to make it as complicated as possible for no gain. When the original code is not too exotic you should be able to link in the resulting objects in any unit with the L compiler directive (e.g. no need to touch the original files).
- FPC is a compiler, not a linker. use option -k to pass things over to the linker

Free Pascal is able to generate the linker script omitting the actual linking stage. That linker script can then be used to manually adjust to then be passed to the linker on the command-line (just as you could do in/for c (or any other compiled language for that matter)).

[Thaddy]

Looks like you need the 8086 cross compiler and a 16 bit linker if you don't want to touch the original code. And mode TP. You would also need a 16 bit platform, like dosbox.
(@TRon fpc comes with internal linkers for some platforms )
Personally I use the original TurboPascal - which is free - in dosbox for my geriatic code. Quite a lot that I really should translate to 32 or 64 bit code but that will almost always need modification of the sources.
For example I have the sources from a program called "geef" written by Peter Backer - I use it with permission - which is a database program that is the precursor to PerfectView, which was very popular in the netherlands in the 80's and 90's, but is way too complex to translate to 32 or 64 bit without much, much effort and a team of programmers. But since it is good I run, edit and compile it in dosbox with TurboPascal 3 or 5.5. OTOH we did manage to make PerfectView 32 bit but I do not have the PerfectView sourcecode.(I worked for PerfectView and enjoy a small part of my pension because of that)

[TRon]

Yes, thank you Thaddy. I am aware though.

It is just the moment you want something more than just your standard linking that you have to fall-back to an external one anyhows. Especially with these kind of niche issues.

Ofc that which is possible depends on the actual (source)code. asm and/or access to hardware requires far more work to be able to bring up to par in which case you need to fall back as described by Thaddy.

[MarkMLl]

Just some observations:
- These kind of archaic actions are usually only necessary when there is no source-code. You have the source-code so looks to me like trying to make it as complicated as possible for no gain. When the original code is not too exotic you should be able to link in the resulting objects in any unit with the L compiler directive (e.g. no need to touch the original files).
- FPC is a compiler, not a linker. use option -k to pass things over to the linker

Free Pascal is able to generate the linker script omitting the actual linking stage. That linker script can then be used to manually adjust to then be passed to the linker on the command-line (just as you could do in/for c (or any other compiled language for that matter)).

I'd broadly echo that. Generally speaking FPC does everything as a single operation, although you could probably move each sourcefile into a separate package... I'm not defending that, just saying it the way it is. For documentation purposes you can obviously write a makefile rather than relying on e.g. the Lazarus IDE to get things right, hence e.g. https://github.com/MarkMLl/Mastech_ms2115b/blob/main/ms2115b/Makefile

MarkMLl

p.s. Love the work you've done on Cowgol. Are you still at Zürich?

[MarkMLl]

I have a very old program (1983, probably) which I'm trying to build with FreePascal. Unfortunately, it seems to want to be structured into multiple Pascal files which get compiled separately, and then linked together, like C does.

If you're where I think you are... what compiler was this for? You might do better with one of the P series, hence https://github.com/StanfordPascal/Pascal etc.

MarkMLl

[Thaddy]

Mark, fpc is compatble to P5 (ISO mode)

[MarkMLl]

Mark, fpc is compatble to P5 (ISO mode)

At the source level, not necessarily at the commandline level.

MarkMLl

[david.given]

The program I'm dealing with, BTW, is C.H. Lindsey's Algol 68S compiler from 1977-1983. The source code is extremely peculiar, with its own custom preprocessor and extensions, and also line numbers. It even comes with its own custom bytecode Pascal compiler. Here's an example.

Code: [Select]

00750 (*-03()
00760 (*+01() PROGRAM A68SCOM(SOURCDECS, OUTPUT+, LGO, LSTFILE, A68INIT ); ()+01*)
00770 (*-01() (*-05() (*+71()
00780 PROGRAM A68SCOM(SOURCDECS, LGO, LSTFILE, A68INIT, DUMPF, OUTPUT);
00790 ()+71*) ()-05*) ()-01*)
00800 (*+25() PROGRAM A68SCOM(SOURCDECS, OUTPUT, LGO, LSTFILE, A68INIT ); ()+25*)
00810 ()-03*)

It's tempting to try and refactor this into something modern, but I really don't think that's a good idea as this is a genuine historical artifact. I would like to try and build this in as original a format as possible. It will (mostly) compile with p2c but I'm very distrustful of a compiler which claims to prioritise readable output over correctness! It's structured as a set of bag-of-procedures files, which get separately compiled and then linked together, and it's this structure which I'm trying to replicate in FreePascal (in -Miso mode).

However, this may all be moot. Someone's just discovered that the way the compiler is built is that it loads a preinitialised memory image, which is generated by doing partial builds of the compiler, running the init code, and then dumping the heap to disk --- this works entirely because of the way it's compiled to individual object files. This of course won't work on any modern system. So we'll probably have to persuade the preprocessor to generate a single file containing both the compiler and all the init code, so eliminating the need for partial compilation.

Still, it'd be really nice if FreePascal could be persuaded to work in a mode more like traditional compilers. It'd make it so much easier to, e.g., integrate into third-party build systems.

[MarkMLl]

The program I'm dealing with, BTW, is C.H. Lindsey's Algol 68S compiler from 1977-1983. The source code is extremely peculiar, with its own custom preprocessor and extensions, and also line numbers. It even comes with its own custom bytecode Pascal compiler. Here's an example.

Those leading line numbers are nasty. B5500 ALGOL (which I've got running here on a mainframe emulator) has /trailing/ line numbers (significant for conditional inclusion), but work on the principle that the compiler truncates at column 72...

Code: Text  [Select][+][-]

1. COMMENT  ----------- NOTE ALGOL STATEMENT LIMIT OF 72 CHARS -----------; 4567890
2. % ---------------------- NOTE CARD LIMIT OF 80 COLUMNS ----------------------- %
3. ...
4.   END IF % ANYTHING AFTER END IS IGNORED HERE.                                 %
5. END.     % END MUST BE FOLLOWED IMMEDIATELY BY . HERE ------------------------ %
6.  

It's tempting to try and refactor this into something modern, but I really don't think that's a good idea as this is a genuine historical artifact. I would like to try and build this in as original a format as possible. It will (mostly) compile with p2c but I'm very distrustful of a compiler which claims to prioritise readable output over correctness! It's structured as a set of bag-of-procedures files, which get separately compiled and then linked together, and it's this structure which I'm trying to replicate in FreePascal (in -Miso mode).

OK, so let's try to work out what we're talking about here. You've got an ALGOL compiler written in Pascal, where the Pascal is subject to a custom preprocessor (which rings a bell) and outputs bytecode as you've shown above.

What you /could/ do would be write a mechanical translator using Perl or whatever that systematically and repeatably converted the source you've got into a "modern" form, and could annotate program output listings to look like the original source.

If they're "bag of procedure" files, could you handle them by rewriting only the main program and then including them?

One problem that you're going to have is that- going by my recollection of when this was last discussed- FPC doesn't have full support for the ISO import/export syntax, and I don't think fixing that is high on the developers' list of priorities.

However, this may all be moot. Someone's just discovered that the way the compiler is built is that it loads a preinitialised memory image, which is generated by doing partial builds of the compiler, running the init code, and then dumping the heap to disk --- this works entirely because of the way it's compiled to individual object files. This of course won't work on any modern system. So we'll probably have to persuade the preprocessor to generate a single file containing both the compiler and all the init code, so eliminating the need for partial compilation.

There's little I can say there other than "ouch". Reminds me a bit of PS-ALGOL, Plus of course of Stallman's experience when he tried to construct a compilation system based on Pastel.

Still, it'd be really nice if FreePascal could be persuaded to work in a mode more like traditional compilers. It'd make it so much easier to, e.g., integrate into third-party build systems.

Regrettably, there are people in this forum who will argue forcefully that FPC is doing things perfectly, and it's high time that the rest of the World caught up. I'm not one of them, and I don't much like cmake either.

Updated: the lack of a preprocessor for FPC has been discussed before, there aren't any hooks in the compiler and no prospect of anything being added... "if you want that sort of thing use a makefile but generics are almost always adequate".

MarkMLl

[PascalDragon]

Still, it'd be really nice if FreePascal could be persuaded to work in a mode more like traditional compilers. It'd make it so much easier to, e.g., integrate into third-party build systems.

Well, you can tell it to skip linking when compiling a program. Or you compile per unit, but the compiler must be able to find the other units and will compile them if there's no up-to-date PPU file, cause that's how multi-module Pascal works as otherwise the compiler would not be able to resolve symbols.

[domasz]

Try to convert the source code to modern pascal using ChatGPT.