This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro


On Fri, 6 Feb 2015, Mike Stump wrote:

> Personally, the call form of bal in my book should be called call, and 
> the non-call form of it should be called bal, but, I realize it is 
> likely to late to do much about now.  If one went down this path, then 
> even changing it away from bal is wrong.  That’s the basis of why I 
> fired up the first email.  Maybe more a lament at this point.

 I'm confused, these all are conditional short-distance calls.  And I 
suspect that they were included in the original MIPS architecture for the 
very purpose of letting relocatable code find its own position in memory 
at the run time -- and the rest was added to maximise the benefit of the 
opcode(s) that had to be there anyway.

 And it's just, owing to how the architecture has been structured, that 
there are exactly two cases (of the 64 encodings available) where the 
condition is fixed to either `true' or `false', respectively.  And if 
anyhow, I'd call any assembly-language idiom of `BLTZAL $0, foo' just 
`MOVE $31, $pc' or maybe to avoid confusion `[D]ADDIU $31, $pc, 8'.

 Note that `foo' is never used in that operation (and that the MIPS16 and 
microMIPS, and now also r6 instruction sets actually have such direct 
operations that have a wider range of immediates available; although care 
has to be taken about them as they may have unusual alignment or other 
restrictions).

  Maciej


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]