This is the mail archive of the crossgcc@cygnus.com mailing list for the crossgcc project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
[Followups please remove the cross-post unless it's relevant to both] I have been looking thru lb1sf68.asm and noticed that its code isn't the best - especially for the CF. Generally, the CF adaption has been done on an instruction-by-instruction basis (and the original code wasn't that brilliant), without taking into account areas where the CF is good. One area in particular in __adddf3 is the fraction shifting. This was originally done a bit at a time using roxrl instructions. (Whilst this approach isn't great, given the 68000's shift speed, it's not too bad). The CF port has just expanded the roxrl to lslr;btst;beq;bset, which is appalling. Given the CF's barrel-shifter, a non-iterative shift-and-mask approach is virtually always faster. Also, whoever originally wrote the code avoids doing arithmetic on the address registers - exchanging them back into data registers. Whilst 68000 address arithmetic is slower than (word-length) data arithmetic, I think that the exg instructions outweigh these gains (particularly on the CF, where exg is 3 instructions). Finally, __mulsi3 appears to be wrong - it performs an unsigned multiply instead of a signed multiply. Luckily, this function shouldn't be used on the CF (the machine description generates inline mulsl instructions). [I haven't written a bug report on this yet]. Is anyone else looking at this? Peter -- Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5247