> > 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.
