pgen refactor goals

[samiam95124]

pgen refactor goals

1. Break pgen into multiple modules (described below).
2. Refactor to use input buffering (described below).
3. Change read and write procedures to use temp for the read/write file.
4. Implement a per-CPU/calling convention flag, like AMD64.
5. Implement cexternal and cwexternal.

pgen modules [done]

The first refactor of pgen modules is:

registers - Describes CPU registers, prints of those registers, etc.
This needs to be a separate module because even the independent logic relies on them.

independent - Gives pgen routines that are not CPU dependent.

pgen - Contains the main module and all logic that is CPU dependent (outside of registers).
In the future these will be named for their CPUs, like pgen_amd64, etc.

Input buffering [done]

Like pcom, pgen will buffer up input lines. This will improve error handling, since errors can
print the input line in error. It will also greatly clean up the logic, because copy throughs (carrying
the input line to the output as a comment) will be a one step process contained in generate,
and not spread over assemble().

Change read/write procedures to use temps

The current read and write procedures chain the input or output file reference via a complicated
mechanism of preserving the file parameter During each chained call. Instead we put the
evaluated file in a temp and let the chained calls load that. Much cleaner and done entirely
in pcom.

Per CPU calling convention

The number of registered parameters becomes CPU specific, and the registered parameters
all go to a so called "pad" on the stack of all pushed registers. At present, all parameters are
both stacked and registered to keep compatibility with the interpreter. This would make
the calling convention in .p6 per CPU compatible, but improves the CPU calling convention
compatibility. The return result is also left in a register. This is also a required step to
prepare for Windows.

cexternal and cwexternal

Described elsewhere, this allows parameters to be converted to C form intelligently as part of
the call. This is done via a combination of "natural" conversions (like strings) and directed conversions done by special mode identifiers. Both cexternal and cwexternal do this convertion. cexternal drops module coining. cwexternal does not, and is used to create wrappers, by redirecting the call to a wrapper equivalent.

[samiam95124]

pgen modules was done, but there is further work needed to separate out the independent parts.

[samiam95124]

That was completed (modularity). The net lines for pgen.pas (the CPU depdent part) is 3317 lines.

Next step is all the pgen files get moved to ./source/pgen. The reason for this is all of the cpu specifics and assembler specifics will go to separate files under the pgen directory, such as pgen_amd64.pas, etc. gas specifics will go into
a support file like gcc_support.pas, but that is not going to happen for a long time (if ever).

[samiam95124]

Per CPU calling conventions

The first option is AMD64. Its true that the full name is the "System V AMD64 ABI", but I think the name covers it, and Windows is another issue (they should use the same convention, IMHO).

This option has a couple of effects:

1. It makes intermediates incompatible with pint/pmach/cmach.
2. The parameters in excess of the first 6 are reversed in order.
3. The return of functions are passed exclusively in rax.

These will have comments below.

parameter reversal

C was designed to REQUIRE that the entire parameter list be stored by the front end so that it can be right to left evaluated. Pascal-P6 does it the easy way and evaluates in source order. This (sorry) stupid pet trick was done to allow varargs stuff like printf() to work.

I don't see significantly refactoring Pascal-P6 to do that as a good use of time (perhaps I'll change my mind later). This can be fixed in Pascal-P6 via two expediants:

1. Have pcom reverse the addressing of parameters in excess of 6.
2. Have pgen swap parameters in excess of 6 into order.

For #2, although pcom does not have the full expression tree available at compile time, that is not so at pgen time, because pgen forms a graph of the intermediate code. Thus the parameter swap can occur by swapping the evaluation. Thus it generates no runtime code for that.

Function returns

This is done by changing the way calls and returns work a bit.

Wrappers

These are fairly light changes, but make the decks incompatible, and negates the current wrappers. In fact, the wrappers get simpler.

[samiam95124]

Cexternal and cwexternal

The issue with cexternal and cwexternal is they occur too late in the parse, after the procedure or function is complete. Thus this doesn't work.

Directives

The closest ISO 7185 Pascal has to this is the "directive", which is an identifier that occurs in a certain place, and we determine to contain a special name. In the case of ISO 7185, its "external", but it could be anything. What this does is allow directives to exist without using a keyword, which would restrict the use of that name in all source code.

c_call and cw_call

Thus it is proposed that these directives be used before the call:

c_call procedure dothis(i: integer; s: string);

The underscore in the directive makes it clear that Pascaline, not Pascal is in use (since that would be illegal in ISO 7175 Pascal).

The difference between c_call and cw_call is that cw_call still coins the module name into the call, like:

mymodule_dothis()

for the above example. The reason we do this is to allow a C call to go to a wrapper first before calling the C code directly, and thus allows the wrapper to make changes in the call.

Default conversions

Since ordinary Pascaline calls are, or will be AMD64 calling convention compatible, the point of the c_call and cw_call conventions is to allow default conversions to take place. Each default conversions depend on the type of the parameter.

arrays

Each array is normally passed by it's base address. However, the parameter will also accept integers, or nil, which is equated to zero (0). The reason is that C commonly uses NULL to indicate a missing parameter. This also applies to small integers on some systems like Windows, in which small integers are not possible as pointers, since the zero page of applications memory is reserved as an invalid page. Pascal-P6 does not, however, check the size of the integer.

pointers

By the same logic as arrays, an array parameter, nil or integer is allowed. The only checking done is that the base type is the same as indicated, if there is one. var parameters are treated as a pointer to the base type.

packed arrays of char with 1 as lower index

This is, of course, the definition of a string in Pascal. On all parameters but out parameters, the string is converted, usually onto the stack, as a string followed by a zero byte. On out parameters, these are converted to a base address and length pair with length following the base address (the same as a container array). For actual container arrays, the rules are the same but use the length the length of string. Pascal-P6 will also obey a directive appearing before the parameter, c_strlen, that indicates that a base address/length pair is to be used even on in parameters.

[samiam95124]

Input buffering

Done.