Proof of concept pre-processor

[hutch--]

I have had this basic capacity in mind for a while but have been a bit swamped to get it up and running. The attached program pp.exe will accept a source file and if certain macros are called from the source file, it will perform the text replacement of parameters and replace the call with the contents of the macro. The simplified form of word testing was made possible by Michael Websters switch$ macro system and has made extending a test piece like this reasonably easy as it tests the word and contains the .DATA section string for the macro in the same place.

There are faster ways to test for words but when each macro may only have 3 or 4 arguments, constructing a hash table or dynamic tree will probably be slower. This version does sequential work replace from the list of arguments in the macro to perform the parameter replacements. A technique like this one is probably well suited for a play assembler, small compiler or a scripting language.

The macro format is the simple MASM style and it support statement style macros only, it only reads the first word to test if the line of text is a macro or not so function style macros as are used in MASM with EXITM <value> cannot be done at the moment. The wordtest capacity has been put into a seperate file to facilitate changing this particular method to one that is a lot more powerful, something like a hash table for pointers and a block of memory that the pointers keep track of for any macro calls.

[attachment deleted by admin]

[Vortex]

Hi Hutch,

Back home, I will check the attachment. Is this topis associated with the fact that MS is planning to create the 64-bit Masm without high level constructs?

[hutch--]

 :bg

Not really,

Manhattan has just posted the reply that Microsoft will continue to support the high level constructs in ML64 on the basis of popular demand. This is aimed at small tools like the ones I mentioned and it was designed to test out a number of ideas. ALthough STDOUT is slow, the overall speed of the algo seems OK and if it was written directly to a file or alternatively to memory as a file image, it should be more than fast enough for macro expansion.

[Farabi]

:bg

Not really,

Manhattan has just posted the reply that Microsoft will continue to support the high level constructs in ML64 on the basis of popular demand. This is aimed at small tools like the ones I mentioned and it was designed to test out a number of ideas. ALthough STDOUT is slow, the overall speed of the algo seems OK and if it was written directly to a file or alternatively to memory as a file image, it should be more than fast enough for macro expansion.

Mister hutch, is ML64 support mmx? I cannot use the mmx instruction right now.

[hutch--]

Use .MMX at the top of your code near the .486

[Randall Hyde]

:bg

Not really,

Manhattan has just posted the reply that Microsoft will continue to support the high level constructs in ML64 on the basis of popular demand. This is aimed at small tools like the ones I mentioned and it was designed to test out a number of ideas. ALthough STDOUT is slow, the overall speed of the algo seems OK and if it was written directly to a file or alternatively to memory as a file image, it should be more than fast enough for macro expansion.

Mister hutch, is ML64 support mmx? I cannot use the mmx instruction right now.

I do know that MS had killed support for the FPU in Windows64. They argue that everyone should use SSE rather than FPU for floating point operations. Just so you know. Whether this applies to MMX or not, I haven't a clue (do they save FPU/MMX state across task switches?)  If they don't support MMX under Win64, I can see why the assembler wouldn't support those instructions.
Cheers,
Randy Hyde

[hutch--]

I have just had some time to play with the PP test file and created a 5 milion line test file of about 69 meg.

running the command line,

Code Select Expand


  pp tt.txt > result.txt


It ran in just under 15 seconds, loading the file, expanding the macros and writing them back to the output file which ended up about 119 meg.

I know this type of operation can be done faster again with dedicated procedures but so far it does seem fast enough for a reasonable sized code delivery tool.

[Farabi]

I have just had some time to play with the PP test file and created a 5 milion line test file of about 69 meg.

running the command line,

Code Select Expand


  pp tt.txt > result.txt


It ran in just under 15 seconds, loading the file, expanding the macros and writing them back to the output file which ended up about 119 meg.

I know this type of operation can be done faster again with dedicated procedures but so far it does seem fast enough for a reasonable sized code delivery tool.

Cool. That still very fast.