Ok I find it: http://documentation.renesas.com/eng/products/mpumcu/rej09b0318_sh_4sm.pdf page 172
On Thu, Oct 14, 2010 at 7:43 PM, Vincent Labie <vincent.labi...@gmail.com>wrote: > > > On Thu, Oct 14, 2010 at 4:37 PM, Andy Polyakov <ap...@openssl.org> wrote: > >> > 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. >> >> => for sure mov #imm,Rn is EX, so is the mova ins, the only MT ins is the > mov Rm,Rn. > I will find a pointer. > > >> > 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 take a look, but it is a real pain on this CPU, and I think it is no > use since gcc will probably never be fixed for the very same reason. > > > 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. >> > > => in fact only the 300 series have a symetric pipe. > > ______________________________________________________________________ >> > OpenSSL Project http://www.openssl.org >> Development Mailing List openssl-dev@openssl.org >> Automated List Manager majord...@openssl.org >> > >
