Re: [Mspgcc-users] TI compiler

[Przemek Klosowski]

On Fri, Mar 24, 2017 at 10:43 AM, Grant Edwards
 wrote:

> I predict it will get worse and worse until it gets forked and
> somebody else fixes it.
I thought someone suggested that the interrupt routine saves too many
registers because it ends up calling a runtime function because one of
the variables has a wrong type (or rather, type that is not optimal
for this case).

Bob, did you check whether changing the declared type avoids calling
the runtime, and avoids excessive register saving/restoring?

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[Bob von Knobloch]

On 23/03/17 15:10, David W. Schultz wrote:
> The family guides have complete descriptions. In this case slau144.

Thanks David, I seem to have missed that, it is indeed a proper description.
Thanks for all the help. The TI compiler is still no good - the 
interrupts are still taking much longer that the old compiler and the 
code size is still much bigger.
The enhancements that I wanted to do to the target can, seemingly, only 
be achieved with the old compiler at this time.
I'll give up on the TI one and keep looking in case it improves.

Cheers,

Bob

-- 
The Sun is out, the sky is blue, it's time to drive the MR2.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[David W. Schultz]

On 03/23/2017 06:13 AM, Bob von Knobloch wrote:
> Do you know where there is proper documentation of their instruction 
> set? What I have from TI is scant, to say the least.

The family guides have complete descriptions. In this case slau144.


-- 
David W. Schultz
http://home.earthlink.net/~david.schultz
"Life without stock is barely worth living..." - Anthony Bourdain

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[Bob von Knobloch]

On 23/03/17 11:45, David W. Schultz wrote:
> While you didn't explicitly call a function in your interrupt routine,
> the compiler did for the right shift of TXByte.

Which the 'old' compiler doesn't.

And your complaint to TI of April 2015 appears to have been ignored.

> Making TXByte a signed int makes this go away. (The MSP430 doesn't have
> a single instruction to do the unsigned right shift.) You don't need for
> it to be unsigned because you don't care about those bits.

In this case, true, but irritating.

> A minor nit:
>
> Making TXByte and BitCnt volatile buys you nothing except slower code.

Yes, I forgot to remove this. It was just an attempt to try to influence 
the compiler.

Is there any way of inputting this to TI?

and

Do you know where there is proper documentation of their instruction 
set? What I have from TI is scant, to say the least.

Thanks,

Bob


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[David W. Schultz]

While you didn't explicitly call a function in your interrupt routine,
the compiler did for the right shift of TXByte.

Making TXByte a signed int makes this go away. (The MSP430 doesn't have
a single instruction to do the unsigned right shift.) You don't need for
it to be unsigned because you don't care about those bits.



A minor nit:

Making TXByte and BitCnt volatile buys you nothing except slower code.

Their values can't change while the interrupt is being serviced so it
doesn't help there. They also can't change while you aren't looking in
put_char() because it waits for the timer to finish.

-- 
David W. Schultz
http://home.earthlink.net/~david.schultz
"Life without stock is barely worth living..." - Anthony Bourdain

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[Bob von Knobloch]

OK,
here is some code that shows the problem.
I use OpenSUSE LEAP 42.1 as the operating system and have both compilers 
installed in /opt under 2 different names ("msp430-elf-gcc" for the TI 
and "msp-gcc" for the 'old' P.A.Bigot compiler).
Hope it's not too much, I've tried to keep it as small as reasonable 
without hiding anything.

The source:

/*
 
**
 
**
Compiler test: msp430-elf-gcc
Includes and Interrupt definition syntax different for 'old' mspgcc
Otherwise identical
 
**
 
**
  */

#include
#include

/*
 
**
  Programmer information *** DO NOT USE IFDEFS *** (AWK'ed by avrprog etc)
  OK to comment out with '//'
 
**
  */

#define MCU_TARGET  msp430g2232

#define LED BIT0// LED on P1.0
#define TXD BIT1// TXD on P1.1
#define RXD BIT2// RXD on P1.2
#define Bit_time104 // 9600 Baud, 
SMCLK=1MHz (1MHz/9600)=104
#define Bit_time_5  52  // Time for 
half a bit.

volatileuint16_tBitCnt; // Bit count, 
used when transmitting byte
volatileuint16_tTXByte; // Value sent 
over UART when 
put_char() is called
uint16_tresult, status, checksum;

/*
 
**
Write a character to RS232
 
**
  */

static  void put_char(uint8_t databyte)
{
 TXByte = databyte;
 TXByte |= 0x100;   // Add stop bit 
(= 1)
 TXByte <<= 1;  // Add start 
bit (= 0)
 BitCnt = 10;   // Load Bit 
counter, 8 bits + start + stop

 P1OUT |= TXD;
 TACTL = TASSEL_2 + MC_2;   // SMCLK, 
continuous mode
 TACCR0 = TAR;  // Initialize 
compare register
 TACCR0 += Bit_time;// Set 
time of first bit
 TACCTL0 =  CCIE;   // Enable 
interrupts
 while (TACCTL0 & CCIE ) {};// Wait 
for TX completion (by the 
interrupt)
}

/*
 
**
Main
 
**
  */

void main(void)
{
 WDTCTL = WDTPW | WDTHOLD;  // Stop WDT

 BCSCTL1 = CALBC1_1MHZ; // Set range
 DCOCTL = CALDCO_1MHZ;  // SMCLK = DCO 
= 1MHz

 P1DIR |= TXD | LED;

 _NOP();
 _EINT();   // interrupts 
enabled

 while(1)
 {
put_char('+');
 }
}
/*
 
**
  Timer A0 interrupt service routine (RS-232 9600 Baud Tx).
  Handles Tx bit timing.
 
**
  */

void __attribute__ ((interrupt (TIMER0_A0_VECTOR))) TIMER0_A0_ISR(void)
{
 P1OUT &= ~LED; // Turn LED on 
(start of interrupt)
 TACCR0 += Bit_time;// Add 
Offset to TACCR0
 if (BitCnt == 0)   // If all bits 
TXed
 {
TACTL = TASSEL_2;   // SMCLK 
selected, timer off (for power 
consumption)
TACCTL0 &= ~CCIE ;  // Disable 
interrupt
 }
 else
 {
if (TXByte & 0x01)
P1OUT |= TXD;
else
P1OUT &= ~TXD;

TXByte >>= 1;
BitCnt--;
 }
 P1OUT |= LED;  // Turn LED on 
(end of interrupt)
}


The compile command for msp430-elf-gcc (taken from running my 'make').

msp430-elf-gcc -I/opt/msp430-gcc/include/ -O2 -Wall -g -mmcu=msp430g2232 
  -Wno-main 

Re: [Mspgcc-users] TI compiler

[DJ Delorie]

Could you post your interrupt code (C) and the resulting assembler?
It's hard to debug problems without seeing those...

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[David W. Schultz]

On 03/22/2017 10:43 AM, Bob von Knobloch wrote:
> On 22/03/17 16:24, David W. Schultz wrote:
>> Calling another function from the ISR was what triggers this bad
>> behaviour. Especially if the called function is in another file.
> Hi David,
> my code doesn't call a function in the interrupt, it merely decrements a 
> count, tests it for zero and, if not, sets a port bit hi or low, then 
> exits. This uses only R13 which is why I'm surprised that all the others 
> are 'push-pulled'. Your description also depicts not the best behaviour.
> 
> Bob
> 

I just took a look at some generated code for a simple timer interrupt
and it only saves 5 registers. Just what it used and nothing else.

Compiler version is: msp430-elf-gcc (SOMNIUM Technologies Limited -
msp430-gcc 5.3.0.219) 5.3.0

Not quite the latest.

-- 
David W. Schultz
http://home.earthlink.net/~david.schultz
"Life without stock is barely worth living..." - Anthony Bourdain

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[Bob von Knobloch]

On 22/03/17 16:24, David W. Schultz wrote:
> Calling another function from the ISR was what triggers this bad
> behaviour. Especially if the called function is in another file.
Hi David,
my code doesn't call a function in the interrupt, it merely decrements a 
count, tests it for zero and, if not, sets a port bit hi or low, then 
exits. This uses only R13 which is why I'm surprised that all the others 
are 'push-pulled'. Your description also depicts not the best behaviour.

Bob

-- 
The Sun is out, the sky is blue, it's time to drive the MR2.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[David W. Schultz]

On 03/22/2017 09:54 AM, Bob von Knobloch wrote:
> Inspecting the assembly, I found that the interrupt was suspect.
> The 'old' code pushed the registers that it needed, the 'new' TI 
> compiler pushes (and, of course, later pulls) all of the registers from 
> r4 - r15 inclusive.

I complained about the failure to follow the EABI (which registers a
called function is required to preserve) to the TI forums some time ago.
(April 2015)

Apparently it still isn't fixed.

Calling another function from the ISR was what triggers this bad
behaviour. Especially if the called function is in another file.

-- 
David W. Schultz
http://home.earthlink.net/~david.schultz
"Life without stock is barely worth living..." - Anthony Bourdain

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[Bob von Knobloch]

On 06/03/17 21:53, David W. Schultz wrote:
> On 03/06/2017 02:19 PM, Bob von Knobloch wrote:
>> Hi David,
>> How have you extracted these from the .elf file?
>
> I didn't. You were talking about the .hex file so that is where I looked.
>
> The ISRs start out like this:
>
> __attribute__((wakeup, interrupt(USCI_A1_VECTOR))) void rxISR(void)
>

OK - I have it now,
You put me on the right track David.

I have been used to creating the hex file with "objcopy", in a make 
file. For my AVR projects, this copied .text, .data, & .vectors into the 
HEX output.

It seems this is unnecessary with msp430-elf-gcc and a simple "objcopy" 
from "main.elf" to "main.hex" with no section options does the job, also 
including the used ISRs and reset vectors.

Many thanks,
Bob
-- 
The Sun is out, the sky is blue, it's time to drive the MR2.

--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[Bob von Knobloch]

On 06/03/17 21:53, David W. Schultz wrote:
> On 03/06/2017 02:19 PM, Bob von Knobloch wrote:
>> Hi David,
>> How have you extracted these from the .elf file?
>
> I didn't. You were talking about the .hex file so that is where I looked.
>
> The ISRs start out like this:
>
> __attribute__((wakeup, interrupt(USCI_A1_VECTOR))) void rxISR(void)
>
Thanks David,
I have 2 ISRs in my file. Their .text parts appear in the output, but 
the appropriate vector entries are missing.
The compiler does not make a hex file. This is done by objcopy. 
Somewhere in your compile command (Makefile?), there is a stanza like 
"msp430-elf-objcopy -j text -t data -j vectors -O ihex" or similar.
This places the vectors in the hex file (or, in my case, it doesn't).
If you can find this, I would appreciate a look at it.
Regards,
Bob

-- 
The Sun is out, the sky is blue, it's time to drive the MR2.

--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[David W. Schultz]

On 03/06/2017 02:19 PM, Bob von Knobloch wrote:
> Hi David,
> How have you extracted these from the .elf file?

I didn't. You were talking about the .hex file so that is where I looked.

The ISRs start out like this:

__attribute__((wakeup, interrupt(USCI_A1_VECTOR))) void rxISR(void)

-- 
David W. Schultz
http://home.earthlink.net/~david.schultz
"Life without stock is barely worth living..." - Anthony Bourdain

--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[Bob von Knobloch]

On 06/03/17 18:09, David W. Schultz wrote:
> On 03/06/2017 10:25 AM, Bob von Knobloch wrote:
>> Now I have to find out where the vectors have gone - they are missing
>> from the .hex file. Maybe a different name from the old mspgcc?
>>
>
> TI moved a lot of things into the linker scripts a while back. Each
> vector now gets its own section and as near as I can tell, these will
> not appear in the output unless you have an actual ISR defined.
>
> I have three interrupt service routines in the program I am using as an
> example and the hex file includes this:
>
> :02FFE6001259AE
> :02FFEA00A883EA
> :02FFF400EE55C8
> :02FFFE006A5245
>
> I count three interrupt vectors plus reset.
>

Hi David,
How have you extracted these from the .elf file?
I have no vectors, not even reset (and there are 2 ISRs defined):
Regards,
Bob

-- 
The Sun is out, the sky is blue, it's time to drive the MR2.

--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[Bob von Knobloch]

On 06/03/17 17:52, DJ Delorie wrote:
>
> Bob von Knobloch  writes:
>> Now the linker doesn't want to play with me - it cannot find the
>> "msp430g2231.ld" link file. Curious because the compiler fids "msp430.h"
>> in the same directory.
>
> Add "-v" to your gcc line, it will show you more info on where it's
> searching for things.  Note that the linker and the preprocessor use
> different search paths; the path to the linker script may come from gcc
> (via -L or an absolute path) or from the linker's built-in path.
>
> You can also use "strace -f -o /tmp/foo gcc . . ." to capture all the
> places it searches for files (grep for msp430g2231 in that file), which
> might help.
>
Thanks DJ,
the -v flag is very useful. I solved this problem by moving the -ld scripts.
Now I must find the vectors which do not appear in my hex file.

Regards,
Bob

-- 
The Sun is out, the sky is blue, it's time to drive the MR2.

--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[David W. Schultz]

On 03/06/2017 10:25 AM, Bob von Knobloch wrote:
> Now I have to find out where the vectors have gone - they are missing 
> from the .hex file. Maybe a different name from the old mspgcc?
> 

TI moved a lot of things into the linker scripts a while back. Each
vector now gets its own section and as near as I can tell, these will
not appear in the output unless you have an actual ISR defined.

I have three interrupt service routines in the program I am using as an
example and the hex file includes this:

:02FFE6001259AE
:02FFEA00A883EA
:02FFF400EE55C8
:02FFFE006A5245

I count three interrupt vectors plus reset.

-- 
David W. Schultz
http://home.earthlink.net/~david.schultz
"Life without stock is barely worth living..." - Anthony Bourdain

--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[DJ Delorie]

Bob von Knobloch  writes:
> Now the linker doesn't want to play with me - it cannot find the 
> "msp430g2231.ld" link file. Curious because the compiler fids "msp430.h" 
> in the same directory.

Add "-v" to your gcc line, it will show you more info on where it's
searching for things.  Note that the linker and the preprocessor use
different search paths; the path to the linker script may come from gcc
(via -L or an absolute path) or from the linker's built-in path.

You can also use "strace -f -o /tmp/foo gcc . . ." to capture all the
places it searches for files (grep for msp430g2231 in that file), which
might help.

--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[Bob von Knobloch]

On 06/03/17 16:58, Ben Green wrote:

>>From my understanding the .h files and the .ld files are not supposed to be 
>>in the same directory. When in installed msp430-gcc-support-files-1.198.zip I 
>>did this:

Curious, as the TI installer places them there (under 
/opt/msp430-gcc/include)

> cp *.ld /opt/msp430-elf-6.2.1.16/msp430-elf/lib/430/
> cp *.h /opt/msp430-elf-6.2.1.16/msp430-elf/include/

Makes sense - I'll try that.

> Now that does seem strange, I would have expected that to work, did you make 
> sure you were passing the argument to the linker and not GCC (though that 
> might not make any difference)... how about using the -L switch?
>
> -L /opt/msp430-elf-6.2.1.16/msp430-elf/lib/430 -T msp430g2231.ld

Yes, tried that too.

> Benjamin.

Yes, splitting the two worked, (I wonder why they installed into the 
same place?) thank you Ben.


 From David Schultz,

 > I include -Wl,-L$(SUPPORT_FILE_DIRECTORY) in the flags for gcc when
 > linking.

I had tried this, but no joy.

Now I have to find out where the vectors have gone - they are missing 
from the .hex file. Maybe a different name from the old mspgcc?

Cheers,

Bob

-- 
The Sun is out, the sky is blue, it's time to drive the MR2.

--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[David W. Schultz]

On 03/06/2017 09:42 AM, Bob von Knobloch wrote:
> Now the linker doesn't want to play with me - it cannot find the 
> "msp430g2231.ld" link file. Curious because the compiler fids "msp430.h" 
> in the same directory.

I include -Wl,-L$(SUPPORT_FILE_DIRECTORY) in the flags for gcc when
linking.

SUPPORT_FILE_DIRECTORY having previously been set to /usr/ti/gcc/include


-- 
David W. Schultz
http://home.earthlink.net/~david.schultz
"Life without stock is barely worth living..." - Anthony Bourdain

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[Ben Green]

> Now the linker doesn't want to play with me - it cannot find the
> "msp430g2231.ld" link file. Curious because the compiler fids "msp430.h"
> in the same directory.

>From my understanding the .h files and the .ld files are not supposed to be in 
>the same directory. When in installed msp430-gcc-support-files-1.198.zip I did 
>this:

cp *.ld /opt/msp430-elf-6.2.1.16/msp430-elf/lib/430/
cp *.h /opt/msp430-elf-6.2.1.16/msp430-elf/include/

> It looks like the dir info is not being passed to the linker.
> I have tried forcing it with -T, but no joy.
> I have my compiler installed at /opt/msp430-gcc/ (I don't want to
> clutter /usr/local/bin) and wonder if a hard coded path has been set
> somewhere?

Now that does seem strange, I would have expected that to work, did you make 
sure you were passing the argument to the linker and not GCC (though that might 
not make any difference)... how about using the -L switch?

-L /opt/msp430-elf-6.2.1.16/msp430-elf/lib/430 -T msp430g2231.ld

Good luck,

Benjamin.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[Bob von Knobloch]

On 03/03/17 19:30, DJ Delorie wrote:
> Also, you can use "msp430-elf-gcc -mintr ..." to minimize the runtime
> support.
Thanks DJ,

I tried -mintr and at least one project produces code that could fit, 
thanks (should have RTFM - but finding this was not intuitive).

Now the linker doesn't want to play with me - it cannot find the 
"msp430g2231.ld" link file. Curious because the compiler fids "msp430.h" 
in the same directory.

It looks like the dir info is not being passed to the linker.
I have tried forcing it with -T, but no joy.
I have my compiler installed at /opt/msp430-gcc/ (I don't want to 
clutter /usr/local/bin) and wonder if a hard coded path has been set 
somewhere?

I am running on OpenSUSE42.1 (which is 64-bit).
I have tried compiling from source and also installing TI's installer - 
the results are the same.
Any one have any ideas ?

Regards,

Bob

-- 
The Sun is out, the sky is blue, it's time to drive the MR2.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[Orlando Arias]

Ugh... Really sorry, hit reply instead of reply list.

Greetings,

Apologies for hijacking this e-mail chain, but I have had issues with
the ``bloat'' in newlib as well. My issue is with internationalization
support in newlib. I have configured and compiled newlib with the
following flags:

  export CFLAGS_FOR_TARGET="-Os -g -ffunction-sections -fdata-sections"
  ../configure \
--prefix=/usr \
--target=msp430-elf \
--disable-newlib-supplied-syscalls \
--enable-newlib-reent-small \
--disable-newlib-fseek-optimization \
--disable-newlib-wide-orient \
--enable-newlib-nano-formatted-io \
--disable-newlib-io-float \
--enable-newlib-nano-malloc \
--disable-newlib-unbuf-stream-opt \
--enable-lite-exit \
--enable-newlib-global-atexit \
--disable-nls

It was my understanding that --disable-nls would disable
internationalization support. Unfortunately, I am observing the
following behaviour with the attached code:

$ msp430-elf-gcc -Os -o uart uart.c -mmcu=msp430g2553
$ size uart
   textdata bss dec hex filename
778  16  90 884 374 uart

$ msp430-elf-gcc -Os -o uart uart.c -mmcu=msp430g2553 -DUSE_TOUPPER
$ size uart
   textdata bss dec hex filename
   1476 398  921966 7ae uart

The function toupper() is pulling in 382 bytes into .data. This accounts
for 74.6% of this particular microcontroller's SRAM. This is not very
nice. Furthermore, I have not really looked into it, but should this new
data actually be mutable? If not, it could very well go into .rodata and
stay in flash memory.

Ideally, I should be able to disable internationalization support
alltoguether even if it goes against the C and POSIX standards. Is there
any way to actually do that I am missing?

Thank you.

Cheers,
Orlando.

On 03/03/2017 01:30 PM, DJ Delorie wrote:
> 
> This has come up before, and here's what's going on... the new
> msp430-elf-gcc includes all the code required by the standard, partly
> because... well, standards... and partly so that the testsuite can test
> everything.  The old msp-gcc made lots of assumptions about how the
> compiler would actually be used, and "pre-optimized" the runtime for it.
> 
> So you end up with things like "argv handling" when there's no command
> line, or "exit closes files" when you never exit.  A big change is using
> a float-enabled printf when you don't need it.
> 
> I put some notes here, way back when, but they're old, and IIRC it's
> been improved even more since then:
> 
> http://people.redhat.com/~dj/msp430/size-optimizations.html
> 
> Also, you can use "msp430-elf-gcc -mintr ..." to minimize the runtime
> support.
> 
> Also, if you're REALLY constrained to size, you might consider getting
> the crt0.S source file from newlib and modifying it yourself to really
> strip out the parts you don't need.  Most embedded code really only
> needs to set up the stack and watchdog, then jump to main().
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
> 


signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[Peter Bigot]

On Fri, Mar 3, 2017 at 12:30 PM, DJ Delorie  wrote:

> Also, if you're REALLY constrained to size, you might consider getting
> the crt0.S source file from newlib and modifying it yourself to really
> strip out the parts you don't need.  Most embedded code really only
> needs to set up the stack and watchdog, then jump to main().
>

Be careful with this.  TI's Code Composer compiler originally had a
stripped down crt0 that didn't bother clearing the bss section.  This meant
any static variable definition (including globals) would not necessarily be
cleared on power up.  So if you rely on a variable being null to indicate
that some initialization is necessary your program may or may not work.

The advice is also dubious if you're using C++ as there may be static
constructors that need to be invoked (and yes, modern C++ if used carefully
is appropriate for embedded programming even on constrained chips like
MSP430).

In short, if you muck with the crt0 code be very sure you know the effect
of stripping things out.

Peter
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[Bob von Knobloch]

On 03/03/17 19:30, DJ Delorie wrote:
>
> This has come up before, and here's what's going on... the new
> msp430-elf-gcc includes all the code required by the standard, partly
> because... well, standards...

> So you end up with things like "argv handling" when there's no command
> line, or "exit closes files" when you never exit.  A big change is using
> a float-enabled printf when you don't need it.
>

>
> Also, you can use "msp430-elf-gcc -mintr ..." to minimize the runtime
> support.
>
> Also, if you're REALLY constrained to size, you might consider getting
> the crt0.S source file from newlib and modifying it yourself to really
> strip out the parts you don't need.  Most embedded code really only
> needs to set up the stack and watchdog, then jump to main().
>

Thanks to all for the input.
This confirms what I suspected regarding newlib.
I will pursue rewriting crt0.S at some stage.
For now, I still can go back to an old OS with mspgcc as a stopgap.
Cheers,

Bob

-- 
The Sun is out, the sky is blue, it's time to drive the MR2.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[Yamandu Ploskonka]

long story short, one of my first mspgcc worked because of a bug, when
later either the bug was fixed in mspgcc or fedora (don't recall which one
exactly), things broke all over, code unusable, docs I had share were
wrong.
But by then I was already married to the MSP430 chips, so I stayed for the
ride, and am generally happy with my choice, though that ESP that uses
arduino code and has full wifi at a cost of around one US dollar per has
more than once made me look again. :-) (but it eats battery power, so
again, MSP430 is better, at least for me)

On Fri, Mar 3, 2017 at 12:30 PM, DJ Delorie  wrote:

>
> This has come up before, and here's what's going on... the new
> msp430-elf-gcc includes all the code required by the standard, partly
> because... well, standards... and partly so that the testsuite can test
> everything.  The old msp-gcc made lots of assumptions about how the
> compiler would actually be used, and "pre-optimized" the runtime for it.
>
> So you end up with things like "argv handling" when there's no command
> line, or "exit closes files" when you never exit.  A big change is using
> a float-enabled printf when you don't need it.
>
> I put some notes here, way back when, but they're old, and IIRC it's
> been improved even more since then:
>
> http://people.redhat.com/~dj/msp430/size-optimizations.html
>
> Also, you can use "msp430-elf-gcc -mintr ..." to minimize the runtime
> support.
>
> Also, if you're REALLY constrained to size, you might consider getting
> the crt0.S source file from newlib and modifying it yourself to really
> strip out the parts you don't need.  Most embedded code really only
> needs to set up the stack and watchdog, then jump to main().
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[Peter Bigot]

I think it's pretty unlikely msp430-libc would work with upstream gcc,
though I admit I haven't tried it.

http://pabigot.github.io/bsp430/msp430elf.html has some outdated
suggestions for building customized newlib and trimming out functionality
that isn't needed.

Glad to know people are still getting value out of mspgcc.  I'm afraid I
haven't even fired it up for a couple years (mostly doing either ARM
Cortex-M or Node.js these days).

Peter

On Fri, Mar 3, 2017 at 8:03 AM, Nick Clifton  wrote:

> Hi Bob,
>
> > As far as I can see, the 'bloat' is in library funcs (newlib?).
>
> If the bloat is indeed in the library funcs why not just compile with
> gcc and then link in the old, mspcc C library instead of newlib ?
>
> Cheers
>   Nick
>
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[DJ Delorie]

This has come up before, and here's what's going on... the new
msp430-elf-gcc includes all the code required by the standard, partly
because... well, standards... and partly so that the testsuite can test
everything.  The old msp-gcc made lots of assumptions about how the
compiler would actually be used, and "pre-optimized" the runtime for it.

So you end up with things like "argv handling" when there's no command
line, or "exit closes files" when you never exit.  A big change is using
a float-enabled printf when you don't need it.

I put some notes here, way back when, but they're old, and IIRC it's
been improved even more since then:

http://people.redhat.com/~dj/msp430/size-optimizations.html

Also, you can use "msp430-elf-gcc -mintr ..." to minimize the runtime
support.

Also, if you're REALLY constrained to size, you might consider getting
the crt0.S source file from newlib and modifying it yourself to really
strip out the parts you don't need.  Most embedded code really only
needs to set up the stack and watchdog, then jump to main().

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[Yamandu Ploskonka]

I "thought" something like that was happening to me, but didn't follow
through. For operating system compatibility reasons I decided a while back
to just keep using the legacy one, it works well for the simple things that
I do, also some tool I downloaded from TI was a terrible bloat itself in
the computer at that moment, and I really didn't need whatever GUI features
it offered, if any, or why it needed so much space (very early SSD, 1.5 GB
available space total).

Too many words to say, again, thanks to P.Bigot! your stuff is still being
used

On Fri, Mar 3, 2017 at 8:08 AM, Bob von Knobloch  wrote:

> On 03/03/17 14:29, David W. Schultz wrote:
> > On 03/03/2017 05:20 AM, Bob von Knobloch wrote:
> >> As far as I can see, the 'bloat' is in library funcs (newlib?).
> >> Why the 50% increase and can I mitigate this somehow?
> >> Regards,
> >> Bob von Knobloch.
> >>
> >
> > Hard to say without seeing the code. Have you looked at the resulting
> > file using objdump? If not, that can disassemble the code into something
> > readable so you can see just what is going on.
> >
> Yes, it shows (as does the .map file) that the .text corresponding to my
> source is approx. the same size for both compilers, but that the very
> basic library functions that get pulled in (add, subtract etc.) are
> producing much more code than in the old version.
> I have tested different optimisation switches, but always get the same
> resulting code size.
>
> Bob
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[Bob von Knobloch]

On 03/03/17 14:29, David W. Schultz wrote:
> On 03/03/2017 05:20 AM, Bob von Knobloch wrote:
>> As far as I can see, the 'bloat' is in library funcs (newlib?).
>> Why the 50% increase and can I mitigate this somehow?
>> Regards,
>> Bob von Knobloch.
>>
>
> Hard to say without seeing the code. Have you looked at the resulting
> file using objdump? If not, that can disassemble the code into something
> readable so you can see just what is going on.
>
Yes, it shows (as does the .map file) that the .text corresponding to my 
source is approx. the same size for both compilers, but that the very 
basic library functions that get pulled in (add, subtract etc.) are 
producing much more code than in the old version.
I have tested different optimisation switches, but always get the same 
resulting code size.

Bob


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[Nick Clifton]

Hi Bob,

> As far as I can see, the 'bloat' is in library funcs (newlib?).

If the bloat is indeed in the library funcs why not just compile with
gcc and then link in the old, mspcc C library instead of newlib ?

Cheers
  Nick




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[Nico Coesel]

Op 03/03/2017 om 02:29 PM schreef David W. Schultz:
> On 03/03/2017 05:20 AM, Bob von Knobloch wrote:
>> As far as I can see, the 'bloat' is in library funcs (newlib?).
>> Why the 50% increase and can I mitigate this somehow?
>> Regards,
>> Bob von Knobloch.
>>
> Hard to say without seeing the code. Have you looked at the resulting
> file using objdump? If not, that can disassemble the code into something
> readable so you can see just what is going on.
>
An easier approach is to let the linker generate a map file and compare 
between the two compilers. The mapfile shows the size of each object 
(source file and imported library functions). It can be code generation 
is less efficient or libraries are bigger. The original MSP430GCC C 
libraries are very compact so it wouldn't surprise me if it turns out a 
different library is the cullprit.

N. Coesel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[David W. Schultz]

On 03/03/2017 05:20 AM, Bob von Knobloch wrote:
> As far as I can see, the 'bloat' is in library funcs (newlib?).
> Why the 50% increase and can I mitigate this somehow?
> Regards,
> Bob von Knobloch.
> 

Hard to say without seeing the code. Have you looked at the resulting
file using objdump? If not, that can disassemble the code into something
readable so you can see just what is going on.

-- 
David W. Schultz
http://home.earthlink.net/~david.schultz
"Life without stock is barely worth living..." - Anthony Bourdain

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

[Mspgcc-users] TI compiler

[Bob von Knobloch]

Hi,
I've been using the 'old' compiler last maintained by P.Bigot(many 
thanks to him).
Now I need to make some changes and have installed the new msp430-gcc 
6.2.1.16 under OpenSuse 42.1

My small project under the 'old' compiler produced a .text size of 1392 
bytes, the 'new' compiler makes a .text of 2160 bytes.

This no longer fits on the target µproc.

As far as I can see, the 'bloat' is in library funcs (newlib?).
Why the 50% increase and can I mitigate this somehow?
Regards,
Bob von Knobloch.
-- 
The Sun is out, the sky is blue, it's time to drive the MR2.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users