It's probably been forgotten, but there is an issue with large memory model
because in this model the following is true:
sizeof(void*) != sizeof(ptrdiff_t)
See
https://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=Gcc47:20-Bit_Design#mixedmode
GCC internally has a hard-coded assumption that those two values are equal,
and it will frequently replace address operations with base-plus-index
operations, then convert them back. Such conversions are invalid when the
index has a smaller range than the address. Through grotesque hacks I
quashed many of those cases. I suspect this is another, though it could
also be an error in the machine description constraints (which theory is
supported because the code also fails under the huge model).
You can work around this by changing the declaration to the following:
uint8_t * volatile addr = (uint8_t *)0x18000L;
There are redundant stack accesses with this code, which you might be able
to get away with further trickiness.
It would be good if you'd file a ticket describing this problem. However,
it is unlikely to be worked by me any time soon.
Peter
On Fri, Feb 8, 2013 at 5:35 AM, Martin Zoller <martin.zol...@tinynode.com>wrote:
> Hi,
> I have an issue with the -Os optimization parameter in mspgcc 4.7.0
> 20120911.
> The following code writes a byte to 0x18000 (in flash > 64 KB) on an
> MSP430F5342:
>
> #include <msp430f5342.h>
> #include <stdint.h>
> #include <string.h>
>
> int main(){
> uint8_t* addr=(uint8_t*)0x18000;
> WDTCTL = WDTPW+WDTHOLD;
> FCTL3 = FWKEY + LOCKA; // Clear LOCK and LOCKA
> FCTL1 = FWKEY + ERASE; // Enable segment erase
> *addr = 0; // Dummy write, erase the
> selected segment
> while(FCTL3 & BUSY); // Wait for erase to finish
> FCTL1 = FWKEY + WRT; // Enable write
> *addr = 0x88; // WRITE
> while(FCTL3 & BUSY); // Wait for write to finish
> FCTL1 = FWKEY; // Disable writes / erases
> FCTL3 = FWKEY + LOCK + LOCKA; // Set LOCK and LOCKA
> return 0;
> }
>
> It works fine when I compile it without -Os:
> msp430-gcc -mmcu=msp430f5342 -mmemory-model=large test.c
>
> But with -Os I get:
> /tmp/ccANT1um.s: Assembler messages:
> /tmp/ccANT1um.s:18: Error: value 98304 out of range for 16-bit immediate
> /tmp/ccANT1um.s:23: Error: value 98304 out of range for 16-bit immediate
>
> To identify the offending optimization parameter, I tried using all the
> parameters that -Os is supposed to activate, as determined with msp430-gcc
> -Os -Q --help=optimizers:
>
> -falign-functions -falign-jumps -falign-labels -falign-loops
> -fbranch-count-reg -fcaller-saves -fcombine-stack-adjustments -fcommon
> -fcompare-elim -fcprop-registers -fcrossjumping -fcse-follow-jumps -fdce
> -fdefer-pop -fdelete-null-pointer-checks -fdevirtualize -fdse
> -fearly-inlining -fexpensive-optimizations -fforward-propagate -fgcse
> -fgcse-lm -fguess-branch-probability -fif-conversion -fif-conversion2
> -finline-atomics -finline-functions -finline-functions-called-once
> -finline-small-functions -fipa-cp -fipa-profile -fipa-pure-const
> -fipa-reference -fipa-sra -fivopts -fjump-tables -fmath-errno
> -fmerge-constants -fmove-loop-invariants -fomit-frame-pointer
> -foptimize-register-move -foptimize-sibling-calls -fpeephole -fpeephole2
> -freg-struct-return -fregmove -frename-registers -freorder-blocks
> -freorder-functions -frerun-cse-after-loop -fsched-critical-path-**heuristic
> -fsched-dep-count-heuristic -fsched-group-heuristic -fsched-interblock
> -fsched-last-insn-heuristic -fsched-rank-heuristic -fsched-spec
> -fsched-spec-insn-heuristic -fsched-stalled-insns-dep -fshort-enums
> -fshrink-wrap -fsigned-zeros -fsplit-ivs-in-unroller -fsplit-wide-types
> -fstrict-aliasing -fthread-jumps -ftoplevel-reorder -ftrapping-math
> -ftree-bit-ccp -ftree-builtin-call-dce -ftree-ccp -ftree-ch
> -ftree-copy-prop -ftree-copyrename -ftree-cselim -ftree-dce
> -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre
> -ftree-loop-if-convert -ftree-loop-im -ftree-loop-ivcanon
> -ftree-loop-optimize -ftree-phiprop -ftree-pre -ftree-pta -ftree-reassoc
> -ftree-scev-cprop -ftree-sink -ftree-slp-vectorize -ftree-sra
> -ftree-switch-conversion -ftree-tail-merge -ftree-ter
> -ftree-vect-loop-version -ftree-vrp -funit-at-a-time -fweb
>
> But with these parameters the code compiles.
> Unfortunately the executables get much bigger with these parameters than
> with -Os, so using them as a workaround is not an option.
>
> Any ideas on what might cause this problem?
>
>
> Martin
> --
>
> Martin Zoller ? Tinynode <http://www.tinynode.com/> ? System Architect ?
> Lausanne ? D: +41 21 510 11 81 ? F: +41 21 510 11 71 ?
> martin.zol...@tinynode.com
> <mailto:martin.zoller@**tinynode.com<martin.zol...@tinynode.com>
> >
>
> New postal address from 12/15/2012: Tinynode SA, Boulevard de Grancy 19A,
> 1006 Lausanne
>
>
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
>
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
