> > if the dwords procedure isn't called, it's not > compiled. > > That's true. But the print library core is a procedure > capable of > handling dwords. If you use two different decimal routines > (e.g. byte > and sword), this is efficient. If you use only one, the > design is > inefficient.
Ok, it's been a while since I had a look at the print.jal code. I found it very readable, the only thing I remember that did not fully meet my taste were lots of divisions. > As to my previous statement: the bottom line is jallib > (like many > libraries) aim to be universal and that comes at a price, > which in > most cases is code size. There is no point in just > criticize code > size. You one thinks code size (or stack usage) could be > reduced > without reducing functionality, please, please, show how. Well, sometimes it is possible. You could replace the print.jal-procedures with procedures of the "looped subtraction"-type I sketched in this thread. You would win in code size and execution time, probably even in RAM usage. But the cost would be to change a beautifully readable code into an awful mud of strange loops. Adding the "remove leading zeroes" function would make things worse. The "limit to (n) digits" would turn it into an unreadable mess. Let's leave such efficient but ugly constructs to the user who really needs it. 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.
