> > It *Should* be based on this
> Could you explain why it *should* be using inline
> assembler?

I can explain part of the changes: The original format.jal uses divisions of 
large variables by numbers that are not constant powers of two. Those divisions 
take quite some code space and a real lot of processor cycles.

Those divisions can be omitted however in JAL without using assembler by using 
alternative algorithms for decimal conversion. Bit rotations using the carry 
bit for transfering bits from one byte to another can not easily be done in 
JAL, so there have to be more complicated instructions to be used, or 
assembler. Another thing that's not-so-easyly accessible in JAL is the carry 
bit, to find out if a subtraction in unsigned values did overflow (underflow, 
that is...). 

We've had an algorithm posted on this list some time ago that would do a 
conversion in 18 instruction cycles for which the current format.jal needs 
several hundred. There is definitely room for improvement in this lib.

Greets,
Kiste

-- 
You received this message because you are subscribed to the Google Groups 
"jallib" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/jallib?hl=en.

Reply via email to