Error in macros\compile-time arithmetic and preprocessor support.

[JeremyWildsmith]

I cannot do (and I think I should be able to) do something like this with macros:

macro _sfLocal(offset) {

[b - offset + 1]

}

set _sfLocal(0), 10

I am not sure why this isn't supported (or maybe I am not doing it properly?)

You may also notice that the above code looks very odd, since I should be subtracting offset and then 1 from b, though it appears as if I am subtracting offset then adding one.

Devkit interprets the following statement: b - offset + 1

as if it were:

b - (offset +1)

which is

b - offset -1

Which has a completely different definition. Than the original.

FInally, I would like it if we could implement some layer of preprocessor to our code via plugins.

At the momment, there is no efficient way to implement a preprocessor via the plugins without having to reimplement an assembler. Consider if I wanted to extend on to the current .10c file type provider, I would need to reimplement the entire provider and then add whatever layer I wanted overtop. I would appreciate it if I could override a specific routine of the .10c file type provider and then add some logic overtop the existing assembler.

[kierenj]

I'm investigating the preprocessor issue thanks. It is easier than starting from scratch to write a preprocessor, the C compiler plugin uses the assembler 'service' that is available. But I like the idea of chaining processes and output. How would you best like the user to experience a preprocessor : if plugin loaded then always preprocess on all asm files, a property on project files, or something else?

[JeremyWildsmith]

Hmm, well right now you have a ISourceFileScope interface. It would be nice if we could chain some member functions of that interface. Specifically the the handler for the CompilationPass.Pass2ExpandMacros .

I'm not sure how it is designed internally, but it would be nice if we had some sort of chained system for pass 2 (i.e, plugin can add pass 2 logic routine to a chain, and when the code is compiled, the compiler steps through the chain and does each routines preprocessing in the chain in the order they were added). Hmm, I haven't thought about how exactly it would be implemented. It would be difficult IMO with the current design because it makes sense to chain pass 2, but I don't understand how the remaining passes would be chained (but the routine which handles pass 2 also handles all of the other passes, so it isn't as simple as overriding the Compile function.)

As an example of what I'd want to do:

Have a statmenet like

@EXPORT( Label) : (code here...)

I would transform this to Label: (code here...)

And allow 0x10c devkit to process it as usual, but also add the relative address of that label to an internal list (inside of the plugin.) Then, when 0x10c is done doing everything (compiling and generating executable code), I would prepend the entire executable generated by 0x10c devkit with binary header, that would include some data along w\ this list (via the plugin.)

I think something like this should be do-able with plugins. This isn't just for developing executable images, it will also allow people to very easily add very comprehensive features to your compiler.

[JeremyWildsmith]

Further, this would allow someone to change something like:

dat szStr("Hello") to dat 0x(HexEncodedNullTerminatedAsciiSingleByteString)

or dat pascalStr("Hello") etc...

via plugins which imo is pretty high in demand