I'm thinking of porting some blitter code from NASM to MASM and I have a couple of questions I wanted to ask.

The code essentially consists of a set of basic 2d graphics effects (color keying, alpha blending and so forth, sometimes in multiple versions to take advantage of enhanced instruction sets). As well as loop frameworks with different ways of fetching the pixels to be processed (horizontal flipping, VQ compression, unrolled alignment cases). To deal this combinatorial explosion I've naturally opted to compose everything through macros.

Now the main reason I want to switch assemblers in the first place is due to NASM's apparent inability to produce debugging information which Visual Studio can understand. Unfortunately from the little I've tried to use MASM it appears as if a macro is simply treated as a single atomic line in the debugger, and with the entire functions being generated that means I get no benefit at all from having debugging information.
In C I'd be able to solve this problem by letting the preprocessor at the code separately as a precompilation step. And at worst I suppose I could use a separate preprocessor to write the macros but that would be ugly and inconvenient to say the least, and I can hardly be the first to have this problem.

Another feature I'd really like to take advantage of is function-level linking. With the set of blitters growing exponentially and the average user only using a handful it's a golden opportunity to save space. My question is do you simply have to specify a unique COMDAT statement and segment for each function for it to work? What about symbols imported from these functions (the blitters call various setup functions written in C), are these dependencies automatically tied to the function's segment? I guess the size hasn't really become significant yet, I could partially solve the problem by splitting things into more files, but it'd be nice not to just not have to worry about it.

By the way here's a recent beta of the library in the unlikely event that anyone cares: http://www.minoan.ath.cx/~doynax/JRADev_20070723.zip.
Posted on 2007-07-24 19:24:29 by doynax
I'm afraid I can't help you with the macro/debuggability question, and I never got to look properly at manual COMDAT generation... but perhaps you should consider moving to runtime generated code, to avoid massive binaries.

I don't know if the softwire project is still alive, but that project was geared at runtime assembly (including register allocation and some stuff) - but it's developer is still active on this board :)
Posted on 2007-07-25 05:13:07 by f0dder

I'm afraid I can't help you with the macro/debuggability question, and I never got to look properly at manual COMDAT generation... but perhaps you should consider moving to runtime generated code, to avoid massive binaries.

I don't know if the softwire project is still alive, but that project was geared at runtime assembly (including register allocation and some stuff) - but it's developer is still active on this board :)


It's really not enough of a a problem to let it dictate my choice of assembler and function-level linking would be a far simpler solution if I could get them to work. Besides the size of the dynamic assembler itself would almost certainly dwarf any amount of blitters any reasonable project might use (we're not talking about fancy pixel shaders in endless variations here, just your basic 2d effects).

The main problem, though, is that with dynamic code generation I'd get no symbolic debugging at all (right?) which was kind of the problem I was trying to solve in the first place..
Posted on 2007-07-25 05:33:29 by doynax