> it's not a bad idea on first glance. And indeed the easiest solution > apart from always doing everything far. > > But ... > > 20 bit pointers are non-standard. They fit into an X-register (other > than SR!), but require 32 bit if pushed on stack or stored to memory. > But when read from memory, they require only one register isntead of 2 > for 'normal' 32 bit values.
I meant making it 32 bits where needed and 20 bits where possible (in the special registers), but not 16 unless the programmer indicates that that's what he wants. That way, the whole address space is transparantly available. > Always treating them as 32 bit wastes memory and performance but would > eliminate possible problems (the programmer cannot make anything wrong > and the compiler can handle the cases where a 32 bit value is > used for addressing). Unfortunately it would massively increase the > register space requirements wherever pointers are used or passed. > Making 20 bit the default will however cause problems when it comes to > pointer arithmetics (other than the compiler-created one). The > programmer will often never notice what's going wrong without a > debugger (and we > know about the debugging problems with the X devices) I guess I'm more of the "first make it work, then make it fast" school but that may not be appropriate for a compiler writer. I'd make everything 32 bits, CALLA and RETA everywhere, with the -mdata-64k and -mcode-64k options to use 16 bit pointers if you want to save the overhead. Sure, 32-bit pointers waste memory, but the new devices come with more RAM, and now it effectively wastes lots of flash because you can't use it easily. > Unfortunately it would massively increase the > register space requirements wherever pointers are used or passed. That's a good point and I have no insight in what impact that would have. > So manually and intentionally activating the X features for variables, > pointers and functions by declaring them FAR (and using 16 bit if not) > is the most transparent way (for the programmer) to handle things. By > adding the FAR qualifier, the programmer has actively declared it non- > conforming to the 'normal' 16/32 bit world. And the compiler can issue > warnings due to type-checking and some simple rules. Everything else is > up to the programmer. I'd rather have the compiler do the work :P At least in the default configuration, with a manual fallback for when you need to squeeze the last bit of performance out. > I'd say there is no 'perfect' solution to this dilemma. The question is > what would be the optimum. > In any case, the chosen path and its inner workings should be _very_ > well documented. Indeed. > p.s.: actually I don't use nor require any of the X functions right > now. The lower 64k is enough for all of my projects right now. I use > the 54xx mainly because of its hardware modules and the huge RAM size. > And with > the current stte of the compiler, my first use of the FARTEXT would be > placing some constant tables and the init data for the variables there. Ah, conversely, I'm most interested in the extra flash for code. Our application is outgrowning the 1611 and the 2418 only has 52 KB if you can't use FARTEXT, so that's 4 KB extra flash while losing 2KB of RAM. I don't look forward to slapping FAR on hundreds of functions, I just want the linker to toss one half up there and one half down here. Take care, Michiel > ----- Ursprüngliche Nachricht ----- > Von: Michiel Konstapel > An: [email protected] > Gesendet am: 02 Feb 2010 13:09:26 > Betreff: Re: [Mspgcc-users] suggestion: MSP430X far address warning > > > It all depends on your project, and putting everything into 20 bit is > > the worst solution of all. Albeit the easiest. > > I must say that, as a default, the easiest actually sounds best to me. > How about doing it the other way around, using NEAR to mark those > critical bits where you want the extra speed 16 bit points will give > you, but by default, everything is compiled so that it can be linked > anywhere and will Just Work (TM)? > Michiel
