Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: свежак KGP win32/arm/avr/mips/m68k
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Cредства разработки для МК > GNU/OpenSource средства разработки
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26
klen
свежак для ARM

www.klen.org/Files/DevTools/kgp_arm_cortex-m3_20090901.7z - обрезанна, для кортекса.
www.klen.org/Files/DevTools/kgp_arm_full_20090901.7z - полня
alexander iz
Цитата(klen @ Sep 3 2009, 23:59) *
свежак для ARM

www.klen.org/Files/DevTools/kgp_arm_cortex-m3_20090901.7z - обрезанна, для кортекса.
www.klen.org/Files/DevTools/kgp_arm_full_20090901.7z - полня


Ситуация такая:
установлен WinAVR.
PATH сначала указывает на кучку свежаков, потом на winavr.
С крайтим свежаком для arm при сборке проекта вываливается mkdir с ошибкой обращения к памяти. С предыдущей сборкой такой ошибки нет, проект собирается корректно (mkdir.exe подсасывается из winavr\utils\bin определённо, потому что более его нигде нет).

C AVR досадно, но не работает avr-size из крайней сборки для avr (хотя, из winavr считает объёмы корректно).

c:\gcc\bin\avr-size.exe: unrecognized option `--mcu=atmega324p'
Usage: c:\gcc\bin\avr-size.exe [option(s)] [file(s)]
Displays the sizes of sections inside binary files
If no input file(s) are specified, a.out is assumed
The options are:
-A|-B --format={sysv|berkeley} Select output style (default is berkeley)
-o|-d|-x --radix={8|10|16} Display numbers in octal, decimal or hex
-t --totals Display the total sizes (Berkeley only)
--common Display total size for *COM* syms
--target=<bfdname> Set the binary file format
@<file> Read options from <file>
-h --help Display this information
-v --version Display the program's version

Как-то так.

Определённо, я что-то делаю не так. Только не пойму, что именно.

ЗЫ можно, для облегчения жизни, бросать ссылки на крайние сборки в первый пост?
ReAl
Цитата(alexander iz @ Sep 14 2009, 18:15) *
C AVR досадно, но не работает avr-size из крайней сборки для avr (хотя, из winavr считает объёмы корректно).
...
Определённо, я что-то делаю не так. Только не пойму, что именно.
Просто при сборке WinAVR донакладывают свои патчи. Почему (из каких соображений) они не попадают в ствол - я не знаю. Способность avr-size принимать конкретный тип контроллера и выдавать с процентом использования - один из таких давно существующих патчей.
alexander iz
Цитата(ReAl @ Sep 14 2009, 23:31) *
Просто при сборке WinAVR донакладывают свои патчи. Почему (из каких соображений) они не попадают в ствол - я не знаю. Способность avr-size принимать конкретный тип контроллера и выдавать с процентом использования - один из таких давно существующих патчей.


Спасибо.
Подумаю, как лучше поступить..

А с mkdir решилось установкой winavr от 20090313 (был 200812xx).
Компилируется теперь без косяков.
Остаётся понять, в чём была проблема.
NikAn
Уважаемый Klen

Скажите, пожалуйста, для чего нужна libiconv-2.dll, и, как сделать так, чтобы arm-kgp-elf-g++.exe её находил.

Также буду весьма благодарен, если Вы выложите примеры make-файлов, который можно использовать для
компиляции standalone-приложений (.bin) для процессоров ARM7 (LPC2478) и Cortex-M3 (LPC1768)

И еще вопрос: поддерживает ли предложенный Вами openocd примитивный программатор типа Wiggler?


Заранее благодарен
klen
>Скажите, пожалуйста, для чего нужна libiconv-2.dll, и, как сделать так, чтобы arm-kgp-elf-g++.exe её находил.
это внешняя библа для того подержки кодировок разных языков
тут написано http://www.gnu.org/software/libiconv/
вообщето я ее в архив кладу(но мог както пропустить). оно должно лежать в /bin

>Также буду весьма благодарен, если Вы выложите примеры make-файлов, который можно использовать для
>компиляции standalone-приложений (.bin) для процессоров ARM7 (LPC2478) и Cortex-M3 (LPC1768)

..ммм .. я даже не знаю че сказать unsure.gif
мэйкфайлы вообщето не для процессоров а для сборки конкретного приложения и у всех они могут быть разными.

максимум чем я могу помоч так это отослать вас к манам по make и положить пример для STM32F103RET6 в котором демонстрируется в числе прочего как юзать функциональность make. но МАНЫ ВПЕРЕД!!!


>И еще вопрос: поддерживает ли предложенный Вами openocd примитивный программатор типа Wiggler?
ага, сам виглером шил поначалу. есть особенность. Вы должны поставить стронние дрова для паралельного порта. это процедура в инете описана.
NikAn
Добрый вечер (ночь/утро/день) !

Цитата(klen @ Sep 23 2009, 10:31) *
..ммм .. я даже не знаю че сказать unsure.gif
мэйкфайлы вообщето не для процессоров а для сборки конкретного приложения и у всех они могут быть разными.


Я не правильно поставил вопрос. Я хотел узнать ключи компилятора, по которым он определяет для какого процессора
генерировать код. Это конечно можно в интернете узнать и проверить на железке, но как раз ее у меня пока инет.

Цитата
ага, сам виглером шил поначалу. есть особенность. Вы должны поставить стронние дрова для паралельного порта. это процедура в инете описана.


У меня в конфигурационном файле для openocd есть такие слова:
#interface
interface parport
parport_port 0x378
parport_cable wiggler

На этот конфиг, я натравливал приложение с именем openocd-pp.exe. И драйвер какой-то был установлен.
Теперь, если запустить Ваш openocd, появляется сообщение:
Error: The specified JTAG interface was not found (parport)
The following JTAG interfaces are available:
1: ft2232
2: presto

То есть параллельный порт как бы и не подразумевается этим openocd, если я правильно понял.
Непонятно. Нужна такая dll'ка, чтобы параллельный порт "прикинулся" ft2232, что ли?
Вы говорите, что "эта процедура в инете описана". Напишите ссылку, пожалуйста.

Заранее благодарен
klen
увидите какие ключи говорят для какого проца компилить
arm-kgp-elf-gcc --target-help

косяг у меня - я конфигурил oocd без поддержки LPT.
дособираю новую сборку - там будет oocd рулить lpt. Вы как раз и протестируете.
NikAn
Цитата(klen @ Oct 1 2009, 22:48) *
увидите какие ключи говорят для какого проца компилить
arm-kgp-elf-gcc --target-help

косяг у меня - я конфигурил oocd без поддержки LPT.
дособираю новую сборку - там будет oocd рулить lpt. Вы как раз и протестируете.



Добрый вечер (ночь/утро/день)!

Как у Вас обстоят дела с новой сборкой? Не терпится протестировать!
klen
Цитата(NikAn @ Oct 19 2009, 23:29) *
Добрый вечер (ночь/утро/день)!

Как у Вас обстоят дела с новой сборкой? Не терпится протестировать!

хорошо обстоят дела - проблема в одном. нада напрячся и нажать на кнопки файлзиллы чтоб положить все на фтп smile.gif

я щас добавляю LTO оптимизацию для mingw32-host arm-target порта GCC. тут есть проблемки - нада ручками писать код - релизовать врапер unix системных вызовов из sys/mman.h ( mmap() munmap() mlock()..... ) средствами Win32 API. это отображение механизм файлов. Если кто знает готовый врапер для mingw32 тыкните носом - дело ускорится.

результатом будет оптимизация при линковке (LinkTimeOptimization - LTO ), поидее еще болще мусора должно выкидыватся но самое главное линкер сможет двигать куски кода более свободно, например рядом распологать взаимосвязанные функции и и спользовать короткие и более быстрые вызовы, капример rcall вместо call в AVR или чтото в этом роде. Нада разбиратся детально как это с умом приложить http://gcc.gnu.org/wiki/LinkTimeOptimization
AHTOXA
У меня вопрос про arm-kgp, в части Cortex-M3.
Компиляю им проект под scmRTOS, на плюсах.
Есть класс-критическая секция:
Код
class TCritSect
{
public:
    TCritSect () : StatusReg(__get_interrupt_state()) { __disable_interrupt(); }
     ~TCritSect() { __set_interrupt_state(StatusReg); }
private:
     TStatusReg StatusReg;
};

И есть некая использующая эту критическую секцию функция класса:
Код
        INLINE byte GetCount() const { TCritSect cs; return count; }

То есть, идея такая: при входе в функцию создаётся объект TCritSect, при создании запрещаются прерывания, потом выполняется тело функции, и при выходе из неё объект TCritSect разрушается, восстанавливая состояние прерываний.
Так вот, её вызов компилится при помощи arm-kgp в следующий код:
Код
     mrs    r3, PRIMASK    
      cpsid    i          
      msr    PRIMASK, r3    
      ldrb    r0, [r0, #8]
      bx    lr

Здесь две первые строчки - конструктор TCritSect (сохранение PRIMASK и запрет прерываний), третья строчка - деструктор TCritSect (разрешение прерываний), и только четвёртая строчка - чтение переменной. То есть, работает не так, как мне бы хотелось.
CodeSourcery g++ компилит это вот так:
Код
     mrs    r3, PRIMASK    
      cpsid    i          
      ldrb    r0, [r0, #6]
      msr    PRIMASK, r3    
      bx    lr

, то есть, как мне нужно - запрет прерываний, чтение переменной, восстановление прерываний.

Вопрос в следующем: как они этого добились? Делали специальный патч, или просто задали какие-то параметры при сборке? Вернее, вопрос состоит в другом: а нельзя ли сделать как они? smile.gif

ЗЫ. Вопрос о том, как положено по стандарту - неясен, долгие баталии по этому поводу не дали однозначного ответа. Но, имхо, для эмбеддед приложений второй вариант предпочтительней.
ReAl
Цитата(AHTOXA @ Oct 30 2009, 22:15) *
ЗЫ. Вопрос о том, как положено по стандарту - неясен, долгие баталии по этому поводу не дали однозначного ответа.
Эт с какой точки зрения смотреть. С моей -
Цитата
если count (который изменяется где-то независимо от данного участка кода) объявлен как volatile, то всё должно быть нормально в данном случае, так как порядок доступа к volatile-переменным нарушаться не может, а если не volatile, то компилятор вправе двигать
- звучит достаточно однозначно :-).
И count должен быть volatile в любом случае, а TCritSect обеспечивает только атомарность доступа к нему.
Насколько я помню, по итогам обсуждения системный счётчик тиков в scmRTOS стал volatile :-)
Неужели тут count квалифицирован как volatile и всё равно бяка?
AHTOXA
Цитата(ReAl @ Oct 31 2009, 12:50) *
Эт с какой точки зрения смотреть. С моей - - звучит достаточно однозначно :-).

Я потерял ссылку на это обсуждение, потому цитировал по памятиsmile.gif
Цитата
И count должен быть volatile в любом случае, а TCritSect обеспечивает только атомарность доступа к нему.

Ну, атомарность тут обеспечивается архитектурой процессора. То есть, в данном случае критическая секция и не нужна.
Цитата
Насколько я помню, по итогам обсуждения системный счётчик тиков в scmRTOS стал volatile :-)
Неужели тут count квалифицирован как volatile и всё равно бяка?

Это TChannel.GetCount(). То есть, там на самом деле не
Код
return count;

а
Код
return Cbuf.get_count();


Где Cbuf - TCbuf, и в нём
Код
byte get_count() const { return count; }
...
volatile byte count;

То есть, таки volatile.
ReAl
Цитата(AHTOXA @ Oct 31 2009, 10:22) *
Код
byte get_count() const { return count; }
...
volatile byte count;

То есть, таки volatile.
Тогда, на мой взгляд, это баг.
Чтение count и запись назад в статус менять местами нельзя.
AHTOXA
Цитата(ReAl @ Oct 31 2009, 14:35) *
Тогда, на мой взгляд, это баг.


Согласен. А не напомните ссылочку на то обсуждение?

---
Хотя...
Запись статуса реализована как
Код
INLINE inline void __set_interrupt_state(TStatusReg status)
{
    __asm__ __volatile__ (
        "MSR PRIMASK, %0\n"
        : : "r"(status)
    );
}


Мне не совсем понятно, является ли в этом случае PRIMASK volatile?
ReAl
Цитата(AHTOXA @ Oct 31 2009, 12:15) *
Согласен. А не напомните ссылочку на то обсуждение?
Да оно как-то частично по аськам... Выплеснулось на "исходники.ру", сейчас попробую найти

Цитата(AHTOXA @ Oct 31 2009, 12:15) *
Код
INLINE inline void __set_interrupt_state(TStatusReg status)
{
    __asm__ __volatile__ (
        "MSR PRIMASK, %0\n"
        : : "r"(status)
    );
}
Мне не совсем понятно, является ли в этом случае PRIMASK volatile?
Хм... а поставьте-ка в clobbered list "memory" в качестве барьера...


upd: вопрос и обсуждение на "исходниках.ру" http://forum.sources.ru/index.php?showtopi...amp;hl=volatile
а история аськи уже утеряна

upd2: хм, а там модераторы работают, знатно тему почистили, в конце выстрижены все посты кроме моих ответов с примерами кода
AHTOXA
Цитата(ReAl @ Oct 31 2009, 19:13) *
Хм... а поставьте-ка в clobbered list "memory" в качестве барьера...


Да, так всё в порядке. Непонятно только, откуда сборка от CodeSourcery сразу знала про волатильность PRIMASK? smile.gif
Интересная штука с размером кода получается.
Для arm-kgp-elf при внесении "memory" в clobbered list размер моего проекта подрос с 14200 до 14368.
А вот для arm-none-eabi- - наоборот, сократился с 15924 до 15812.
Первое понятно, отключилась какая-то оптимизация. А вот второе просто удивительноsmile.gif

Цитата
upd: вопрос и обсуждение на "исходниках.ру" http://forum.sources.ru/index.php?showtopi...amp;hl=volatile

Ага, оно. Большое спасибо!

---
Да, забыл главное написать. 2 klen - вопрос снят, ваша сборка -- лучшаяsmile.gif
ReAl
Цитата(AHTOXA @ Oct 31 2009, 21:04) *
Да, так всё в порядке.
Ну, в общем-то, этот "ломовой" способ должен бы работать и при всех не-volatile (т.е. шо PRIMASK, шо count).
klen
Цитата(AHTOXA @ Oct 31 2009, 22:04) *
Да, забыл главное написать. 2 klen - вопрос снят, ваша сборка -- лучшаяsmile.gif


стараимсо!
Кстате, как Вы это измеряете?


собрал компиллер и бинутилс с поддержкой link time optimization (LTO) - но чето пока никак не пойму как это работает, код в 10 раз больше в бинарь суется(мож это и не код). разберусь - выложу свежак. главно что заработало, дальше посмотрим че не так.
AHTOXA
Цитата(ReAl @ Nov 1 2009, 02:12) *
Ну, в общем-то, этот "ломовой" способ должен бы работать и при всех не-volatile (т.е. шо PRIMASK, шо count).

Ну а как ещё сказать компилеру, что PRIMASK волатильный? Поправил порт для кортекса на всякий случай, закоммитил.

Цитата(klen @ Nov 1 2009, 02:13) *
стараимсо!
Кстате, как Вы это измеряете?


На глазокsmile.gif Вот на два поста выше привёл размер кода в сравнении с CodeSourcery.

Цитата
собрал компиллер и бинутилс с поддержкой link time optimization (LTO) - но чето пока никак не пойму как это работает, код в 10 раз больше в бинарь суется(мож это и не код). разберусь - выложу свежак. главно что заработало, дальше посмотрим че не так.


Посмотримsmile.gif Но самое главное в новых фичах -- это чтоб их можно было отключитьsmile.gif
klen
свежак для мелких arm

полный мультитлиб
http://www.klen.org/Files/DevTools/kgp_arm_full_20091116.7z

обрезок от полного до cortex-m3
http://www.klen.org/Files/DevTools/kgp_arm...-m3_20091116.7z
напоминаю, что эти тулсы только компилируя с опцией -mcpu=cortex-m3

мои проекты уменьшились на 1% smile.gif

есть подержка LTO, но както оно странно (не)работает, короче ее не использовать, а то в флеш не вместится результат.

брат друг и товаришь по форуму Doka сообщил что ему требуется все тоже самое на хосте x86-64. учитывая что сборка происходит на убунте, если требуется кому, могу выкладывать архивы для нинукса. только свисните.
Jat
Уважаемый klen!
Спасибо большое за Вашу работу по GCC.
Сейчас это лучшая сборка по ARM.
И хочется, чтобы работа с битовыми полями была лучше.

Если приведенный ниже пример поможет Вам - буду рад.

Пример кода (перекодировка по табличкам)

Cortex-M3 -Os

CODE

extern unsigned char const k[8][16];

typedef union
{
struct
{
unsigned y0: 4;
unsigned y1: 4;
unsigned y2: 4;
unsigned y3: 4;
unsigned y4: 4;
unsigned y5: 4;
unsigned y6: 4;
unsigned y7: 4;
} y;
unsigned int x;
} var;

unsigned int func( var v )
{
v.y.y0 = k[0][v.y.y0];
v.y.y1 = k[1][v.y.y1];
v.y.y2 = k[2][v.y.y2];
v.y.y3 = k[3][v.y.y3];
v.y.y4 = k[4][v.y.y4];
v.y.y5 = k[5][v.y.y5];
v.y.y6 = k[6][v.y.y6];
v.y.y7 = k[7][v.y.y7];
return v.x;
}


GCC: (Sourcery G++ Lite 2009q3-68) 4.4.1

CODE

20 func:
24 0000 1A4B ldr r3, .L3
25 0002 00F00F02 and r2, r0, #15
26 0006 9A5C ldrb r2, [r3, r2] @ zero_extendqisi2
27 0008 62F30300 bfi r0, r2, #0, #4
28 000c C0F30312 ubfx r2, r0, #4, #4
29 0010 9A18 adds r2, r3, r2
30 0012 127C ldrb r2, [r2, #16] @ zero_extendqisi2
31 0014 62F30710 bfi r0, r2, #4, #4
32 0018 C0F30322 ubfx r2, r0, #8, #4
33 001c 9A18 adds r2, r3, r2
34 001e 92F82020 ldrb r2, [r2, #32] @ zero_extendqisi2
35 0022 62F30B20 bfi r0, r2, #8, #4
36 0026 C0F30332 ubfx r2, r0, #12, #4
37 002a 9A18 adds r2, r3, r2
38 002c 92F83020 ldrb r2, [r2, #48] @ zero_extendqisi2
39 0030 62F30F30 bfi r0, r2, #12, #4
40 0034 C0F30342 ubfx r2, r0, #16, #4
41 0038 9A18 adds r2, r3, r2
42 003a 92F84020 ldrb r2, [r2, #64] @ zero_extendqisi2
43 003e 62F31340 bfi r0, r2, #16, #4
44 0042 C0F30352 ubfx r2, r0, #20, #4
45 0046 9A18 adds r2, r3, r2
46 0048 92F85020 ldrb r2, [r2, #80] @ zero_extendqisi2
47 004c 62F31750 bfi r0, r2, #20, #4
48 0050 C0F30362 ubfx r2, r0, #24, #4
49 0054 9A18 adds r2, r3, r2
50 0056 92F86020 ldrb r2, [r2, #96] @ zero_extendqisi2
51 005a 62F31B60 bfi r0, r2, #24, #4
52 005e 03EB1073 add r3, r3, r0, lsr #28
53 0062 93F87030 ldrb r3, [r3, #112] @ zero_extendqisi2
54 0066 63F31F70 bfi r0, r3, #28, #4
55 006a 7047 bx lr


GCC: (Klen's GCC package (KGP) for ARM/elf platform) 4.5.0 20091115 (experimental)

CODE

10 func:
13 0000 F3B5 push {r0, r1, r4, r5, r6, r7, lr}
14 0002 1E4B ldr r3, .L2
15 0004 00F00F0C and ip, r0, #15
16 0008 C0F30311 ubfx r1, r0, #4, #4
17 000c 13F80C60 ldrb r6, [r3, ip] @ zero_extendqisi2
18 0010 5918 adds r1, r3, r1
19 0012 C0F30322 ubfx r2, r0, #8, #4
20 0016 91F810C0 ldrb ip, [r1, #16] @ zero_extendqisi2
21 001a 9A18 adds r2, r3, r2
22 001c C0F30351 ubfx r1, r0, #20, #4
23 0020 C0F30335 ubfx r5, r0, #12, #4
24 0024 C0F30344 ubfx r4, r0, #16, #4
25 0028 1C19 adds r4, r3, r4
26 002a 0091 str r1, [sp, #0]
27 002c C0F30367 ubfx r7, r0, #24, #4
28 0030 03EB1071 add r1, r3, r0, lsr #28
29 0034 92F82020 ldrb r2, [r2, #32] @ zero_extendqisi2
30 0038 5D19 adds r5, r3, r5
31 003a 66F30300 bfi r0, r6, #0, #4
32 003e 95F83050 ldrb r5, [r5, #48] @ zero_extendqisi2
33 0042 6CF30710 bfi r0, ip, #4, #4
34 0046 94F840C0 ldrb ip, [r4, #64] @ zero_extendqisi2
35 004a 009C ldr r4, [sp, #0]
36 004c 62F30B20 bfi r0, r2, #8, #4
37 0050 0191 str r1, [sp, #4]
38 0052 65F30F30 bfi r0, r5, #12, #4
39 0056 1919 adds r1, r3, r4
40 0058 91F85020 ldrb r2, [r1, #80] @ zero_extendqisi2
41 005c DB19 adds r3, r3, r7
42 005e 6CF31340 bfi r0, ip, #16, #4
43 0062 DDF804C0 ldr ip, [sp, #4]
44 0066 93F86010 ldrb r1, [r3, #96] @ zero_extendqisi2
45 006a 62F31750 bfi r0, r2, #20, #4
46 006e 9CF87030 ldrb r3, [ip, #112] @ zero_extendqisi2
47 0072 61F31B60 bfi r0, r1, #24, #4
48 0076 63F31F70 bfi r0, r3, #28, #4
49 007a FCBD pop {r2, r3, r4, r5, r6, r7, pc}
klen
свежак

теперь тулсы будут собиратся c EABI, это дает лучший код.

че это такое и очем речь можно по диагоняли посмотреть тут http://infocenter.arm.com/help/topic/com.a...0036B_bsabi.pdf

www.klen.org/Files/DevTools/kgp_arm_eabi_20091127.7z

2_Jat
с EABI стало лучше, Вами предложенный код компиляется на 2 инструкции длинне чем у Sourcery G++ Lite 2009q3-68.
это скотино зачемто сохраняет в стек регистры которые можно неиспользовать. отсюда удлиннение. курю и думаю.
кстате это к работе с битами никакого отношения не имеет. толко к registers usage. Работа с битами очень даже хорошо для кортеха генерится.
dimka76
2 klen

а для AVR вы сборки не делаете?
klen
Цитата(dimka76 @ Dec 1 2009, 14:10) *
2 klen

а для AVR вы сборки не делаете?


делаю
dimka76
Цитата(klen @ Dec 1 2009, 21:10) *
делаю


А скачать откуда можно? На вашем сайте последняя сборка для AVR от 2006 года.
Jat
Цитата(klen @ Dec 1 2009, 15:37) *
с EABI стало лучше, Вами предложенный код компиляется на 2 инструкции длинне чем у Sourcery G++ Lite 2009q3-68.
это скотино зачемто сохраняет в стек регистры которые можно неиспользовать. отсюда удлиннение. курю и думаю.
кстате это к работе с битами никакого отношения не имеет. толко к registers usage.


Спасибо большое!
Скачал, проверил - все великолепно!

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

CODE
unsigned int func( var v )
{
var vv;

vv.y.y0 = k[0][v.y.y0];
vv.y.y1 = k[1][v.y.y1];
vv.y.y2 = k[2][v.y.y2];
vv.y.y3 = k[3][v.y.y3];
vv.y.y4 = k[4][v.y.y4];
vv.y.y5 = k[5][v.y.y5];
vv.y.y6 = k[6][v.y.y6];
vv.y.y7 = k[7][v.y.y7];
return vv.x;
}


то код компилится лучше, чем у CS. На 1 инструкцию (4 байта) меньше.
И push/pop нет совсем.
klen
Цитата(Jat @ Dec 2 2009, 10:20) *
Спасибо большое!
Скачал, проверил - все великолепно!

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

CODE
unsigned int func( var v )
{
var vv;

vv.y.y0 = k[0][v.y.y0];
vv.y.y1 = k[1][v.y.y1];
vv.y.y2 = k[2][v.y.y2];
vv.y.y3 = k[3][v.y.y3];
vv.y.y4 = k[4][v.y.y4];
vv.y.y5 = k[5][v.y.y5];
vv.y.y6 = k[6][v.y.y6];
vv.y.y7 = k[7][v.y.y7];
return vv.x;
}


то код компилится лучше, чем у CS. На 1 инструкцию (4 байта) меньше.
И push/pop нет совсем.


вот я этого и добивался!
я не знаю как там IAR и иже с ними, но если для GCC код С писать c пониманием во что и как это переваривается - можно недетски оптимизатору помочь. Но.. для этого нада спецнавыки и знания навыки.

2_dimka76
седня-завтра пересоберу выложу.


2_All_кому_нада _avr
ктонить тыкнет носом в патч который avr-size заставляет знать размеры ОЗУ и FLASH микросхем. лень искать и лень самому писать.
Andrew2000
Цитата(klen)
вот я этого и добивался!

выкладывайте, пожалуйста, линуксячие сборки (32бит) - раз уж все равно собираете...
klen
Цитата(Andrew2000 @ Dec 2 2009, 14:42) *
выкладывайте, пожалуйста, линуксячие сборки (32бит) - раз уж все равно собираете...

я 64битные собираю. 32битные не кашерно. Это сильно старый комп должен быть чтоб на него нельзя было поставить 64биный линукс.
faa
Цитата(klen @ Dec 2 2009, 15:11) *
я 64битные собираю.

А где?
На http://www.klen.org/Files/DevTools/ ошибка 403.
klen
Цитата(faa @ Dec 2 2009, 16:52) *
А где?
На http://www.klen.org/Files/DevTools/ ошибка 403.

во первых их там еще нет. я их собираю но не складываю туда.
во вторых у Вас нет прав на просмотр www.klen.org/Files/DevTools

при следеющей пересборке выложу линуксовую сборку.
Andrew2000
Цитата(klen @ Dec 2 2009, 15:11) *
Это сильно старый комп должен быть чтоб на него нельзя было поставить 64биный линукс.

да, старенький;
тогда, если не сложно, архив Ваших src, или изменения относительно оригинальных исходников, ну или краткую инструкцию по сборке (я уже спрашивал через личку - не пришло сообщение?).
(хотя, жаль что нет 32бит - уж больно долго все это добро собирается)
klen
Цитата(Andrew2000 @ Dec 2 2009, 20:19) *
да, старенький;
тогда, если не сложно, архив Ваших src, или изменения относительно оригинальных исходников, ну или краткую инструкцию по сборке (я уже спрашивал через личку - не пришло сообщение?).
(хотя, жаль что нет 32бит - уж больно долго все это добро собирается)

все что я правил уже в транке, я с транка собираю
http://gcc.gnu.org/svn.html
Andrew2000
Цитата(klen @ Dec 2 2009, 23:42) *
все что я правил уже в транке, я с транка собираю
http://gcc.gnu.org/svn.html

еще вопросы:
- в gcc/config/arm/t-arm-elf какие-нить изменения вносите для полного мультилиба?
- gmp- и mpfr- нужно скачивать отдельно, или они вообще не нужны?
faa
Цитата(klen @ Dec 2 2009, 20:10) *
при следеющей пересборке выложу линуксовую сборку.

Если Вас не затруднит. И очень желательно бы с исходниками.
А если все будет еще и скриптами обернуто, как, например, в crunch-tools/cross-tool/buildroot/ptxdist/oe и т.п. (специфические патчи, откуда брать исходники и скрипты для сборки).
А то пока со всех ресурсов все соберешь в кучу - столько времени и сил уходит smile.gif
Причем, прекрасно знаешь/понимаешь, что кто-то это уже сделал или делает в этот же момент либо занят чем-то другим и ждет, кто быстрее его патч прикрутит к более свежей версии, если этот патч в транк/бранч не вошел.
ЗЫ: Машины линуксовые есть - и 32 и 64. Можно хоть каждую ночь собирать на автомате.
klen
свежак для avr
www.klen.org/Files/DevTools/kgp_avr_20091202_i686-pc-mingw32.7z

1. Исходники ко всему берутся из cvs репозиториев (binutils,gdb,avr-libc,newlib), svn trunk для gcc, поэтому Вы сами можете их и без меня забрать.
2. скрипта сборки у меня нет. делаю все руками.
3. по поводу сборки для линукс. пока ниче не получится. потому что тулсы тянут кучу системных и сторонних (пересобранных мной) либ. если их тупо скопировать хрен это заработает.
в следующий раз попытаюсь скомпилять тулсы статически. если получится то буду выкладывать. сейчас к примеру сс1 тянет
klen@klen-dev:/opt/kgp_avr/libexec/gcc/avr/4.5.0$ ldd /opt/kgp_arm_eabi/libexec/gcc/arm-kgp-eabi/4.5.0/cc1plus
linux-vdso.so.1 => (0x00007fff043ff000)
libcloog.so.0 => /opt/kgp_linux64/lib/libcloog.so.0 (0x00007fa56c78e000)
libppl_c.so.2 => /opt/kgp_linux64/lib/libppl_c.so.2 (0x00007fa56c242000)
libppl.so.7 => /opt/kgp_linux64/lib/libppl.so.7 (0x00007fa56bf7a000)
libgmpxx.so.4 => /opt/kgp_linux64/lib/libgmpxx.so.4 (0x00007fa56bd76000)
libmpfr.so.1 => /opt/kgp_linux64/lib/libmpfr.so.1 (0x00007fa56bb27000)
libgmp.so.3 => /opt/kgp_linux64/lib/libgmp.so.3 (0x00007fa56b8ca000)
libdl.so.2 => /lib/libdl.so.2 (0x00007fa56b6c6000)
libelf.so.0 => /opt/kgp_linux64/lib/libelf.so.0 (0x00007fa56cb97000)
libc.so.6 => /lib/libc.so.6 (0x00007fa56b357000)
libstdc++.so.6 => /opt/kgp_linux64/lib/libstdc++.so.6 (0x00007fa56b030000)
libm.so.6 => /lib/libm.so.6 (0x00007fa56adac000)
libgcc_s.so.1 => /opt/kgp_linux64/lib/libgcc_s.so.1 (0x00007fa56ab95000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa56c9b0000)

4. mpfr и gmp необходимы для сборки gcc, если их нет gcc не соберется
http://gcc.gnu.org/install/prerequisites.html здесь написано что необходимо.
Вы должные скачать готовые либы и ниделы для своей платформы или скачать исходники их собрать.

5. мануал я писать как собирать все это барохло я не буду. никаких ''сИкретов" нет. все патчи уже содержатся в trunk.
dimka76
Цитата(klen @ Dec 3 2009, 17:38) *
свежак для avr
www.klen.org/Files/DevTools/kgp_avr_20091202_i686-pc-mingw32.7z


Вы свою сборку с WinAVR не сравнивали ?
Например, на предмет оптимальности получаемого кода.
klen
Цитата(dimka76 @ Dec 4 2009, 08:47) *
Вы свою сборку с WinAVR не сравнивали ?
Например, на предмет оптимальности получаемого кода.


неа, уверен Вы сравните и раскажете. А че? плохой код выдает?
а что такое "оптимальный получаймый код" я незнаю ? скорость, компактность, объем потребного озу, скорость кодогенерации. это все взаимоисключающие критерии. какой из них для Вас "оптимальный" smile.gif Вот например для индусов оптимальный код - тот который написан за один час и имеет 1000 строк кода и похер как работает.

для меня "оптимальный получаймый код" - быстрые циклы ручками на асме, прарывания жЁско на асме, все остальное С-код GCC по любому пережует неплохо. Главное чтоб глюков небыло.
dimka76
Цитата(klen @ Dec 4 2009, 12:29) *
а что такое "оптимальный получаймый код" я незнаю ?


это - скорость, компактность, объем потребного озу, скорость кодогенерации в одном флаконе biggrin.gif

просто если все (и вы и создатели WinAVR, в том числе) собирают из одних исходников, то какая разница.
этот вопрос и для ARM(ов) справедлив.
klen
Цитата(dimka76 @ Dec 4 2009, 12:56) *
это - скорость, компактность, объем потребного озу, скорость кодогенерации в одном флаконе biggrin.gif

просто если все (и вы и создатели WinAVR, в том числе) собирают из одних исходников, то какая разница.
этот вопрос и для ARM(ов) справедлив.


разница есть и их 2 штуки минимум.
1. сам компиллер и библиотеки можно собирать с мулионом вариантов 0пций компиляции и получить разный выходной бинарный код. исходнички то одни ....
2. я компиляю свежие исходники с оперативными изменеиями, которые в релизы еще не вошли. WinAVR раз в год опоросяеццо... или реже? исходнички то разные ....

но по большому счету наверно в 99% проектов это незаметно. для энтузиастов-исследователей интересно поглядеть какой на выходе асм , а просто разработчиком это паралельно
Andrew2000
2 klen
Спасибо за ответы!
остался без внимания вопрос:
- в gcc/config/arm/t-arm-elf какие-нить изменения вносите для полного мультилиба?
klen
"полный" это относительное понятие
модете еще дораскоментировать некоторве секции

Код
# For most CPUs we have an assembly soft-float implementations.
# However this is not true for ARMv6M.  Here we want to use the soft-fp C
# implementation.  The soft-fp code is only build for ARMv6M.  This pulls
# in the asm implementation for other CPUs.
LIB1ASMFUNCS += _udivsi3 _divsi3 _umodsi3 _modsi3 _dvmd_tls _bb_init_func \
    _call_via_rX _interwork_call_via_rX \
    _lshrdi3 _ashrdi3 _ashldi3 \
    _arm_negdf2 _arm_addsubdf3 _arm_muldivdf3 _arm_cmpdf2 _arm_unorddf2 \
    _arm_fixdfsi _arm_fixunsdfsi \
    _arm_truncdfsf2 _arm_negsf2 _arm_addsubsf3 _arm_muldivsf3 \
    _arm_cmpsf2 _arm_unordsf2 _arm_fixsfsi _arm_fixunssfsi \
    _arm_floatdidf _arm_floatdisf _arm_floatundidf _arm_floatundisf \
    _clzsi2 _clzdi2

MULTILIB_OPTIONS     = marm/mthumb
MULTILIB_DIRNAMES    = arm thumb
MULTILIB_EXCEPTIONS  =
MULTILIB_MATCHES     =

MULTILIB_OPTIONS      += march=armv7
MULTILIB_DIRNAMES     += armv7
MULTILIB_EXCEPTIONS   += march=armv7* marm/*march=armv7*
MULTILIB_MATCHES      += march?armv7=march?armv7-a
MULTILIB_MATCHES      += march?armv7=march?armv7-r
MULTILIB_MATCHES      += march?armv7=march?armv7-m
MULTILIB_MATCHES      += march?armv7=mcpu?cortex-a8
MULTILIB_MATCHES      += march?armv7=mcpu?cortex-r4

MULTILIB_OPTIONS      += mcpu=cortex-m3
MULTILIB_DIRNAMES     += cortex-m3
MULTILIB_EXCEPTIONS   += mcpu=cortex-m3* *march=armv7*/mcpu=cortex-m3*  marm/*mcpu=cortex-m3*
MULTILIB_MATCHES      += mcpu?cortex-m3=mtune?cortex-m3


# Not quite true.  We can support hard-vfp calling in Thumb2, but how do we
# express that here?  Also, we really need architecture v5e or later
# (mcrr etc).
#MULTILIB_OPTIONS       += mfloat-abi=hard
#MULTILIB_DIRNAMES      += fpu
#MULTILIB_EXCEPTIONS    += *mthumb/*mfloat-abi=hard*

# MULTILIB_OPTIONS    += mcpu=ep9312
# MULTILIB_DIRNAMES   += ep9312
# MULTILIB_EXCEPTIONS += *mthumb/*mcpu=ep9312*
#     
#MULTILIB_OPTIONS     += mlittle-endian/mbig-endian
#MULTILIB_DIRNAMES    += le be
#MULTILIB_MATCHES     += mbig-endian=mbe mlittle-endian=mle
#
#MULTILIB_OPTIONS    += mhard-float/msoft-float
#MULTILIB_DIRNAMES   += fpu soft
#MULTILIB_EXCEPTIONS += *mthumb/*mhard-float*
#
MULTILIB_OPTIONS    += mno-thumb-interwork/mthumb-interwork
MULTILIB_DIRNAMES   += normal interwork
#
# MULTILIB_OPTIONS    += fno-leading-underscore/fleading-underscore
# MULTILIB_DIRNAMES   += elf under
#
# MULTILIB_OPTIONS    += mcpu=arm7
# MULTILIB_DIRNAMES   += nofmult
# MULTILIB_EXCEPTIONS += *mthumb*/*mcpu=arm7*
# # Note: the multilib_exceptions matches both -mthumb and
# # -mthumb-interwork
# #
# # We have to match all the arm cpu variants which do not have the
# # multiply instruction and treat them as if the user had specified
# # -mcpu=arm7.  Note that in the following the ? is interpreted as
# # an = for the purposes of matching command line options.
# # FIXME: There ought to be a better way to do this.
# MULTILIB_MATCHES    += mcpu?arm7=mcpu?arm7d
# MULTILIB_MATCHES    += mcpu?arm7=mcpu?arm7di
# MULTILIB_MATCHES    += mcpu?arm7=mcpu?arm70
# MULTILIB_MATCHES    += mcpu?arm7=mcpu?arm700
# MULTILIB_MATCHES    += mcpu?arm7=mcpu?arm700i
# MULTILIB_MATCHES    += mcpu?arm7=mcpu?arm710
# MULTILIB_MATCHES    += mcpu?arm7=mcpu?arm710c
# MULTILIB_MATCHES    += mcpu?arm7=mcpu?arm7100
# MULTILIB_MATCHES    += mcpu?arm7=mcpu?arm7500
# MULTILIB_MATCHES    += mcpu?arm7=mcpu?arm7500fe
# MULTILIB_MATCHES    += mcpu?arm7=mcpu?arm6
# MULTILIB_MATCHES    += mcpu?arm7=mcpu?arm60
# MULTILIB_MATCHES    += mcpu?arm7=mcpu?arm600
# MULTILIB_MATCHES    += mcpu?arm7=mcpu?arm610
# MULTILIB_MATCHES    += mcpu?arm7=mcpu?arm620

EXTRA_MULTILIB_PARTS = crtbegin.o crtend.o crti.o crtn.o

# If EXTRA_MULTILIB_PARTS is not defined above then define EXTRA_PARTS here
# EXTRA_PARTS = crtbegin.o crtend.o crti.o crtn.o

LIBGCC = stmp-multilib
INSTALL_LIBGCC = install-multilib

# Currently there is a bug somewhere in GCC's alias analysis
# or scheduling code that is breaking _fpmul_parts in fp-bit.c.
# Disabling function inlining is a workaround for this problem.
TARGET_LIBGCC2_CFLAGS = -fno-inline

# Assemble startup files.
$(T)crti.o: $(srcdir)/config/arm/crti.asm $(GCC_PASSES)
    $(GCC_FOR_TARGET) $(GCC_CFLAGS) $(MULTILIB_CFLAGS) $(INCLUDES) \
    -c -o $(T)crti.o -x assembler-with-cpp $(srcdir)/config/arm/crti.asm

$(T)crtn.o: $(srcdir)/config/arm/crtn.asm $(GCC_PASSES)
    $(GCC_FOR_TARGET) $(GCC_CFLAGS) $(MULTILIB_CFLAGS) $(INCLUDES) \
    -c -o $(T)crtn.o -x assembler-with-cpp $(srcdir)/config/arm/crtn.asm
Andrew2000
Цитата(klen @ Dec 8 2009, 18:09) *
"полный" это относительное понятие

Спасибо!
ReAl
Цитата(klen @ Dec 2 2009, 12:06) *
2_All_кому_нада _avr
ктонить тыкнет носом в патч который avr-size заставляет знать размеры ОЗУ и FLASH микросхем. лень искать и лень самому писать.

https://winavr.svn.sourceforge.net/svnroot/...-avr-size.patch
klen
Цитата(ReAl @ Dec 16 2009, 22:13) *

спасибо. при следующей сборке постараюсь прикрутить.
klen
с замиранием дыхания констатирую окончание "праздников", с чем и поздравляю, неее.. ребята, с этим нада что то делать. так мы новое прекрасное общество с таким календарем не построим


итак, оправившись от тяжелейшего отдыха, сравнимого по воздействию на организм с жеским стресом, выкатываю свежую сборку для мелкоармов
http://www.klen.org/Files/DevTools/kgp_arm_eabi_20100119.7z
оставлен GDB 6.8, новый 7.0-ой тоже есть, но c ним есть эклипс регистры не кажет - перцы из eclipse.org тупят и не патчат CTD+JTAG/gdb плагины.
должен сказать что openocd растет как на дрожжах - позитиф! за месяц нового много функционала.

собрал сборку под мипсы с ньюлибом. нада комунить?

для авыэров будет пожже. хочу закрыть все накопившиеся вопросы с avr32, atxmega, avr-size
AHTOXA
Цитата(klen @ Jan 25 2010, 00:21) *
выкатываю свежую сборку для мелкоармов
http://www.klen.org/Files/DevTools/kgp_arm_eabi_20100119.7z


Ура!

Но... чего-то не хватаетsmile.gif

  • cc1plus.exe -- хочет отсутствующую libstdc++-6.dll;
  • make --version молча завершается;
  • sh тоже молча завершается;
  • openocd хочет libusb0.dll.
Первое критично, остальное пофигsmile.gif
inco
Тоже подтверждаю. Версия не рабочая. Проект собранный на версии kgp_arm_eabi_20091127 с новой версией не собирается! Ассемблерные файлы не компилируются (startup) и на файлы c++ тоже ругается.
klen
завтра (тоесть утром) починим.
про libstdc++-6.dll я сам уже заметил. перенес на другой комп.

2_inco
а дайте этот асмовый файл, я погляжу про че там ругаеццо.

тем немение этой сборкой собрал проетик с stm32f107vct + rtl8201cp + uIP , заработало! это первое мое железо с эзернетом. зайти броузером на платку и выставить светодиоды - это приятно.

зы. яж выше писал - выход из праздников вещь тяяяжелоая cranky.gif
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.