Re: cFASM (calling FASM as a C function)

On Mar 20, 5:30 pm, "vid...@xxxxxxxxx" <vid...@xxxxxxxxx> wrote:
I've modified the symbol table lookup routines. Sped them up a bit and
used a hash table rather than the hash tree scheme previously used.
This saves a bit of memory for large projects (e.g., assembling the
FASM.ASM source code). There are *lots* of opportunities to speed up
the code, but it really needs to be refactored first.

can you list parts which you suceeded to speed up, and parts which you
think can be boosted to FASM board please? I believe Tomasz would be
interested

When I get done refactoring the code, I'll certainly do that.
In the meantime, the hash function is a bit slow. True, it generates
values that produce very few collisions, but it's expensive to
compute. I replaced it with a stupid 16-bit ROL and XOR hashing
function and sped up symbol table searches in FASM by about 15%. I got
rid of the hash tree and replaced it with a hash table (16-bit, 65536
entries) and that sped up the compilation of FASM.ASM quite a bit.
The next thing I'll probably look at in terms of performance
enhancement is the way FASM does reserved word lookups in the symbol
table lookup code -- it's basically a linear search (which can
obviously be sped up quite a bit, especially considering the number of
reserved words). Granted, there are some optimizations, such as
hashing off the length of the identifier, but there's still
considerable room for improvement here.

I suspect a *huge* performance improvement can be made by eliminating
most of the string instructions in the code. Except for movs*, the
string instructions are generally *far* slower than the discrete
instructions they replace. CMPS* is particularly offensive in this
regard. 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.
Cheers,
Randy Hyde

.

Relevant Pages

  • Re: Hashing
    ... Computing the hash function, which is handled by the instructions: ... reserved word/identifier when searching through the reserved words ... collisions and four slots that have four collisions. ...
    (alt.lang.asm)
  • Re: Definitions - What are yours?
    ... *something* about the FASM code, ... DOS and its ilk. ... The problem with FASM's performance and the "DOS limitation" has ... Tomasz would use scasd instructions ...
    (alt.lang.asm)
  • RE: Code Cracking in Java
    ... > byte it is required to know the opcodes of JVM instructions. ... > the server side precalculated hash, ... > problem is to implement server side checks no doubt it will ...
    (Pen-Test)
  • RE: QPopper 4.0.x buffer overflow vulnerability
    ... Instructions can be found at http://www.networkdweebs.com/chroot.html ... > Hash: SHA1 ... >> Feedback is welcome. ...
    (Bugtraq)
  • Re: ///Re: NASM problem
    ... HLA doesn't even use FASM's ability to translate ... mnemonics into object code; HLA emits DB statements with the ... What are these instructions that FASM doesn't support? ... MASM 6 is the one that doesn't support all the x86 instructions. ...
    (alt.lang.asm)