Re: cFASM (calling FASM as a C function)

On Mar 20, 6:48 pm, "vid...@xxxxxxxxx" <vid...@xxxxxxxxx> wrote:
If you go through the FASM source code, you'll find that it's
written using a 386-era programming style. By that, I mean that Tomasz
uses CISC instructions that get as much work done per byte of object
code as possible. While that was an effective programming style at one
time, on the modern "more-RISC-like" x86 CPUs you pay a heavy penalty
for using that programming style. A classic example is how Tomasz uses
the SCASD instruction to do nothing other than increment EDI by 4.
Clever, if saving space is your prime concern, but certainly not the
fastest way to add 4 to EDI. Given how heavily string instructions
get used in the code, I wouldn't be surprised to find that you could
double the speed of FASM by replacing those instructions.

In some discussions i recall, Tomasz was against lowlevel
optimizations that makes maintaining harder.

This isn't a debate I want to get into here, but if maintenance is a
concern, substituting descrete instructions for string instructions is
nothing compared with other issues I've found. For example, the
complete overlapping of function boundaries in the code is a real
maintenance nightmare. The fact that one procedure calls another, that
called procedure jumps back into the calling code, sometimes without
cleaning up the stack (intended or otherwise) make maintenance
difficult. Another issue: the almost exclusive use of "magic numbers"
in the source code (e.g., offsets into structs and the like) is a
*real* maintenance nightmare.

But ignoring some existing issues, I just don't see how using "add edi,
4" is going to make the code less readable and less maintainable than
employing a trick like "scasd" to do the same task.

Also, as you probably don't know, size is a concern here. Tomasz wants
to keep .COM version of FASM, but size of FASM is dangerously hitting
64KB. :)

Why keep a .com version? .EXE work fine in 16-bit code. Even if one
insists on keeping a 16-bit version active, there is no reasonable
argument for keeping a .com version in this day and age. Granted, a
"tiny model" program meshes well with FLAT code and nothing special
needs to be done to the source file, but that's the price to pay for
being able to maintain a 16-bit version.
Cheers,
Randy Hyde




.