My assembler project has been to write and implement a translation of an existing Java application used at my workplace. The workplace is a scientific environmental research organisation for which part of my job has been writing application code. The particular application I targeted does constant 24-7 data collection and processing in real time and makes extensive use of timers, floating point math, networking and periodic runtime execution of external programs. Actually, Java is already well suited to this kind of work, but since I had been dabbling with assembly for a little while it really plucked my curiosity how assembler could manage.
I started the project using masm32. However, in order to really satisfy my desire to do things from the ground up I initially started writing a macro library to handle the common conversion and string handling routines etc that would likely be used very commonly. For some of the more difficult routines such as float/string conversions and exponentials/powers I resorted to the masm32 packaged procedures.
At a stage when I was becoming reasonably happy with most of the macros, and already beginning on the application, FASM came to my attention. I was immediately curious about comparing FASM-coding with MASM and began re-writing things in FASM and continuing the project in parallel for while. This was a period where I could make some comparisons between the two: As far as using the syntax is concerned a can't honestly say that I had at that stage any particular preferences, although I struggled (and still do) with some of the advanced FASM directives. FASM was appealing however because of its transparency and by being developed and supported by real people rather than a huge stubborn company.
Then can crunch time when I almost chucked in FASM. I was doing, and still do, most of my development at home on an old Win95 IBM Think-Pad with very limited memory. The application size reached a critical point where when compiling in FASM it caused my computer to spend a very long time apparently paging to disk, blowing the compile time to over 30 seconds. This did not happen with MASM. The problem turned out to be caused by a combination of low memory, FASM extended headers, and way too much macro nesting. The solution was to re-write most of the macros as procedures and work without extended headers. I was also using some MASM-like syntax and "fix"-ing them so that I had more syntax compatibility. This also appeared to create too much overhead for the FASM compiler.
Then came crunch time for MASM. Since I became dependent on lots of procedures that were still developing, I became discouraged having to keep up the "proto"s. That was the "straw" that broke my use of MASM because with FASM I could use the better-designed stdcall. I still think however that core MASM is a good assembler, but my MASM folder went into mothballs.
At present, the procedures and macros are reasonably stable, but always of course, with lots more that could and will be done in terms if robustness and optimisation. The application is completed to that stage of being actually implemented at work, at least for three days now without any catastrophes. There are still plenty of refinements to do, and a few minor bugs, but nothing to stop it from doing its job. The look and feel of the application mimics very closely the Java original. It has to so as not to upset other operators at work. I must admit however that the original did not make much use of widgets and layouts etc for the display, but did use mainly simpler graphics methods.
Some of the FASM/JAVA comparisons statistics are:
Source code length:
FASM:97K (application) + 52K (procedures)
JAVA: 89K (application) + enormous class library
Source lines:
FASM: 3075
JAVA: 2592
Compile time:
FASM: 0.4 s (fast computer), 5.8 s (slow computer)
JAVA: about 2 s, impossible on slow computer
Executable length:
FASM: 42K
Bytecode length:
JAVA: 50K
This is a case of FASM being used professionally for a real job (and to help the environment). It looks very impressive seeing a FASM program being the controlling interface for and monitoring a large room full of scientific equipment! I trust that I have not violated any legal rules in doing so. I would like to know if there are many similar uses of FASM. I find that programming in FASM for this kind of work is entirely feasible and very straight forward when working with a library of procedures, not to mention such fun. I shall next begin on the other Java applications at work.
Thank you Tomasz for such a terrific compiler and all the work you have obviously put into it over the years. I have learnt a great deal and will continue to learn more as I continue with your product.
Chris Leslie
|