On Thu, Oct 14, 2010 at 4:37 PM, Andy Polyakov <[email protected]> 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 [email protected] > Automated List Manager [email protected] >
