Optimizing Assemblers

[Albert_redditt]

I was wondering;
Instead of creating an optimizing compiler, for a High level Language like C , C++ ,???

Why hasn't anyone created an Optimizing Assembler?

An Asembler that takes the ordinary input *.ASM and rewrites it;
to fully exploit the desired processor instructions and regs and utilize the fastest instruction sequences.

It should even be possible for a program to rewrite 16 or 32 bit asm to 64 asm or the other way around.
Or turn Alpha,SPARC *.asm to X86 *.asm or the other way around.

[KeepingRealBusy]

Albert,

When will you have this done. I would like to try it out!

Dave.

[jj2007]

Me too :icon_mrgreen:

Remember the szLen optimise thread in the old forum? Over 300 posts - all that could be done by the optimising assembler.. ::)

[hutch--]

Albert,

It sounds like an interesting idea until you think about it, generally you write critical code in an assembler for a specific advantage to other automated methods of code production (generally compiler output [which also claims to produce optimised output]) but in practice rarely ever live up to their promises. The problem is that tasks are very varied and the CISC nature of x86 assembler instructions are so complex to codify that even very good optimising compilers cannot handle the flexibility and range of manual code.

One of the solutions is libraries that perform specific tasks (sorts, searches, graphic conversions etc ....) but if you have a task that has not been pre-canned into a library module then you generally write the algorithm yourself and pass it through the only tests that matters, correctness and SPEED.

Where assembler code has its real advantages is in algorithm construction, you must know what you are doing and be willing to time and modify code and algorithm design to get the speed advantage that you are after. When you get it right THEN you put it into a library module so that you can reliably re-use the code.

[dedndave]

i thought we wrote in assembler to avoid such things
the idea is - you are in charge - you are in control - all problems are your fault   

[Albert_redditt]

I was thinking about HLL compilers or even Assemblers.

And rather than the compiler trying to optimize the code , you have the assembler optimize it.

This would probably require a multi-parrallel *.ASM parse tree;  with,
  a branch for calculating register allocation requirements.
  a branch for calculating Individual Instruction times.
  a branch for calculating Function times.
  And then you would have an "Invention Branch", that invents the fastest instruction sequences, that matches that set of code for that or another  processor.

I mean, why would you sit and intentionally write 1 mega byte or more of assembly code??
Especially knowing that it wont be good or optimized for the next round of processors.

=============================================================
Thats why i was thinking of the possiblity of a cross-processor optimizing assembler.

It could have all the processor instinsics, of multiple processors, from multiple vendors, and still INVENT the best ASM, for a particular processor model.

I imagine, you could sell such a beast of a program, for several thousands of dollars to individual companies, maybe even charging per-seat liscenses like MicroSoft does.

[hutch--]

There is a solution, write your own. Most companies already do this and they call it a C/C++ compiler. Theories of optimisation are many but they still must be put into practice and the sheer complexity takes corporate resources to get going and the results of the best can at times be very ordinary. Most things can produce non-critical hack code but its exactly when you need a very detailed grasp of both the task and the technical capacity of the processor that this approach does not perform.

The historical solution has always been libraries, the technique to target specific things that a compiler is never going to be smart enough to handle and this is why most compilers come with their own libraries, some of which may be written in assembler. Now with 64 bit you are going to have to wait some years before they start producing the code quality that the later 32 bit C compilers were producing which often was very good but 64 bit is a new animal and a more complex animal again.

As far as processor family specific optimisations go, blended model was always a theory based on clapped out old optimisation techniques and many of the techniques assumed RISC rather than CISC which further distorted the techniques used. It was not that long ago that high end C compilers were still loading a value into a register first before performing an operation on it and while this was a big deal in a PII, it stopped mattering by about the PIII era.

I hope you do OK if you ever try and write a successful optimising compiler but be warned that it is a task that needs corporate resources to even vaguely get going.

[Daydreamer]

You underestimate masm macro caps hutch
You can program masm with help of macros entirely and unlock keywords to be reprogrammed too
And just include for example inc file for targeted you at top of your main .asm file
take a look on my SSE2 macros from old forum to see how I do things

[jj2007]

You underestimate masm macro caps hutch
You can program masm with help of macros entirely and unlock keywords to be reprogrammed too
And just include for example inc file for targeted you at top of your main .asm file
take a look on my SSE2 macros from old forum to see how I do things

http://www.movsd.com/board/index.php?topic=973.msg6946#msg6946 [deleted by admin]

> unlock keywords to be reprogrammed too
Can you give an example? I'd like to use Instr and For as macro names but there is obviously a conflict...

[MichaelW]

How about OPTION NOKEYWORD:<FOR INSTR>

[hutch--]

MAgnus,

You may be surprised what I know about MASM, I have only been using it since about 1990.  The problem with your comments is it is not addressing what the post was about which was a theory about an optimising assembler. Pre-canned assembler is trivial, macros, pasted code blocks and of course libraries are the main options you have available but this is technically different from an optimiser, something generally found in better C compilers.

Michael's comment makes sense, if you want to remap keywords, then use the "option" option and you can turn off and reuse keyword names without problems. I have always avoided the technique as it interferes with portability across different MASM programs.

[jj2007]

How about OPTION NOKEYWORD:<FOR INSTR>

Works fine if you don't have any macros that are using FOR or INSTR ;)