> 2. Why do you use tables of small constants? There is 'mov #imm,Rn' > instruction, where #imm is 8-bit signed value. Works for all [Ss]igma > constants. As for mask_ff. There is extu.b that does &0xff... > > This is very important for the sh4 serie 200 pipeline: there is only one > ALU pipe, so you have to use load/store for optimization.
Is 'mov #imm,Rn' ALU instruction? Not according to "SH-4A Software Manual", rev. 1.50, where it's marked MT, i.e. pairable with *anything* and capable of executing on either pipe. > I will take a deeper look on the extx ins usage. > > 3. Position independence is still problem. > > > - In SH4 asm, the MOVA is hidden behind a normal mov.l without a base > > register, so in fact, it is used very often. > > Can't confirm this. Well, I can see now that it extensively uses 'mov.l > @(disp,PC),Rn' for loading constants, but no mova... I.e. following is > position-independent: > > mov.l label,rx > > label: > .long xxxx > > Only[!] as long as xxxx is *not* another label, in which case a > relocation record is generated voiding position independence. > > > => I know, nevertheless, if you compile code on SH4 with gcc with -PIC, > then the same apply, so currently, I don't see the point to make real > PIC code on this CPU. Are you afraid of doing better job than compiler? :-):-):-) I mean if it's the case, obviously one can argue that lack of proper PIC support in gcc is a bug. And if it's a bug, then chances are that it will be fixed at some point. Why would we have to wait and struggle adapting assembler later (when we've forgotten all about it), if we can do proper job writing PIC code *now* and ensure it works for all eternity? As mentioned in the beginning, assembler programming is exhausting experience and there is no excuse for not doing absolute best from the start. Because fixing it can be as exhausting, i.e. on the edge to prohibitive. In other words, it's *not* an excuse for not doing it, especially when we see that position independence doesn't cost much extra (if anything at all). > I will study some more anyway on that. > Note: the mova ins is a ALU ins for this CPU. Is this specific for 200 series? Got a reference? Thing is that above mentioned manual lists 'mova' as LS instruction, i.e. non-ALU. But even if it is, why is it a problem, when you have to use it only *once* per subroutine invocation? A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
