| Author |
Message |
|
Written on: 20. 09. 2010 [12:53]
|
|
Expert
Владимир Тихонов
registered since: 05.08.2008
Posts: 45
|
"almaz" wrote:
1:45 не рекорд для ARM 1.2ГГц. На самом деле ОС работает с флэшкой при компиляции. Читает библиотеки, утилиты и т.д. С быстрым жёстким диском время должно ещё уменьшиться...
ну ждем результатов, такими темпами на арм по тихому можно контроллеры переводить))) Недавно баловался с гуруплюг, знакомый использует в качестве хоумсервера.
Все глюки Windows исправляются установкой Linux
|
|
Written on: 14. 11. 2010 [20:02]
|
|
fido_max
Maxim Kochetkov
Contributor
registered since: 28.10.2010
Posts: 129
|
Я пытаюсь кросскомпилировать опенскаду под АРМ. Компиляция проходит (с некоторыми отключенными модулями), работают даже транспорты и интерфейсы пользователя. Но есть проблема с JavaLikeCalc. При попытке запустить любую из функций все рушится с сегфолтом. Нарыл, что падает в том месте, где начинает разбираться байт-код. Посему вопрос: это байт-код кривой получился, или он выполняется криво? Судя по отладочным сообщениям он пытается писать в 106 регистр, а у этой функции их всего два. Просьба к тем, кто собирал скаду непосредственно на АРМе: дайте пожалуйста файлик daq_JavaLikeCalc_la-func_analise.cpp (или как-то так), он лежит в src\moduls\daq\JavaLikeCalc. Я так понимаю, что он генерится бизоном в момент компиляции скады? Есть подозрение, что он не правильный получился.
|
|
Written on: 15. 11. 2010 [15:46]
|
|
fido_max
Maxim Kochetkov
Contributor
registered since: 28.10.2010
Posts: 129
|
Сегодня изучал байт-код, который получается после компилятора JavaScript и его последующее выполнение. Генерируется он вроде правильно, но при его выполнении есть один нехороший момент:
На команду там отводится один байт, потом идут адреса регистров (по два байта) и собственно данные. Так вот, получается, что адрес регистра у первой команды лежит в первом байте программы (в нулевом находится код команды), а у процессор АРМ не может читать два байта из памяти по нечетному адресу (не выровненные). Самый простой выход из этой ситуации - сделать так, чтобы компилятор генерил байт-код где команда занимает два байта, а не один. Ну или переписывать полностью процедуру выполнения байт-кода. Хотя в случае с двумя байтами на команду, нужно будет еще следить за тем, чтобы размер всех переменных был четным.
Вопрос к Роману: как лучше поступить? Если по простому пути, то где это указать?
|
|
Written on: 15. 11. 2010 [16:44]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"fido_max" wrote:
На команду там отводится один байт, потом идут адреса регистров (по два байта) и собственно данные. Так вот, получается, что адрес регистра у первой команды лежит в первом байте программы (в нулевом находится код команды), а у процессор АРМ не может читать два байта из памяти по нечетному адресу (не выровненные).
С чего Вы такое взяли? Там проблема скорее в порядка байтов в этом адресе, что типично для RISC. И именно эти проблемы нужно вылавливать при адаптации.
Learn, learn and learn better than work, work and work.
|
|
Written on: 15. 11. 2010 [17:05]
|
|
fido_max
Maxim Kochetkov
Contributor
registered since: 28.10.2010
Posts: 129
|
Для 80x86 - выравнивание пофигу.
А для ARM выравнивание - важно. Проц не может работать со словом, если оно не выровнено по границе 4 байт (2-х для 16-разрядного слова).
из exec:
for(int i=0; i<4; i++){
printf("%02x",(unsigned char)cprg[i]);
}
вывод:
0x04
0x01
0x00
0x00
Команда MviR в первый регистр
printf("%04x",*(uint16_t*)(cprg));
printf("%04x",*(uint16_t*)(cprg+1));
вывод:
0x0104
0x0104
Тут видимо компилятор GCC исправил ошибку выравнивания, чтобы процессор не упал в дата аборт.
Так что придется ровнять.
|
|
Written on: 15. 11. 2010 [17:45]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
Никто ничего тут выравнивать не будет. Скорее брать адрес побайтно прийдётся.
Хотя думаю для gcc должен быть ключ, обходящий эту проблему чтением побайтно. Например, "-zas1".
Learn, learn and learn better than work, work and work.
|
|
Written on: 15. 11. 2010 [22:37]
|
|
fido_max
Maxim Kochetkov
Contributor
registered since: 28.10.2010
Posts: 129
|
"roman" wrote:
Никто ничего тут выравнивать не будет. Скорее брать адрес побайтно прийдётся.
Да я впринципе и сам могу этим заняться.
"roman" wrote:
Хотя думаю для gcc должен быть ключ, обходящий эту проблему чтением побайтно. Например, "-zas1".
Можно попробовать. Завтра займусь этим.
Хотя вариант с выравниванием мне в идеале больше нравится.
Я же не требую это сделать. Я помочь хочу.
|
|
Written on: 16. 11. 2010 [09:57]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"fido_max" wrote:
Хотя вариант с выравниванием мне в идеале больше нравится.
Это только потому, что Вы всей глубины проблемы не видите.
Learn, learn and learn better than work, work and work.
|
|
Written on: 16. 11. 2010 [10:27]
|
|
fido_max
Maxim Kochetkov
Contributor
registered since: 28.10.2010
Posts: 129
|
"roman" wrote:
"fido_max" wrote:
Хотя вариант с выравниванием мне в идеале больше нравится.
Это только потому, что Вы всей глубины проблемы не видите.
Ну так просвятите.
Ксати -zas1 не работает. Не понимает компилятор такую опцию, а других подобных не нашел. :-(
|
|
Written on: 16. 11. 2010 [12:48]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"fido_max" wrote:
Ну так просвятите.
1. Потребует значительного изменения генератора байткода и его vm. Включая не только расширение поля команды, но и значений, например строк.
2. Не исключает проблему с чтением значений размером в 4байта(целое) и 8байт(двойное вещественное) или прийдётся выравнивать на 8 байт, но это просто не допустимо.
3. Приведёт к увеличению потребления памяти.
4. Это не то место где нужно заниматься выравниванием.
В результате ни усилия ни последующие проблемы здесь не окупятся.
Как вариант почитайте это http://netwinder.osuosl.org/users/b/brianbr/public_html/alignment.html , а затем попробуйте конкретно для vm использовать __attribute__((packed)).
Learn, learn and learn better than work, work and work.
|
