| |
|
  |
 свежак KGP win32/arm/avr/mips/m68k, GNU tools chain |
|
|
|
|
 Apr 16 2011, 17:48
|
Группа: Новичок
Сообщений: 1
Регистрация: 13-11-08
Пользователь №: 41 606
|
Цитата(Mitsufan @ Mar 31 2011, 00:54)  Что-то линкер из последней сборки для MIPS стал ругаться на инверсию атрибута в описании блока памяти в скрипте линкера.
MEMORY
{
kseg1_data_mem (w!x) : ORIGIN = 0xA0000000, LENGTH = 0x20000
}
../../../mips-kgp-elf/bin/ld.exe: invalid syntax in flags
collect2: ld returned 1 exit status
Меняю ld.exe на предыдущий (4.6.0 от 25.07.2010) - все нормально компилируется. Добрый день. Если не "секрет", не могли бы рассказать как Вам удалось воспользоваться этой сборкой для работы С PIC32MX? Какой язык программирования используется (C или C++) ? Какой отладчик используете? Интересует возможность применения C++ для работы с PIC32MX, использую эту сборку и стандартные средства отладки от Microchip. Теоретически, это возможно.
|
|
|
|
|
|
|
|
Apr 17 2011, 17:20
|
Группа: Участник
Сообщений: 14
Регистрация: 10-11-10
Пользователь №: 60 787
|
К сожалению, что-то никак я не освою работу с обсуждаемым предметом.
Кроме, собственно, того, что Эклипс вызывает не очень хорошие эмоции, никак не разберусь с тулчейном.
Есть демо-проект от терровской платы с stm32f107, несколько статей в pdf-ках. Отладчик их же te-arm-link.
При заливке бинарника из проекта (т.е. который уже был в архиве) всё работает нормально. А вот скомпилить заново такой же -- ну никак..
Основная проблема сейчас -- unresolved inclusion заголовков стандартной библиотеки Си (типа stdint.h) (path к тулчейну прописан)
Пытался разобраться со структурой тулчейна -- непонятно, почему некоторые файлы повторяются несколько раз, почему папка include в корне пустая... и т.п. Помогите разобраться, пожалуйста. Очень хочеться понять.
На всякий случай: ОС ВинХР, 32bit, Eclipse IDE for C/C++ Developers Helios Service Release 2
|
|
|
|
|
|
|
|
Apr 18 2011, 07:31
|
Частый гость
Группа: Участник
Сообщений: 123
Регистрация: 28-06-05
Из: Тула
Пользователь №: 6 361
|
А почему в newlib используются не оптимизированные стандартные функции, например memcpy() ? Побайтовое копирование на 32-х разрядной шине - это что-то с чем-то. Не ожидал такого подвоха, поэтому использовал из netbsd
|
|
|
|
|
|
|
|
Apr 19 2011, 04:43
|
Местный
Группа: Участник
Сообщений: 340
Регистрация: 25-10-05
Из: Пермь, Россия
Пользователь №: 10 091
|
Цитата(Bender @ Apr 18 2011, 12:31) А почему в newlib используются не оптимизированные стандартные функции, например memcpy() ?
Побайтовое копирование на 32-х разрядной шине - это что-то с чем-то. Где именно там побайтное копирование? У Вас, случайно, не определены макросы типа PREFER_SIZE_OVER_SPEED или __OPTIMIZE_SIZE__?
--------------------
Всего наилучшего,
Alex Mogilnikov
|
|
|
|
|
|
|
|
Apr 19 2011, 06:59
|
Частый гость
Группа: Участник
Сообщений: 123
Регистрация: 28-06-05
Из: Тула
Пользователь №: 6 361
|
newlib 1.19вот тут смотрел __OPTIMIZE_SIZE__ PREFER_SIZE_OVER_SPEED не определял, компилю с опцией -Os Полез разбираться дальше для тестирования делаю так Код while(1)
{
LED1_ON;
memcpy((void *)test1, (const void *)test2, 512);
LED1_OFF;
} 1.Оказалось что массивы легли в памяти не выровненными, несмотря на указание Код unsigned int test1[128] __attribute__ ((__aligned__(8)));
unsigned int test2[128] __attribute__ ((__aligned__(8)));
0x400023cd test1
0x40002884 test2 выровнял, введя доп. переменные. Ничего не изменилось. по времени выходит 87 мкс 2.Для netbsd ситуация гораздо лучше: все тоже самое, только времени занимает 8.2 мкс Где еще покопать, чтобы разобраться?
Сообщение отредактировал Bender - Apr 19 2011, 07:57
|
|
|
|
|
|
|
|
Apr 22 2011, 06:00
|
Местный
Группа: Участник
Сообщений: 340
Регистрация: 25-10-05
Из: Пермь, Россия
Пользователь №: 10 091
|
Цитата(Bender @ Apr 19 2011, 11:59) __OPTIMIZE_SIZE__ PREFER_SIZE_OVER_SPEED не определял, компилю с опцией -Os Вот в -Os собака и порылась. При указании опции -Os gcc автоматически делает #define __OPTIMIZE_SIZE__ 1. Или пересоберите newlib без -Os, или используйте свою memcpy().
Сообщение отредактировал alx2 - Apr 22 2011, 06:19
--------------------
Всего наилучшего,
Alex Mogilnikov
|
|
|
|
|
|
|
|
Apr 22 2011, 12:10
|
Частый гость
Группа: Участник
Сообщений: 123
Регистрация: 28-06-05
Из: Тула
Пользователь №: 6 361
|
Меня больше смущает то, что линкер размещает переменные по не выровненным адресам. И хотя все что надо работает работает, сомнения в правильности кода остаются. Да, к тому же хотя объем кода уменьшился, зато область ОЗУ (.bss) раздулась с 8 до 13 кбайт. Например, если линкер будет собирать без ключа -flto получим это: Код 0x40001580 dbg_buf
0x40001600 ... с ключом -flto выделилось больше ОЗУ Код 0x40000409 dbg_buf
*fill* 0x40000df4 0x4 00
.bss 0x40000df8 0x898 C:\temp\ccOPsERd.ltrans2.ltrans.o
0x40000df8 ... без ключа -flto получим это: Код 0x40000fec task_io_stack
0x400011ec task_enc с ключом -flto под стек выделили не выровненную область Код 0x400025d1 task_io_stack
0x400027d1 task_enc И такое место не одно. Хотелось бы понять механизм оптимизации, как им управлять и почему не реагирует на __attribute__ ((__aligned__(8)))
|
|
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
