My project

[ChrisLeslie]

Sorry for this verbose post but I would like to talk about my little project, explain its aims and provide some of the results thus far.

Last year I took a serious look at masm32 and was impressed at its ability to produce workable applications with relative ease due to the inbuilt HLL constructs, Microsoft' s APIs, and the concept of providing a library of useful procedures and macros as part of the masm32 package. I was curious as to whether masm32 could be used to write the applications that I had been writing as part of my work. The work applications are for data acquisition, and processing of spectral data of soil samples produced by gamma and alpha ray detectors. Any language use in such an environment would have to:
1) run 24-7 but be resilient and recoverable from possible power outages
2) be ultra-reliable with no memory leaks 
3) use floating point math and floating point arrays extensively
4) capable of talking over networks
5) provide very clear graphical and colorful representations of 2-D spectrums and be able zoom in and shift around at will
6) be idiot-proof and easy enough for science buffoons to operate when they wish, and
7) be very clearly and explicitly written so that frequent modifications can be made quickly, on the fly and without introducing bugs.

Being about the only programming savvy person in a workplace group of scientists I call the shots in how the processing is done. I therefore use Java as it is well suited to those requirements and thus there is no significantly practical need to use another language. However, my curiosity about using assembler and comparing its usability to Java became overwhelming so I embarked on a translation exercise beginning with some smaller applications. The project thus became that of trialing assembler for professional applications that would normally be programmed in a high level language.

At this stage I should say that my choice of assembler language for the project became FASM. However the project was inspired by and began in masm32. When using the extended headers and the full features of the FASM package there becomes minimal differences between the two assemblers in term of usage. Both are equally capable of producing the goods.

I wanted the assembler methodology to be as easy to use as a HLL, therefore I would be making full use of re-useable modules (procedures or macros will replace methods), HLL loop design structures and sensible use of white space and indenting for clarity, readability and maintainability. Application code will have few labels and favor named variables over general register usage. For this kind of work there will be no place for traditional "vertical" assembler coding, cmp/jmp routines or confusing optimized assembly coding gymnastics for the sake of making code small and tight. To do so would probably lead to an incomplete and abandoned project.

Since FASM does not provide a package of application procedures or a library, I think, my first job was to produce a personal package that is both general and tailored to my requirements. In fact most of my time had been spent writing the common procedures for string manipulation, type conversions, floating point operations, disk I/O and GUI etc etc. All were started from the ground up except for fpu log/exp and float/string conversions that I stole and modified from Ray, and shell execute that I initially stole from m32lib. My package is however really only a few include files of procedures and macros. The procedures do favor lower level and optimized coding practices as opposed to application coding specified in the previous paragraph.

At present I have two application translations completed to a useable state. One of which is one of the 24/7 acquisition applications that has been actually running for real now on trial for about five weeks. It has been temporarily taken down a few times to rectify inevitable problems that appeared when running in the real environment. At present the application and the procedures appear to be quite stable although refinements and additions to the procedures will be an ongoing and satisfying job. I am also now able to make comparisons of assembler verses Java for this kind of program development. Perhaps these statistics, for that particular application, may be of interest to you:

Source code length:   
FASM = 82K (application) + 52K (my procedures etc) + Windows include files
JAVA =   89K (application) + bloated class library)

Source lines:
FASM = 2729 lines                   
JAVA = 2592 lines

Compile time (on an old computer):         
FASM = about 4 seconds
JAVA = about 7 seconds

Executable or bytecode file length:   
FASM = 41K               
JAVA = 50K

It is interesting how there is actually little difference between the two, but that is not too surprising as one is a translation of the other. The look and feel of the GUI for the two is deliberately almost identical. Also, the readability of the sources is somewhat equivalent although different in style. The main differences are: 1) Java involves some exotic OOP design concepts while assembler is procedural or structural. 2) Java can handle long math algorithms in a single line but assembler can't, I don't think. 3) The application's computer is short on memory and so much time appears to be spent by the JRE shuffling code between memory and disk, while assembler is lean, clean and quite. I cannot fairly compare application processing speed as that is controlled by timers, but at least a Java JOptionPane Window usually takes some time to come up while an assembler dialog Window seems to come up instantaneously.

Although this can by no means be regarded as a large project it does demonstrate that assembly can potentially handle application development with the ease of high level languages providing that suitable libraries or procedure/macro suites are used. Perhaps this observation will fall over when it comes to large projects as I have not that experience, and Java has a hierarchy of structural foundations to handle large jobs. The only definite exception I found to favoring assembler was in writing math algorithms. Although my procedures have a full suite of math routines there is still the problem of having to write one line per operational step rather than a one-liner algo. This advantage of Java is very important to me as many algos are long and require frequent changes, often on the fly.

This has been an interesting exercise for me and I shall endeavor to convert the remaining applications to assembler, despite the probability that nobody else will ever be interested in reading the code. Not so long ago I was keenly thinking of going all assembler and ditching Java for my work, but now something tells me that that could be an unwise move, but the experience of dabbling in assembler has been an invaluable experience. Without the masm32 package as an introduction I probably would never have made any attempt to use and learn from 32 bit assemblers. 

Cheers.

Chris Leslie 

[raymond]

I'm glad to hear that you have succeeded in adapting some of the procedures from the FPU library for your specific use. This was the primary purpose of providing the source code for each of the library procedures. Some of them, such as the float/string conversions, can be quite complex.

Those procedures necessarily contain some overhead to provide some flexibility for potential users. Most of that overhead can be eliminated for specific applications. The only overhead which I would not recommend to eliminate is that related to error checking when input is not fully controlled and GIGO is not an option.

Congratulations for that project. :U

Raymond