[M3devel] more cm3cg on Raspberry Pi

[Jay K]

  A few things.  


  I'm sorry this is so hard to get working. 
  It shouldn't be. 


  > The compiler runs and things assemble with the float ABI set to "soft"  


  Can you tell from the assembly?  
  I looked very quickly and couldn't tell.  


  Ok me for me to be less lazy, please do this on the rpi:  


  void f1(float); 
  void f2(double); 
  void f3() { f1(1); f2(2); } 

  cc -c -s 1.c # or cc -c -S 1.c I can't remember 
  cat 1.s   # or cat 1.S I can't remember 



 This will help. 
 I'd like to be able to discern hardfloat from softfloat code. 
 Er, I think in ARM there is "softfloat" and "softfp".
 "softfloat" is "everything is an integer"
 "softfp" is parameter passing in integer registers but use floating
 point hardware, I don't know if it is conditional or not. 


 What is actually a big factor here is not what instructions are used, 
 but how parameters are passed. (Because, you know, let's change 
 that up every few years to add confusion and complexity...) 


  I was of the impression, in my "second try" that the  
  configuration of cm3cg made the later flags redundant. 
  Though, granted, one wouldn't expect the error in that case. 


  Also, maybe there is more configuration/flags here than nececessary? 
  i.e. what if you say "hard float" but not vfp? 
  Is that viable? 
  

  And, in any case, please show again:  
   gcc -v or gcc -V (I get confused)  
   show we can see how it was configured  

   and then I think, also, the above C code with -v or -V   
   to see what flags are passed to cc1.  


 And, and, and we should find out where your gcc was built from. 
 And possibly merge it with ours. 
 And, I agree, ours should already work, since it is FSF 4.7. 
 And, we should try building an unpatched FSF gcc 4.7 cc/cc1.
 That is, the C above, I can cross compile easily enough -- to assembly
 at least. Linking and running are more difficult, but building
 a cross gcc that only produces assembly is quite easy -- our cm3cg
 is like that. 


 Later. 


 Personally I find it ridiculous that there so many variables here. 
 Things are much better on Windows. There is usually only one calling 
 convention per architecture, and where there are multiple, one compiler 
 can produce any of them, the calling convention is encoded in the function name, 
 and any "type" can call any "type". 


 Perhaps we should entertain the idea of "native configuration".
 What if we cross compile cm3 using C, and then in m3-sys/m3cc/src/m3makefile  
 on the rpi, you remove all the switches, even -target, and let 
 it configure native? 
 What does config.guess report? 


 Can you build a native FSF gcc 4.7? 
 Can you give me ssh access? 


 - Jay




> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] more cm3cg on Raspberry Pi
> Date: Tue, 22 Oct 2013 09:47:01 -0700
> From: mika at async.caltech.edu
> 
> 
> One more thing ...
> 
> from
> 
> https://wiki.debian.org/ArmHardFloatPort/VfpComparison
> 
> "The combination of -mfpu=vfp and -mfloat-abi=hard is not available in FSF GCC 4.4, but the CodeSourcery 2009q1 compiler (and later, current release is 2010q1) supports it as does FSF GCC 4.5."
> 
> but the way cm3cg is compiled it says:
> 
> root at raspberrypi:/big/home/mika# /usr/local/cm3/bin/cm3cg -version
> Modula-3 backend (GCC) version 4.7.1 (armv6l-unknown-linux-gnueabihf)
>         compiled by GNU C version 4.6.3, GGC heuristics: --param ggc-min-expand=59 --param ggc-min-heapsize=56092
> Modula-3 backend (GCC) version 4.7.1 (armv6l-unknown-linux-gnueabihf)
>         compiled by GNU C version 4.6.3, GGC heuristics: --param ggc-min-expand=59 --param ggc-min-heapsize=56092
> options passed: 
> 
> Hmm... so it should support the combination?  But:
> 
> root at raspberrypi:/big/home/mika# /usr/local/cm3/bin/cm3cg -mfpu=vfp -mfloat-abi=hard
> cm3cg: sorry, unimplemented: -mfloat-abi=hard and VFP
> 
> Execution times (seconds)
>  TOTAL                 :   0.00             0.00             0.02                  0 kB
> 
>       Mika 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20131022/e6ef6bc8/attachment-0002.html>