Re: [avr-llvm-devel] Load / Store

[Weddington, E. <Eri...@at...>]

 

> -----Original Message-----
> From: John Myers [mailto:ato...@gm...] 
> Sent: Tuesday, November 09, 2010 5:36 PM
> To: Kevin Schoedel
> Cc: avr...@li...
> Subject: Re: [avr-llvm-devel] Load / Store
> 
> 
> 
> 
> This could be taken care of with generic pointers similar to 
> the ones 8052 compilers like Keil and SDCC have.
> It wouldn't be pretty or very efficient but nether would it 
> be fatal. When users require more efficiency they explicitly 
> qualify the pointer parameter which would then only allow 
> them to use the specific type qualified object as an 
> argument. Also, this problem would happen even with 
> explicitly qualified types. So without a generic pointer the 
> compiler would throw an error either way.
> 
> 
> 
> 
> 	>However how
> 	>should we treate inline strings like printf("hello")? 
> place them in ROM by
> 	>default? because declaring a ptr for each string 
> similar to what gcc does
> 	>is a bit insane.
> 	
> 	
> 	In principle, you could have an optimization pass that 
> would, for instance,
> 	replace __builtin_printf(const char *, ...) with 
> __builtin_printf(__flash
> 	const char *, ...) while placing the format string in 
> ROM. To do much more
> 	than that, for C, sounds to me like a large research project.
> 	
> 

In all reality, wouldn't avr-llvm have to work with avr-libc as it's standard C library? If so, then we need to keep that in mind when working on avr-llvm. Using avr-libc would be the path of least resistance to gain users over to avr-llvm. If it works just like GCC, but with some improvements (namely better optimizations), then it will be easy for users to convert. I'd rather keep things as simple as possible, at least at first.