You are here
Баг в компиляторе СЕМИКО
Update. На сайте написали, что «ошибка .NUMT» исправлена в MKL2MKP v0.34 (23.03.19). Подтверждаю. MK.EXE пока без изменений.
Потратил сутки на выслеживание бага и отлов «чудовища» в его первозданном виде. Баг оказался не в моём творчестве, а в фирменном компиляторе, выложенном на официальном сайте НПП «СЕМИКО». Он присутствует как в MK.EXE 1.28 (последняя версия), так и MKL2MKP 0.32 (версию 0.33 не компилировал и не проверял).
С учётом непростого сибирского P.R. даже не представляю, куда в 2019 году сообщать об ошибках и недочётах в «Электронике МК», которую многие по началу восприняли, как национальную архитектуру. Выкладываю здесь, может дойдёт до Новосибирска по «сарафанному радио».
Вот такой код:
.ORG 0 KNOP .ORG 107 Label: KNOP .ORG 142 .NUMT Label ; 107 -> 1 7 KNOP .NUM Label ; 107 -> 1 0 7 KNOP .ENDP
Компилируется вот в такую жуть:
0000 54h K NOP ;T 0001 FFh FFh ; ... 0106 FFh FFh ; 0107 54h K NOP ;T 0108 FFh FFh ; ... 0141 FFh FFh ; 0142 01h 1 ; 0143 07h 7 ; 0144 54h K NOP ;T 0145 01h 1 ; 0146 00h 0 ; 0147 07h 7 ; 0148 54h K NOP ;T 0149 FFh FFh ; ... 0199 FFh FFh ; ; Контрольная сумма ADD 49057 ; Контрольная сумма XOR 255
Понятно, что адрес 107 ну никак нельзя заменять на адрес 17. Даже если это короче на один шаг. Такой же баг будет и просто для числа 107.
В теории можно повозиться с 0.33 и исправить «жучок» самостоятельно. Но пока этого никто не сделал, предлагаю не использовать .NUMT и перейти на .NUM, хотя он в некоторых случаях длиннее.
- AtH's blog
- Log in or register to post comments
- 8913 reads
Comments
Каллисто 1.0 — без ошибок
Каллисто Классик написана на MK.EXE, в её исходнике псевдооператор .NUMT был использован 9 раз, в строках 203, 342, 344, 348, 350, 432, 437, 2472 и 2495. Это адреса 0060, 0463, 0468, 0476, 0481, 0733, 0745, 5315 и 5375 соответственно.
Проверил результат компиляции вручную. Во всех 9 случаях .NUMT сработал верно. В двух последних случаях даже правильно сократил код до 2 и 1 шага.
Так что ошибка в фирменном компиляторе не привела к ошибкам в Каллисто 1.0
Новосибирские компиляторы создавали впечатление надёжных. Там есть, к чему придраться, но свою основную работу они всегда выполняли надёжно — компилируя даже такие большие проекты, как Каллисто. Был крайне удивлён, наткнувшись на такой подлый баг после стольких лет успешной работы с ними. Это первая и пока единственная критическая ошибка, выявленная мною в компиляторе за 10 лет надёжной работы.
MK.EXE против ардуинокомпилятора
Если критическая ошибка в компиляторе проявилась через десять лет и то в такой программе как компилятор "Каллисто", то это говорит только в пользу Новосибирска. Метод написания "Каллисто" на мой взгляд похож на написание игр для "Спектрума" - чтобы добиться приемлемой скорости работы изобретаются различные приёмы и комбинации. Так что неудивительно, что ошибка проявилась только у одного человека при компиляции весьма навороченного кода, при попытке втиснуть в 10000 шагов предельно возможного количества функций. Я думаю, "Семико" это простительно. Если исходники открыты - ничто не мешает выпустить свою версию МК.ЕХЕ независимой редакции :)
Вот когда я начал экспериментировать с ардуиной, я буквально за считанные дни наткнулся на неоднозначность компиляции - две строки с независимыми выражениями, наподобие а=(б+в); г=(д+е); При перемене на г=(д+е); а=(б+в); компиляция давала разный результат - микроконтроллер переставал правильно отрабатывать процедуру обработки нажатия кнопок. Я после этого сразу и без сожаления расстался с мыслью использовать ардуину даже в простом станке на заводе. Вот этот действительно подлый ардуинобаг при неосторожном применении ардуины в промышленности вполне мог силами бездушного механизма повредить рабочему или наладчику руку.
Я так одну свою промышленную поделку чуть не забраковал - при испытаниях самодельный контроллер работал неправильно, причиной были помехи от пускателя. Я пересчитал и переделал цепи опторазвязки под больший уровень помех - и контроллер заработал нормально не смотря на помехи, как и должно быть :)
Сайт
Ошибка в компиляторе. Не в МК-161 и не в Каллисто.
Повторюсь. Ошибок в Каллисто нет — по крайней мере вот эта найденная там не была и не появилась.
Также «Электроника МК-161» работает все эти годы без нареканий — баг обнаружен не в ней, а в сопутствующем ПО на компьютере. Машинка довольно надёжная. За это время уже пара айфонов поизносилась. Первые годы Новосибирск плотно работал с сообществом над выявлением и устранением недостатков. Это тоже способствовало надёжности ЭКВМ.
Во многом Каллисто — учёт этой критики. Кого-то МК-161 разочаровал отсутствием имён переменных и функций (необходимостью вручную распределять регистры и просчитывать адреса), и они вообще ушли с платформы. Я же, поняв, что производителю интересы сообщества во многом до лампочки (не окупаются), решил сделать самостоятельно то, что народ просил у Новосибирска. На уровне «программы пользователя».
Ошибку в новосибирском компиляторе я выявил при работе над менее амбициозным форт-проектом (не Каллисто), который надеюсь представить народу этой весной. Она была в компиляторе MK.EXE все эти годы — в том числе, пока я трудился над своим языком. Благодаря счастливым совпадениям, баг ни на что не повлиял.
У самого MK.EXE код закрыт, но желающие могут исправить компилятор mkl2mkp, его код открыт. В Каллисто-2 я уже ушёл от фирменных компиляторов на собственный форт-ассемблер, её этот баг не коснётся.
Оперативно
Оперативно
Радует.
Радует, что про ЭКВМ не забыли и компилятор обновляют.
Провёл ряд тестов, в 0.34 выявленная мной ошибка исправлена полностью. Откомпилировал новым MKL2MKP и опубликованную «водолазную программу», и свою более сложную, где ошибка проявилась — 28 страниц памяти, 1252 строк исходного текста. Всё заработало, как надо.
Увы, MK.EXE не менялся. Он всё ещё версии 1.28 и компилирует с ошибкой, те же самые примеры.
MK.EXE 1.29
С официального сайта: