home *** CD-ROM | disk | FTP | other *** search
/ Acorn User: China / Acorn User China CD-ROM (UK) (Disc B) / Acorn User China CD-ROM (UK) (Disc B).bin / BARNET / ARMLINUX / MAIL / 9801 / text0025.txt < prev    next >
Encoding:
Text File  |  1998-01-31  |  1.4 KB  |  41 lines
  1. >> EG, to access bytes
  2. >>  12 and 13 only of a structure, GCC will use by default:
  3. >>    ldr r0, [r1, #14]
  4. >>    mov r0, r0, lsr #16
  5. > 
  6. > >Does anyone know if this is a legal optimisation that the compiler is making?
  7. > 
  8. > The consensus among the gcc people is that it is, because the ARM ABI is 
  9. > allowed to define a minimum alignment (and has done so, to 32).  The 
  10. > optimisation does produce noticeably better code in the vast majority of cases.
  11. > 
  12. > A way to signal to gcc that a structure is unaligned in this way is on the 
  13. > cards in the future, but we don't have it yet.  In the short term we need to 
  14. > find a workaround such as using -mshort-load-bytes on the offending source 
  15. > files, or fixing them to use explicit byte ops.
  16.  
  17. Can I ask for a specific example here?  Are we talking about something along
  18. the lines of:
  19.  
  20. struct foo
  21. {
  22.   int a;
  23.   short b;
  24.   short c;
  25.   char d;
  26.   short e;
  27.   short f;
  28. }
  29.  
  30. ie which of these will be wrongly accessed?  And what alignment will GCC
  31. give them?
  32.  
  33. I don't think that -mshort-load-bytes is the correct way to differentiate
  34. the two cases, I think -munaligned-loads versus -mno-unaligned-loads is the
  35. correct name for the switch - simply because I don't think shorts should
  36. be loaded as bytes!  It's /at least/ as efficient to load them as words
  37. and then shift them twice as it is to load as bytes and orr them together.
  38.  
  39. unsubscribe: body of `unsubscribe linux-arm' to majordomo@vger.rutgers.edu
  40.  
  41.