I have been working on FPP64 a “C” language preprocessor. It has been updated several times but not placed in version control; at least not in the software folder. It was one of the earlier pieces of software I worked on once I got a computer. Originating in the early 90’s. It is about 30 years old. From a time before the internet

FPP64 is the preprocessor used for the CC64 compiler. Internally, CC64 shells out to the command-line invoking FPP64 to do the pre-processing.
It has been used in compiling the C standard library which has some pretty nasty pre-processor usage.

Now I am looking into modifying it to support assembly language pre-processing with additional assembly language constructs.

Do you intend to give your C preprocessor more assembly language-like macro facilities?

A feature I've missed in C from assembly languages I had used in the past has been to repeat a block of code.
Some assemblers feature also:
- iteration count as a variable in the repetition body
- if/else - preprocessor-like directives inside the repetition body
- repeat-statements in macros

I have had need for this when programming const static data structures that are supposed to be stored in Flash memory of a memory-constrained microcontroller. I have resorted to kludges like as this:

That is the intent. It will be a command-line switch to enable assembly language pre-processing. (a syntax setting ‘/S’). Many of the directives are the same except for the character indicating a pre-processor directive. “if”, “else”, “endif”, etc are supported.

The intent is to support repeat statements. They are treated like macros and have an instance counter that is available. “\@”. They can also have arguments passed to the repeat statement like a macro. I am not having much luck getting nested repeats to work, and they are needed if repeat is supported. There could always be a repeat statement in an included file resulting in a nest.

The current assembler pre-processor I have been using evaluates everything as numerics, it works great. This means it does not easily support text manipulations, however. FPP64 evaluates everything as text strings. The Verilog pre-processor in use does not support ‘ifdef’ ‘ifndef’ properly. It treats them like a ‘if’ expecting the symbol to be defined. I may use FPP instead.

The older version of FPP had huge buffers statically allocated (eg 10,000,000B) that it used for processing. This made it a bit of a memory hog. It has been changed to use buffers incrementing in size by a memory page (4kB) as needed.

Repeat statements will likely have a max iteration count (100). Otherwise, they could generate a lot of text.

Currently FPP uses memory to expand macros and repeat statements. A lot of memory may be required if there is a large macro repeated numerous times.

Here is a test sample that seems to work.



And result:

More work on FPP64. This time implementing the iterative repeat directive ( “.irp”). I managed to get repeats working better, though not perfect yet, they might be useful. To support nested repeats the pre-processor now makes multiple passes through the input files. Each pass should resolve one nesting level of repeats. ToDo is to detect nested repeats and automatically make enough passes to accommodate them.

Including a file in the middle of a repeat does not work.

Yet more work on FPP64. Trying to get macro and repeat instance variables working (the ‘\@’). When the variable is in a repeat instance it is not changing when it should. I figured it would be easy to add.
Figured out how to get nested repeats to work without needing more than a single pass. They are not macro-like in the sense that they are done immediately in place.
Put code in to suppress extra blank lines appearing in the output due to macro expansions and other directives.

After an early morning coding session,
I believe I have it working! For “instance” variables in repeat statements a large string constant may be generated which indicates the repeat instance and the macro instance.

For example, for three levels of repeats and a macro expansion the constant looks like the following:

One worked_000014_00004_000011_00004_000007
One worked_000014_00004_000011_00004_000008
One worked_000014_00004_000011_00004_000009
One worked_000014_00004_000011_00004_000010

Spent some time tweaking the code. Got a lot done today.

Tweaks
The repeat processing code was broken up (refactored) into more smaller functions to ease future maintenance. It was also placed in its own file. Some other code was refactored to make naming conventions more consistent.
Generally, I do not like to see functions that are too large, and the repeat code was getting that way. It makes maintenance a headache. It is difficult to remember how large functions work, and much easier just to read how smaller ones are operating. One should not memorize the code. I find relying on memory also leads to mistakes.

Extra blanks at the start of lines in the output are removed now. The extra blanks were somewhat unpredictable and made the output harder to read. Removing the blanks should mean less processing for the compiler too.

The directive table was made two-dimensional, one dimension being the syntax. This was done so that a large table did not need to be scanned comparing against a syntax value. It can simply be indexed by the syntax number. This may improve performance.

Found a way to reduce the number of characters output for the instance variable.

Changed SubMacroArg() to use the buffer struct and a dynamically allocated buffer rather than a large static buffer. Also added a function to append a single character to a buffer.

The expression parser was updated to handle 64-bit values. It was also updated to suppress error messages when a value is not needed that would otherwise generate an error. For example, the macro text may expand to (0/0) (this happens in the std C headers). It would normally generate a divide by zero error, but if the value is not needed then the error is suppressed. The same is true of the conditional operator.

Bug Fixes
Stringize was only operating for macros that had parameters. Stringize code needed to be added for parameter-less macros.

Going nuts getting fpp64 to work. Major changes started by an example from GNU as which did not work with fpp64 (a recursive macro definition). Version 3.0 has a large part of the code re-written. It is not quite working yet.

Some heavy-duty coding sessions going on. A major re-write of fpp64 in progress.

Milestone:
Got the following to work:

Which is an example from GNU of a recursive macro definition. It expands out to:



I also believe I have nested repeats working.
It needs to be tested a lot more yet; code is not very stable yet.

Created a branch version called “3.0”.

Fixed the crazy argument expansion. arguments are now reduced, resulting in:



Version 3.01

Constantly improving.

The completely re-written version 3.xx of fpp64 passes a lot of the test suite without issues now. (The test suite is about 200 files testing a C compiler). There is a fair bit of pre-processor testing as well. There were lots of things that were not working correctly, resulting in mostly minor code changes.

Additions included variadic macro functions. This feature was not yet completely coded, it is now.
Macro arguments are reduced where possible. It is assumed the argument is supposed to have a numeric value, if that fails, then it is treated as string.