Просмотр полной версии : Бага SDCC версии 3.3.0
Обрадовалася душа, что такой весь сабж хороший, давай думаю его наконец заюзаю. Не прошло и полчаса, как наступил на багу.
char i;
void main(void)
{
i = 0;
while (1)
i = (i == 3) ? 0 : (i + 1);
}
Свежайшая версия 3.3.0 компилирует вот в это:
_main:
;1.c:9: i = 0;
ld hl,#_i + 0
ld (hl), #0x00
;1.c:11: while (1)
00102$:
;1.c:13: i = (i == 3) ? 0 : (i + 1);
ld a,(#_i + 0)
cp a,#0x03
jr Z,00107$
inc a
00107$:
ld (#_i + 0),a
jr 00102$
Я думаю, комментировать не надо.
ИЧСХ, проверил на версии 2.9.0 (та, которая в шыру-СДК):
_main:
;1.c:9: i = 0;
ld hl,#_i + 0
ld (hl), #0x00
;1.c:11: while (1)
00102$:
;1.c:13: i = (i == 3) ? 0 : (i + 1);
ld a,(#_i+0)
sub a,#0x03
jr NZ,00106$
ld c,#0x00
jr 00107$
00106$:
ld hl,#_i + 0
ld c,(hl)
inc c
00107$:
ld hl,#_i + 0
ld (hl), c
jr 00102$
Предлагается найти 100500 отличий.
Cвежая версия делает намного более вменяемый код. Но пропустить ТАКУЮ багу...
Ладно бы код был какой экзотичный. И что интересно: если написать например:
i = (i == 3) ? 1 : (i + 1);
то получится уже вот так:
ld a,(#_i + 0)
sub a, #0x03 ; <-- !!!!!!!!!!!!!!!!!
jr NZ,00106$
ld a,#0x01
jr 00107$
00106$:
ld a,(#_i + 0)
inc a
00107$:
ld (#_i + 0),a
Перепутали CP и SUB, бида бида...
---------- Post added at 03:57 ---------- Previous post was at 03:51 ----------
Проверил: присутствует в версиях 3.2.0 и 3.1.0 Нету в версии 3.0.0, но она генерит такую же капусту, как и 2.9.0.
Это лучше сюда http://sourceforge.net/p/sdcc/bugs/
Уже.
Но я полагаю, сообщить народу не повредит.
crazy_bender/ex-PLACEBO
26.09.2013, 07:51
а где бы взять готовую сборку?
Сборку чего?
---------- Post added at 06:05 ---------- Previous post was at 05:55 ----------
О, ответили:
It looks like a peephole rule problem. When compiled with --no-peep the resulting assembly looks correct to me.
Действительно, опция --no-peep генерит:
ld iy,#_i
ld a,0 (iy)
sub a, #0x03
jp NZ,00108$
jp 00109$
00108$:
jp 00103$
00109$:
ld a,#0x00
jp 00104$
00103$:
ld iy,#_i
ld a,0 (iy)
inc a
00104$:
ld iy,#_i
ld 0 (iy),a
Ну, то есть peephole не работает, и старая лапша.
Error404
26.09.2013, 09:44
SDCC исторически насквозь кривой. Особенно если пользуешься чем-то кроме простых операций. Я забил им пользоваться. Поскольку компилю большие проекты, искать потом в десятке тысяч строк почему рабочий код после SDCC не работает - нунафиг.
perestoronin
26.09.2013, 09:52
почему рабочий код после SDCC не работает
Если ПО не править, то оно так и останется бажным, я то ПО что мне нужно правлю, чего и всем рекомендую, не чего халяву ловить, надо и самим хотя бы капельку своего труда вложить в открытое ПО.
Error404
26.09.2013, 12:34
Если ПО не править, то оно так и останется бажным, я то ПО что мне нужно правлю, чего и всем рекомендую, не чего халяву ловить, надо и самим хотя бы капельку своего труда вложить в открытое ПО.
SDCC это как жигули: то уши мерзнут, то хвост отваливается, бесконечная история ловли глюков. А жизнь одна. Нафиг. Тем более это не лучший компилятор ни по коду ни по быстродействию, и на реале не работает.
Я вот никакого кайфа от правки инструментария не имею вообще. Другое дело, писать что-то прикладное.
Если ПО не править, то оно так и останется бажным, я то ПО что мне нужно правлю, чего и всем рекомендую
есть еще такая поговорка: из говна конфетку не сделать. если идеология кривая, можешь ее всю костылями увешать, она все равно будет падать то тут, то там.
Это лучше сюда http://sourceforge.net/p/sdcc/bugs/
Во-во причем все люди нормальные так и делают.
[
TSL, перенеси все баги из баг списка. И везде пропиши "Перепутали X и Y, бида бида...".
И в каждой ветке ответят, "кривой.. кривой.."
:)
]
Во-во причем все люди нормальные так и делают.
или только те, кто "болеет" за проект. я, например, прохожу мимо таких проектов (а вот побурчать на форуме могу, а для чего? а для того, чтобы если кто-то когда-то будет стоять перед выбором инструмента - знал, что он кривой, а этот - он не временно кривой, он вообще кривой). вменяемым и полезным для меня проектам - помогаю в меру сил, в т.ч. и готовым кодом.
SDCC исторически насквозь кривой. Особенно если пользуешься чем-то кроме простых операций. Я забил им пользоваться. Поскольку компилю большие проекты, искать потом в десятке тысяч строк почему рабочий код после SDCC не работает - нунафиг.
Чем ты компилишь ?
Там реально багов меньше ?
Error404
26.09.2013, 17:27
Чем ты компилишь ?
Там реально багов меньше ?
Поскольку мне не интересна кросплатформенность единого компилятора, а только код для Z80, то я до сих пор пользуюсь Hitech C выпущенным в 1988 году (на секундочку, 25 лет назад!) в версии для CP/M. Там есть несколько багов компилятора (буквально два), но они обходятся. И новых не будет, т.е. не будет сюрпризов, а именно непредсказуемость бесит, что каждый раз жопа, и каждый раз с новой версией SDCC - в новом месте кода. Код получаемый на выходе Hitech C на 25% меньше чем лучший результат у SDCC (по состоянию моего крайнего подхода к SDCC год назад). Так это я еще специально для SDCC в исходник кучу тупекастов добавил, чтобы он переменные не столь дебильно размещал и инициализировал, как он обычно это делает. А то бы там была не 25%, а все 100% (т.е. в пару раз) разница по весу кода.
Ничего лучше из официально бесплатного чем Hitech C пока не нашел. Жду чем закончится проект gcc+LLVM из соседнего треда - все же какой-то компилер в код Z80 на платформе РС нужен.
SDCC исторически насквозь кривой.
если идеология кривая, можешь ее всю костылями увешать, она все равно будет падать то тут, то там.
А можно немножко подробностей? Ради повышения уровня образованности:) Не смотрел его исходы, посему собственного мнения не имею.
Error404
26.09.2013, 17:41
А можно немножко подробностей? Ради повышения уровня образованности:) Не смотрел его исходы, посему собственного мнения не имею.
Я с примерами кода сейчас аргументировать не могу: не хранил примеры с косяками SDCC. Но неоднократно в разные годы на разных версиях SDCC пытался собирать им работоспособные проекты (которые собирает Hitech C), обламывался, и твердил nevermore. :) И все же потом опять пробовал и жег нервные клетки. Нет, я не спорю, возможно проект без сложных конструкций мало-помалу написанный изначально в SDCC c регулярной правкой глюков, он как-то живет и компилируется (хотя судя по старттопику - не всегда), но это не мой случай.
Я с примерами кода сейчас аргументировать не могу: не хранил примеры с косяками SDCC. Но неоднократно в разные годы на разных версиях SDCC пытался собирать им работоспособные проекты (которые собирает Hitech C), обламывался, и твердил nevermore. И все же потом опять пробовал и жег нервные клетки. Нет, я не спорю, возможно проект без сложных конструкций мало-помалу написанный изначально в SDCC c регулярной правкой глюков, он как-то живет и компилируется (хотя судя по старттопику - не всегда), но это не мой случай.
Не, меня интересуют больше внутренности компилятора, его идеология. Хочется узнать что там считается кривым.
Не, меня интересуют больше внутренности компилятора, его идеология. Хочется узнать что там считается кривым.
самое кривое, что бросается в глаза - peephole optimization через найти и заменить по тексту. ассемблер они тоже применяют кривой, но это дело вкуса (такого отвратительного вкуса я не видел еще).
самое кривое, что бросается в глаза - peephole optimization через найти и заменить по тексту.
Имхо, имеет право на существование. Другое дело что это, похоже, единственная оптимизация:)
А еще что?
Имхо, имеет право на существование.
ясное дело, что лучше с ней, чем без нее, но это по своей сути мега костыль.
Другое дело что это, похоже, единственная оптимизация
емнип, у них еще что-то есть из традиционного, но это не помогает быть оптимальным...
А еще что?
в целом - мне уже хватает. инструмент должен быть как минимум стабильным.
Error404
Согласен, количество багов в нем с трудом компенсируется энтузиазмом разработчиков. Код, кстати, даже с включенным пипом на 5% жырнее, чем у ИАР-а. Печально.
Багу пофиксали между прочим. Уже.
Valen
Расскажи мне про багтрекеры и про нормальных людей. Можешь еще рассказать про системы контроля версий. Если еще есть чего рассказать - рассказывай.
NovaStorm
26.09.2013, 21:13
Error404, а то, что Hitech C - дикий диалект K&R времён компьютерных динозавров, и даже на C89 не тянет, в расчёт не берём?
Я пока пользуюсь ИАРом, точнее ничем не пользуюсь, потому что под зетник почти не пишу. Но: пока иаровский проект настроишь, можно яйца высидеть, а асм там - это вообще *censored*, начать с того, что он не инлайнится в принципе, нужно собирать асмом из отдельного сорца и линковать. Но код выходит сравнительно нежирный.
Кстати, я и в нем багу нашел на максимальном уровне оптимизации.
Error404
26.09.2013, 22:25
Error404, а то, что Hitech C - дикий диалект K&R времён компьютерных динозавров, и даже на C89 не тянет, в расчёт не берём?
C чего это дикий диалект? ANSI C дикий диалект? Или "не читал, но осуждаю"? Пускай и не С89 (еще бы, в 88 то году выпуска), но оно многие написанные на ANSI C вещи компилит и работает, а SDCC - компилит, но не работает.
NovaStorm
26.09.2013, 22:43
Что скажет на main(){printf("Hello, world\n");} hitech, и что современный компилятор?
Хотя против "компилит и _работает_" не попрёшь =)
Error404
27.09.2013, 00:19
Что скажет на main(){printf("Hello, world\n");} hitech, и что современный компилятор?
Хотя против "компилит и _работает_" не попрёшь =)
Скажет "done". И что? :) Ты сам дофига накомпилил, умничаешь тут? Чего хочешь доказать? Уровень моей аргументации не устраивает? Другой не будет. :)
Обычный printf для любого компилера з80 - это 3-4кБ кода со старта. Даже не обсуждаемо, никогда его не юзаю.
NovaStorm
27.09.2013, 08:58
>Скажет "done". И что?
gcc выдал пачку ворнингов...
>Ты сам дофига накомпилил, умничаешь тут? Чего хочешь доказать?
Для Z80 - ничего, всё асмом как-то. Да и доказывать что-то желанием не горю, просто на SDCC такой ор подняли, что кажется записали его авторов в личные враги. Чем мешает развитие(а он таки развивается) этого проекта нашим товарищам ретроградам - непонятно =)
ЗЫ:z80 target для llvm мне тоже интересен.
или только те, кто "болеет" за проект. я, например, прохожу мимо таких проектов (а вот побурчать на форуме могу, а для чего? а для того, чтобы если кто-то когда-то будет стоять перед выбором инструмента - знал, что он кривой, а этот - он не временно кривой, он вообще кривой). вменяемым и полезным для меня проектам - помогаю в меру сил, в т.ч. и готовым кодом.
Люди делятся на две категории: одни ищут возможности, другие ищут причины.
Вот Ширу искал возможности, и создал на базе SDCC среду разработки для ZX-Evolution. С её помощью уже создано портировано несколько проектов из исходников на Си.
К примеру, некто Sergey78 чуть ли не в течение суток после появления открытых исходников делает порт на ZX-Evo. Он тоже ищет возможности, а не причины, чтобы ничего не делать, и не переливает из пустого в порожнее как базарные бабы.
И, к слову, если бы они прислушались к таким "умникам" и "доброжелателям" как ты, то не было бы у нас сейчас ни SDK, ни новых игр: Uwol, Robo, Innsmouth, XNX, AlterEgo...
Воистину говорят, благими намерениями устлана дорога в ад.
Для Z80 - ничего, всё асмом как-то.
т.е., я сам не юзаю, не юзал и не собираюсь, но не понимаю, что вам не нравится:)) надо было юзать и потом уже делать выводы какие-то.
Вот Ширу искал возможности, и создал на базе SDCC среду разработки для ZX-Evolution. С её помощью уже создано портировано несколько проектов из исходников на Си.
и что это доказывает? люди на асме выкручиваются, херачат что-то сложное. на sdcc тоже придется выкручиваться и иметь какие-то странные проблемы, в то время как призвание си - оградить человека от низкоуровневых проблем. не должно даже мысли возникать, например, смотреть листинги. sdcc решает эту задачу отвратительно.
то, что кто-то с помощью кривого инструмента добился-таки результатов - не отменяет кривость инструмента.
и про портирование как бы мимо. портировать - это не заново написать (или, что главное, взять чужое написанное и применить!), кода там меняется не сильно много. а вот когда ты с нуля начнешь, да будешь брать чужой, не адаптированный под sdcc код, натрахаешься всласть. а потом, кто через это не проходил, будет говорить: а вон смотрите, чел взял и сделал, оставляя за кадром весь негатив.
NovaStorm
27.09.2013, 13:27
>т.е., я сам не юзаю, не юзал и не собираюсь
Я всё-таки собирался и пробовал всякие hello world'ы, но ассемблер для моих потребностей оказался гораздо более адекватным средством.
Valen
Расскажи мне про багтрекеры и про нормальных людей. Можешь еще рассказать про системы контроля версий. Если еще есть чего рассказать - рассказывай.
Гы, не обольщайся насчет нормальных людей: похоже, в ихнем ПТУ уроков этики не было. :)
Далан.... :) Я завсегда готов подраться ))) Был бы повод )
Мужики, а кто-нибудь раскурил, как с sdobjcopy работать? Мне надо из .bin-файла получить .rel, который потом можно прилинковать выходному результату.
$ sdobjcopy.exe -I binary -O asxxxx font.bin font.rel
sdobjcopy.exe:font.rel[.data]: File format not recognized
sdobjcopy.exe:font.rel: Invalid operation
$ sdobjcopy.exe -B z80 -I binary -O asxxxx font.bin font.rel
sdobjcopy.exe: architecture z80 unknown
В прочих направлениях (binary -> ihex etc) работает нормально.
Мужики, а кто-нибудь раскурил, как с sdobjcopy работать? Мне надо из .bin-файла получить .rel, который потом можно прилинковать выходному результату.
Именно с sdobjcopy не сталкивался.
Но если нужно именно бинарный файл вставить в прогу, то
- сгенерить из бинарника, файл Си с массивом, содержащем байты бинарника (xxd утилита в линухе)
- включить сгенеренный Си файл в компиляцию своей проги
Но если нужно именно бинарный файл вставить в прогу, то
- сгенерить из бинарника, файл Си с массивом, содержащем байты бинарника (xxd утилита в линухе)
- включить сгенеренный Си файл в компиляцию своей проги
Да, это я знаю. Но хочется чуть более коротким путем :)
...Мне надо из .bin-файла получить .rel, который потом можно прилинковать выходному результату.
Маленько покурив тему, пришел к выводу, что прога работает правильно. Просто мы по наивности думаем, что под "binary" понимается обычный файл двоичных данных. Ан нет. Здесь binary - двоичный файл в BFD-формате, т.е. с каким-то хитрым заголовком. Можно попробовать узнать этот формат и написать простенький конвертер под DOS и батником потом всё автоматизировать.
Просто мы по наивности думаем, что под "binary" понимается обычный файл двоичных данных. Ан нет. Здесь binary - двоичный файл в BFD-формате, т.е. с каким-то хитрым заголовком.
Неа, binary - это именно raw. Это всякие coff/xcoff/elf/etc - с заголовком.
Скажем, берем binutils-z80, ассемблируем сорец из единственного RET, и проверяем
file.s:
.section .text
ret
собираем и смотрим, что получилось
$ z80-unknown-coff-as file.s -o file.coff
$ z80-unknown-coff-objcopy -j .text -O binary file.coff file.bin
$ hd file.bin
В результате видим, что бинарник получился длиной в один байт - C9
00000000 c9 |.|
00000001
То, что sdobjcopy работает не так - это, наверное, всё же баг. Она же не зря так называется, в неё совместимость на уровне параметров командной строки с оригиналом из binutils должна быть заложена.
То, что sdobjcopy работает не так - это, наверное, всё же баг. Она же не зря так называется, в неё совместимость на уровне параметров командной строки с оригиналом из binutils должна быть заложена.
Ну что тут скажешь... Надо по линуксом конвертить тады. :)
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot