[GenaSPB 11]

Как я уже говорил, сообщения об ошибках идут только при ключе -flto=8, просто -flto нормально работает.

Права есть, это мой tmp

Да, связное устройство, трансивер называется - с прямой оцифровкой сигнала на приёме, STM32F429/446 работает DSP и контроллером.

Исходники всего в SVN лежат, я ссылки давал.

какой компиллер 32 или 64 битный.

64

Изменено 3 июня, 2015 пользователем Genadi Zawidowski

[Viciouspriest 0]

2_Viciouspriest

еще один среатив - удалось собрать из транка arm-kgp-eabi host i686-kgp-mingw32

www.klen.org//Files/DevTools/i686-kgp-mingw32/arm-kgp-eabi_@_i686-kgp-mingw32_20150603_CETONIA.7z

 

Собираю с Вашими ключами

 

d:/gcc/arm-kgp-eabi_cetonia/bin/../lib/gcc/arm-kgp-eabi/6.0.0/../../../../arm-kgp-eabi/bin/ld.exe: cannot find crtfastmath.o: 
No such file or directory
collect2.exe: error: ld returned 1 exit status
make: *** [uPKB_G.elf] Error 1

Изменено 4 июня, 2015 пользователем Viciouspriest

[klen 1]

Собираю с Вашими ключами

 

d:/gcc/arm-kgp-eabi_cetonia/bin/../lib/gcc/arm-kgp-eabi/6.0.0/../../../../arm-kgp-eabi/bin/ld.exe: cannot find crtfastmath.o: 
No such file or directory
collect2.exe: error: ld returned 1 exit status
make: *** [uPKB_G.elf] Error 1

распакованное нужно положить в корневую директорию сборки., в либы скопируются crtfatsmath.o

 

www.klen.org/Files/DevTools/arm-kgp-eabi-crtfastmath.tar.bz2

[halfdoom 0]

еще опыт предлагаю, добавте еще при компилянии и линковке 6.0.0 ключики -Ofast -fomit-frame-pointer -finline-functions -ffunction-sections -fdata-sections -fgraphite -funroll-loops -flto=8 -ffat-lto-objects, давайте сравним результаты, LTO оптимизатор должен еще накинуть скорости.

Раньше не было только -fgraphite -funroll-loops -flto=8 -ffat-lto-objects. В данном случае интересен только размер кода, т.к. быстродействия пока хватает. С -flto не собирается совсем - либо segmentation fault, либо "local frame unavailable (naked function?)" - разные версии компилятора дают разные ошибки. Наверное, это из за весьма навороченных шаблонов. Доля чистого C-кода, который мог бы быть оптимизирован не велика, а все остальное (C++) собирается через policy стиль и успешно оптимизируется как одна единица компиляции. -fgraphite никаких изменений не дает.

[demiurg_spb 0]

собирается через policy стиль

Интересно, что это такое?

 

[halfdoom 0]

Интересно, что это такое?

 

Это активно пропагандируемый адептами типа Александреску стиль объектно ориентированного программирования с использованием шаблонов, при использовании которого удается избежать потерь на виртуальные функции и ненужных иерархий классов.

 

Т.е. вместо:

class Interface {
    virtual send() = 0;
    virtual receive() = 0;
};

class SerialInterface : public Interface {
    send();
    receive();
};

class UsbInterface : public Interface {
    send();
    receive();
};

class MySuperRobot
{
    Interface *interface;

    init(Interface *ifp) {
       interface = ifp;
       interface->send() || interface->receive();
    }
};

Предлагается писать:

template<....>
class SerialInterface  {
    send() { blah }
    receive() { vah }
};

template<....>
class UsbInterface {
    send() { blah }
    receive() { vah }
};

template <class Interface>
class MySuperRobot
{
    Interface interface;

    test() { interface.send() || interface.receive(); }
};

 

Аналогичного эффекта можно добиться с отказом от наследования и использованием ifdef'ов, но с шаблонами получается проще и удобнее.

[klen 1]

свежак таргет arm хост linux64

 

http://klen.org/Files/DevTools/x86_64-kgp-...0623_LUPINUS.7z

[kimstik 0]

А можно до кучи к fastmath еще и libc_nano.a ?

[klen 1]

свежак таргет arm хост linux64

 

www.klen.org/Files/DevTools/x86_64-kgp-linux-gnu/arm-kgp-eabi_@_x86_64-kgp-linux-gnu_20150701_PATHENOCISSUS.7z

 

fastmath доприкручн.

 

newlibc-nano.. я пробывал - ненашел различий в разрезе кортексиков. мож не нашел. дособеру выложу.

[klen 1]

... выше выложенным свежаком дособрана newlib-nano-2

libc_nano_2.tar.7z

[kimstik 0]

libc.a надо ручками переименовать в libc_nano.a исходя из nano.specs ?

и размер нулевой у libc.a ...

 

[klen 1]

2_kimstik

>> libc.a надо ручками переименовать в libc_nano.a исходя из nano.specs ?

все зависит о Вас - какие ключи пропихиваются компиллеру и линкеру. если не переименовывать тупо будеть линковатся libc

 

>> и размер нулевой у libc.a ...

не должно быть проблем ибо libc и libg это близнецы и обе ликуются по умолчанию, но всеровно эффект интересный - должны быть идентичны.

 

 

[klen 1]

наладил сквозную сборку по хостам

свеки таргет arm

 

хост x86_64 linux

http://klen.org/Files/DevTools/x86_64-kgp-..._CONVOLVULUS.7z

 

хост x86_64 win

http://klen.org/Files/DevTools/x86_64-kgp-..._CONVOLVULUS.7z

 

хост i686 win

http://klen.org/Files/DevTools/i686-kgp-mi..._CONVOLVULUS.7z

[Шаманъ 0]

наладил сквозную сборку по хостам

свеки таргет arm

 

хост x86_64 win

http://klen.org/Files/DevTools/x86_64-kgp-..._CONVOLVULUS.7z

У меня проблема с компоновщиком - неправильно считает адреса.

 

Вот кусочек из ld скрипта:

  .data  : AT ( _etext )
    {
        . = ALIGN(4);
        /* This is used by the startup in order to initialize the .data section */
        _data_start = .;
        _data_start_flash = _etext;

        *(.data)
        *(.data.*)

        . = ALIGN(4);
        /* This is used by the startup in order to initialize the .data section */
        _data_end = .;
    } >RAM
    
    
    .settings  : AT ( _etext + _data_end - _data_start)
    {
        . = ALIGN(4);
        /* This is used by the startup in order to initialize the .settings section */
        _settings_start = .;
        _settings_start_flash = _etext + _data_end - _data_start;

        *(.settings)
        *(.settings.*)

        . = ALIGN(4);
        /* This is used by the startup in order to initialize the .settings section */
        _settings_end = .;
    } >RAM

 

А вот что в map-файле:

...............................................................................

 

0x0000000008016b74 _etext = .

 

...............................................................................

 

0x0000000020000000 _data_start = .

 

...............................................................................

 

0x0000000020000058 _data_end = .

 

...............................................................................

 

.settings 0x0000000020000058 0xd0 load address 0x0000000048016bcc

0x0000000020000058 . = ALIGN (0x4)

0x0000000020000058 _settings_start = .

0x0000000048016bcc _settings_start_flash = ((_etext + _data_end) - _data_start)

 

Собственно вот - компилируется и линкуется нормально, но прошить с такими адресами естественно не получается. Такое впечатление, что вместо вычитания делается сложение :1111493779: И еще немного информации - этf проблема не только в версии 6.00, аналогичная проблема была в 4.9.3 (не Вашей сборки). А вот CodeSourcery старый 4.4.1 работает нормально.

 

Если нужны ld скрипт и map файлы могу выложить.

[klen 1]

У меня проблема с компоновщиком - неправильно считает адреса.

давайте скрипт линкера, я его проверю. думаю в нем косяг.

либо ... ну и как обычно... под винду все работант через жЁпу... классика....