----- Ursprüngliche Nachricht -----
Von: Michiel Konstapel
An: [email protected]
Gesendet am: 03 Feb 2010 10:10:05
Betreff: Re: [Mspgcc-users] suggestion: MSP430X far address warning
>> 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.
Yes, the address space is, but if this is the default case, then all problems
arising with a mixed 20/32 bit handling are also transparently (and ivisibly)
available. That's my concern.
With a pure 32 bit solution, there are no problems, other that it is highly
ineffective. So it could be made default, but it is not desirable.
With the 20/32 solution, the programm has to know this and its implications.
Consider that when the compiler is done, many users will just use it without
knowledge of the inner workings. They just write C code and think that all will
be the way it is meant to be.
And if things go wrong, many of them don't know about assembly language at all
and are unable to detect WHAT's going wrong in the compiler generated code.
If they are required to use a FAR qualifier then they at least KNOW that
there's something special going on.
> 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.
My experience (25 years of programming on various systems) is that once things
work, they'll most certainly never straightend out.
Nothing lives longer than a temporary solution.
Look at things like the SMTP protocol (which was never meant to be used outside
a small local network) or the IPV4 specification, which is known to be utterly
outdated for at least 15 years and still there is no end
despite of better solutions.
So if you ever want to have it made right, make it right right from the start.
>> 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.
If passed as parameter, it had to be passed on two registers as 32 bit (long).
And for using it as memory pointer, the compiler had to use a third register
for the 20bit usage, as the original 32 bit value needs to be
kept. (except the cmpiler is really smart enough to know that the additional 12
bits are never used again).. The programmer would be surprised when 12 bits of
his long value keep disappearing.
(well, it would be possible to add the upper 4 bit to the lower word register
and use it for referencing, but this requires an awful lot of intelligence on
the compiler side)
>> 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.
And I don't like default setting swhich are not 100% transparent. If I have to
activate an option or add qualifiers or attributes to make sure things work the
way I'd expect following the way they work on most other
machines (left out the PICs with their hardware stack and 12 to 14 bit
instruction words), then I'd consider this a really bad thing.
It's like a car where you need to put your foot on the gas pedal to make it
_not_ move :)
>> 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.
Hey, something we finally agree :) Unfortunately, documentation often is an
orphan in non-commercial projects.
>> 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.
We're also replacing the 1611, but mostly because of its limited I/O (I have to
multiplex SPI and I2C on one USART right now) and the lower speed. (nor 16
instead of 8 MHz). What I'll miss is the D/A module. But the
lower price of the device compensates this.
What about a pragma to put the whole compilation unit into FAR or near, unless
explicitely changed (switch the default)?
I also really miss the optimize pragma in GCC3.2.3. You cannot turn off
optimisation for a single function or compilation unit. You can only do so from
the command line. And then it usually affects the whole project
(unless you make your makefile really complex - and this won't be propagated to
different projects includign the same code module).
So just a compiler option won't do the trick, as it is source related but not
in the source file and not applicable to individual files.
JMGross
