PC organization #236
samiam95124
started this conversation in
General
Replies: 1 comment
-
Runs! |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
PC organization
pc, the Pascaline compiler integrator will be a central part of Pascal-P6, just as it was for IP Pascal, and like Cargo is for Rust. The reason is it automates everything in the build process, gets rid of the need for make files, and simplifies the creation of programs.
The pc.ins file and libs
The starting point for pc is the pc.ins file in the ./bin directory. In Pascaline terminology, the criitical paths are program, user and current. This is also the search sequence for .ins files that tell pc what to do. The most basic information gathered from pc.ins in the bin directory is the module path, which in pc.ins is defined as ../libs. What this means is that wherever you install Pascal-P6, that's all it needs. You execute pc, hopefully by putting it on the $PATH, and it knows from there where to find the libs directory. This means we don't need environment variables or other "sideband" information to compile and run programs.
What's in the libs directory
The fundamental library is psystem, which is a collection of two files into an archive psystem.a. It has NO callable Pascaline routines, but it does have a Pascaline header file psystem.pas. It was easier to provide a null file than to create an exception for that file.
Following that is the services file set, services.a and services.pas. services.pas is the same header file everywhere, since there is no Pascaline source in the file. It is a C file from Petit.ami. Its an archive because it is actually a complex file consisting of an assembly and a C level wrapper file and a support file.
Following that are various support libraries with stripped headers, including strings.pas/strings.o, parse.pas/parse.o. The actual source for these exist in libs/source, but they could be anywhere. For example, psystem.c exists in the AMD64 directory for historical reasons (it contains no AMD64 specific code and will probably get moved). The reason the files aren't archives is that they are simple one source files. The .pas header files in libs are always stripped, mainly just to cut down on duplication of source.
Ordering
Pascaline has strict ordering requirements, but then so do archive files. The difference is that Pascaline files have a startup/shutdown sequence built into the binaries. Look at the make entry for test, which illustrates this:
In the link order, the space from main.o to test.s is the "Pascaline startup/shutdown" area. Pascaline modules call each other to establish startup/shutdown orders. main.o starts the sequence, and then the program file, test.s, ends it. Non-Pascaline modules MUST not appear in this area. Because they don't have Pascaline start/end sequences, they will just crash.
Both before main.o and after test.s are C module insert areas. We use the latter area for C support files. Because these are usually archives, they also have ordering requirements, because the "use" of routines in the archives must appear BEFORE the archives. The reason is because gcc determines what to pull out of the archives based on references to routines.
So why is this complex Pascaline startup/shutdown sequence there? Well, the system in Pascal-P6 is actually a lot simpler than the pragma system in gcc, and it is completely automated by PC. PC does this by forming a dependency tree. In gcc, startup/shutdowns are determined by a number, and thus the user must assign numbers to each module that has a startup or shutdown or both according to "priority". The reason this is not a bigger deal in gcc is most programmers avoid using it[1].
How does PC resolve ordering issues? Within Pascaline modules, it creates a dependency tree. In C/Assembly archives, it uses ordering rules, like psystem is always last, services next, etc.
Exclusions
PC's basic job is to catalog the components signified by different files, process them to completion, and link the result together to form an executable. The components are .pas (source), .s (assembly), .o (objects) and .a (archives).
In terms of the libs directory, none of these should get built by PC. If it tried it, in most cases it would just destroy the output file .o or .a. This is because it has access to the stripped header files, not the source. So the pc.ins file has exclusions for this directory. This could also be done by write protecting the files, but the exclusion mechanism is better.
The "PC is a Swiss army knife" idea
As in IP Pascal, after PC handles most of the work, it starts to look like a good idea to have PC automate all builds, including lower level components. The arguments against this are:
The result is "we'll see".
PC does it all
The other idea is extending PC to cover all forms of Pascal-P6 runs:
IP Pascal didn't have an interpreter, and it used script files to do testing. So this would be new functionality.
[1] And you probably have figured out, I am not most programmers.
Beta Was this translation helpful? Give feedback.
All reactions