MSP-GCC 4. Кто-нибудь пробовал?, Случайно наткнулся:) Опции

[AHTOXA]

http://mspgcc4.sourceforge.net/

Пишут, что

GCC 4.x has several advantages over the old 3.2.3 branch. Here are the most important:

• Better optimization. The generated code is typically 7%-10% smaller than code generated by MSPGCC-3.2.3
• Better debug info support. The objdump utility displays the mixed assembly/code correctly.
• Better C++ and inlining support. Unused local variables are automatically filtered out. Inline functions are implemented in a much more compact way.
• Support for various handy features. For example, gcc 4.3 correctly handles the #pragma once statements.
• Additionally, the MSPGCC4 port fixes the data-sections bug present in all original MSPGCC versions, allowing using -ffunction-sections and -fdata-sections switches.

Насчёт -ffunction-sections and -fdata-sections врут похоже, у меня и с ними и в текущем msp-gcc нет проблем.

Короче, если кто-то пробовал, поделитесь пожалуйста впечатлениями.

[MrYuran]

Нашёл предварительно, где копать:
stdlib.h:

Код

extern __inline__ int abs(int __x) __ATTR_CONST__;
extern __inline__ int abs(int __x)
{
    return (__x < 0)  ?  -__x  :  __x;
}
        
extern __inline__ long labs(long __x) __ATTR_CONST__;
extern __inline__ long labs(long __x)
{
    return (__x < 0)  ?  -__x  :  __x;
}

Ну и каким местом он влезает во все модули, где есть stdlib.h ?
Посмотрел, в старой версии этот файл один-в-один

Таки победил
Пришлось extern __inline__ заменить на static __inline__

Build project 9010U - OK.
text data bss dec hex filename
20191 72 742 21005 520d 9010U.elf
msp430-gcc (MSPGCC4_r4-20100210) 4.4.3
Copyright © 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Ну ничего себе "Better optimization. The generated code is typically 7%-10% smaller than code generated by MSPGCC-3.2.3"
- 20k против 12 от предыдущей версии!

[AHTOXA]

Ну ничего себе "Better optimization. The generated code is typically 7%-10% smaller than code generated by MSPGCC-3.2.3"
- 20k против 12 от предыдущей версии!

Это общая тенденция - 4й GCC генерит больший код, чем 3й. Хотя 20 против 12 - это явный перебор.

[demiurg_spb]

Это общая тенденция - 4й GCC генерит больший код, чем 3й. Хотя 20 против 12 - это явный перебор.

Неа. Всё же со всеми новыми способами оптимизации 4й GCC получается получше 3-его.

[MrYuran]

Неа. Всё же со всеми новыми способами оптимизации 4й GCC получается получше 3-его.

Прикрутил-таки сегодня "вхоле-програм" и "комбайн". -Os

Код

Build project 9010U - OK.
   text       data        bss        dec        hex    filename
   7518          4        772       8294       2066    9010U.elf
msp430-gcc (MSPGCC4_r4-20100210) 4.4.3
Copyright (C) 2010 Free Software Foundation, Inc.

-O3 выдал internal compiler error

-O2:

Код

   text       data        bss        dec        hex    filename
   8876          4        772       9652       25b4    9010U.elf

-O1:

Код

   text       data        bss        dec        hex    filename
   8824          4        772       9600       2580    9010U.elf

Оптимизация выключена:

Код

   text       data        bss        dec        hex    filename
  12574         72       1118      13764       35c4    9010U.elf

Практически то же самое, что 3-я версия давала с -O3
Если это ещё на железке заработает, вывод однозначный. Брать!
По оптимизации вполне сравнимо с ИАРом.

[demiurg_spb]

По оптимизации вполне сравнимо с ИАРом.

Так и о чём:-)
При таком способе оптимизации очень важно грамотно использовать volatile - и там где раньше и без него могло проканать - теперь не проканает...

[AHTOXA]

По оптимизации вполне сравнимо с ИАРом.

Круто! Теперь будет занята четверть объёма флеша

При таком способе оптимизации очень важно грамотно использовать volatile - и там где раньше и без него могло проканать - теперь не проканает...

Кстати да, ждём повторного отчёта, после расстановки всех положенных volatile

[MrYuran]

Круто! Теперь будет занята четверть объёма флеша

Дело не в этом, просто всё должно быть красиво!
Ну и хочется знать хотя бы теоретический предел "сжатия".
К тому же, у меня задачи достаточно легковесные (измериловка, обработка, обмен с хостом), а вот к примеру, для автономного прибора с графическим экранчиком, кучей менюшек и даже встроенным блокнотом уже начинает играть рояль.
Причём, от оптимизации и потребление может зависеть (хотя, на фоне экранчика, жрущего как лошадь 3мА, это всё копейки...)
Или вот например, выпустили серию G2xx. Вот если бы добавили флеша хотя бы до 8кБ, то туда можно было бы упихать что-нибудь стоящее.

Попробовал вчера ещё один проект собрать, там что-то непонятное творит.
Такое ощущение, что вместо elf-а подсовывает неразлинкованный объектник.
 1002TD.elf.lst.zip ( 32.52 килобайт ) Кол-во скачиваний: 80

[demiurg_spb]

Такое ощущение, что вместо elf-а подсовывает неразлинкованный объектник.

Да ну... Откуда такие предположения? Вроде как при такой компиляции он объектные файлы вообще не создаёт.
У Вас в Makefile конечная цель elf или всё-таки ещё получаете hex или bin и что с ними?

[MrYuran]

Да ну... Откуда такие предположения? Вроде как при такой компиляции он объектные файлы вообще не создаёт.
У Вас в Makefile конечная цель elf или всё-таки ещё получаете hex или bin и что с ними?

Предположения из листинга, полученного обждампом из эльфа.
Делаю так:

Код

$(NAME).elf : $(CSRC)
    @echo $^
    @$(CC) -c $(CFLAGS) -combine -fwhole-program $^ $(LDFLAGS) -o $@

Как уже писал, в предыдущем проекте всё собралось нормально.
И листинг нормальный.

CODE

Disassembly of section .text:

00001100 <__init_stack>:

1100: 31 40 00 0a mov #2560, r1 ;#0x0a00

00001104 <__low_level_init>:

1104: b2 40 80 5a mov #23168, &0x0120 ;#0x5a80
1108: 20 01

0000110a <__do_clear_bss>:
110a: 3f 40 e6 02 mov #742, r15 ;#0x02e6
110e: 0f 93 tst r15
1110: 04 24 jz $+10 ;abs 0x111a
1112: 1f 83 dec r15
1114: cf 43 48 02 mov.b #0, 584(r15);r3 As==00, 0x0248(r15)
1118: fc 23 jnz $-6 ;abs 0x1112

0000111a <__do_copy_data>:
111a: 3f 40 48 00 mov #72, r15 ;#0x0048
111e: 0f 93 tst r15
1120: 05 24 jz $+12 ;abs 0x112c
1122: 2f 83 decd r15
1124: 9f 4f 68 5a mov 23144(r15),512(r15);0x5a68(r15), 0x0200(r15)
1128: 00 02
112a: fb 23 jnz $-8 ;abs 0x1122

0000112c <__jump_to_main>:
112c: 30 40 54 22 br #0x2254

00001130 <__ctors_end>:
1130: 30 40 3e 12 br #0x123e

а вот "ненормальный":

CODE

Disassembly of section .text.GetRealTime.1824:

00000000 <GetRealTime.1824>:
0: 0b 12 push r11
2: 0b 4f mov r15, r11
4: 08 3c jmp $+18 ;abs 0x16
6: 1e 42 00 00 mov &0x0000,r14
a: 1f 42 00 00 mov &0x0000,r15
e: 8b 4e 00 00 mov r14, 0(r11) ;0x0000(r11)
12: 8b 4f 02 00 mov r15, 2(r11) ;0x0002(r11)
16: 1c 42 00 00 mov &0x0000,r12
1a: 1d 42 00 00 mov &0x0000,r13
1e: 3e 4b mov @r11+, r14
20: 3f 4b mov @r11+, r15
22: 2b 82 sub #4, r11 ;r2 As==10
24: 0c 9e cmp r14, r12
26: ef 23 jnz $-32 ;abs 0x6
28: 0d 9f cmp r15, r13
2a: ed 23 jnz $-36 ;abs 0x6
2c: 3b 41 pop r11
2e: 30 41 ret
Disassembly of section .text.Beep.1817:

00000000 <Beep.1817>:
0: 0b 12 push r11
2: 0a 12 push r10
4: 0b 4f mov r15, r11
6: 3f 40 00 00 mov #0, r15 ;#0x0000
a: b0 12 00 00 call #0x0000
e: 0c 4b mov r11, r12
10: 3a 40 05 00 mov #5, r10 ;#0x0005
14: b0 12 00 00 call #0x0000
18: 0d 43 clr r13
1a: 82 5c 00 00 add r12, &0x0000
1e: 82 6d 00 00 addc r13, &0x0000
22: e2 c3 31 00 bic.b #2, &0x0031 ;r3 As==10
26: 3a 41 pop r10
28: 3b 41 pop r11
2a: 30 41 ret

Если первый выглядит как нормальный бинарник, с конкретными абсолютными адресами, то второй - как нелинкованный выход компилятора.