Не встречалось.
Но знаю, что эпловский компилятор, вероятно, тоже использовался нечасто.
Недавно мне попалась какая-то прога, которая то ли была уже в коллекции, но чем-то отличалась, то ли пришедшая прога не запускалась и нужно было понять - в чём причина?
Причины всегда разные, может быть битый файла, но может быть прога требует чего-то особенного: конкретной версии бейсика или доса или модели компа...
Как начинается изучение любой проги ? Сперва ищем совпадения каких нибудь сигнатур по базе.
Берём кусок кода, байт 8-16 и роемся. Потому что если похожая прога есть, то их надо хранить и изучать вместе, заодно может оказаться, что какие-то заметки уже присутствуют в базе.
Так вот при поиске сигнатур выяснилось, что в базе уже есть прога с похожими сигнатурами, а если точнее - с почти 2кб куском полностью совпадающего кода. Но за этими 2кб проги полностью различаются.
Это, конечно, мог быть случай битого файла (кусок одного файла смешался с куском другого), но были и разные моменты, которые указывали на то, что это - всё таки - два разных файла.
Дальше я полез внутрь кода и обнаружил, что прога зависает при довольно занятном вызове какой-то процедуры: после команды JSR явно шли данные, а не код. Причем байт через 30 всё повторялось - несколько команд, затем JSR, затем явно не код. Как будто прога состоит из отдельных крупных шагов.
И выяснилось, что ещё до зависания, прога спокойно проходила несколько таких "шагов", а потом, на очередном, что-то зависало внутри JSR (или возвращалась на адрес с мусором ?). Конечно, мусор был данными, которые передавались в JSR. Т.е. JSR вела в процедуры примерно с таким началом:
PLA
STA $40
PLA
STA $41
LDY #1
LDA($40),Y
Я точно этот код не процитирую, возможно путаю младшие и старшие байты, но смысл такой: из стека выуживается адрес возврата из JSR, т.е. указатель, указывающий на следующий за JSR байт. Это аргументы функции. После обработки аргументов возврат из функции будет выполнен на команду, следующую за аргументом.
Причем все JSR вели внутрь этого "константного" куска (совпадавшего между файлами), а "шаги" были расположены за его пределеми.
Ничего не напоминает ?
Это называется "шитый код".
Каждый JSR - это обращение к коду, который соответствует некоему оператору Бейсика.
А аргумент, следующий за JSR - это слегка запакованные аргументы оператора.
Ну а 2кб кусок - что-то вроде интерпретатора этого шитого кода.
В той проге интерпретатор был неповреждён, но повредилась какая-то строка.
Дальше я не полез, но было интересно.
Так вот - как я уже сказал - в нашей коллекции нашлась всего одна программа с таким же вшитым интерпретатором. И я предполагаю, что это был именно Бейсик.
Впрочем, если кто-то может точно сказать, что эпловский бейсик-компилятор был полноценным компилятором - это будет интересно узнать. Но тогда интересно, кто, всё таки, генерировал шитый код на эпле ?
Мы не особо склонны собирать весь эпловский софт, т.е. мы его не ищем целенаправленно. И серьёзно не разбираем.
Но я его сохраняю именно для того, чтобы не разрибать каждый раз - что за программа к нам попала или откуда она, а чтобы сходу можно было найти что-то похожее и сразу узнать: этот код - под эпл и он у нас уже есть и мы знаем его название.