Компиляторы ассемблера
Moderator: Shaos
-
- Doomed
- Posts: 585
- Joined: 19 Feb 2017 03:46
- Location: Санкт-Петербург, Россия, третья планета от Солнца, галактика Млечный Путь
Компиляторы ассемблера
.
Предлагаю переименовать тему в "Компиляторы ассемблера на бейсике". Тогда можно будет обсуждать ассемблеры для 6800 и 8080 без риска, что твой пост грохнут под надуманным предлогом. Это правильно, т.к ассемблер для 8080 уже обсуждался в теме.
Замечу, что упомянутые ассемблеры на бейсике даже слабее, чем 2-х килобайтный ассемблер для РК86 из ж.Радио (нет вычисления выражений в операторах). Чем процессор более прост и система команд лучше структурирована, тем меньшее число операторов бейсика в компиляторе. Потому в компиляторе 8080 в 1.5 раза больше операторов бейсика, чем в компиляторе 6502.
Миниассемблер 6502 (из ПЗУ Apple-II) занимает менее 1 кб. Из этого ясно, что если компилятор 6502 переписать на ассемблер, то получится чуть более 1 кб. Так что компилятор написанный на ассемблере даже в 1976 был более оправдан, т.к тогда мало у кого из любителей микро-ЭВМ ОЗУ было более 4 кб. Каждый лишний килобайт ОЗУ обходился в сотню баксов. Потому-то TINY BASIC для 8080 (объёмом в 1800 байт) и значительно более компактный бейсик для 6800 (768 байт) и были актуальны.
Это кстати, чётко иллюстрирует, что JR-переходы сокращают объём кода, потому в те годы 6800 и 6502 с точки зрения экономии были выгоднее, чем 8080.
Кстати, ассемблер 6502 на TINY-бейсике написал сам автор этого бейсика (Том Питман кажется, если склероз не подводит). А он, вроде бы, за прототип этого своего бейсика взял самый крошечный бейсик для 6800, конвертировав его для 6502. Могу ошибаться, давно читал. Интересно сравнить объём кода бейсика для 6800 с полным аналогом на 6502. Тогда будет ясно у какого CPU плотность кода выше.
Предлагаю переименовать тему в "Компиляторы ассемблера на бейсике". Тогда можно будет обсуждать ассемблеры для 6800 и 8080 без риска, что твой пост грохнут под надуманным предлогом. Это правильно, т.к ассемблер для 8080 уже обсуждался в теме.
Замечу, что упомянутые ассемблеры на бейсике даже слабее, чем 2-х килобайтный ассемблер для РК86 из ж.Радио (нет вычисления выражений в операторах). Чем процессор более прост и система команд лучше структурирована, тем меньшее число операторов бейсика в компиляторе. Потому в компиляторе 8080 в 1.5 раза больше операторов бейсика, чем в компиляторе 6502.
Миниассемблер 6502 (из ПЗУ Apple-II) занимает менее 1 кб. Из этого ясно, что если компилятор 6502 переписать на ассемблер, то получится чуть более 1 кб. Так что компилятор написанный на ассемблере даже в 1976 был более оправдан, т.к тогда мало у кого из любителей микро-ЭВМ ОЗУ было более 4 кб. Каждый лишний килобайт ОЗУ обходился в сотню баксов. Потому-то TINY BASIC для 8080 (объёмом в 1800 байт) и значительно более компактный бейсик для 6800 (768 байт) и были актуальны.
Это кстати, чётко иллюстрирует, что JR-переходы сокращают объём кода, потому в те годы 6800 и 6502 с точки зрения экономии были выгоднее, чем 8080.
Кстати, ассемблер 6502 на TINY-бейсике написал сам автор этого бейсика (Том Питман кажется, если склероз не подводит). А он, вроде бы, за прототип этого своего бейсика взял самый крошечный бейсик для 6800, конвертировав его для 6502. Могу ошибаться, давно читал. Интересно сравнить объём кода бейсика для 6800 с полным аналогом на 6502. Тогда будет ясно у какого CPU плотность кода выше.
-
- Supreme God
- Posts: 16701
- Joined: 21 Oct 2009 08:08
- Location: Россия
Re:Компиляторы ассемблера
Под надуманным предлогом никто ничего не грохает. У форума достаточно разделов, чтобы обстоятельноbarsik wrote:Предлагаю переименовать тему в "Компиляторы ассемблера на бейсике". Тогда будет можно обсуждать ассемблеры для 6800 и 8080 без риска, что твой пост грохнут под надуманным предлогом.
вести беседу на любую тематику.
Переименовывать эту тему также нет необходимости.
"Компиляторы ассемблера на бейсике" для процессоров и 6800, и 8080, и др. - это что такое?
Это софт. На форуме есть для этого специальный раздел: Software - здесь и создадим целевой топик.
Прошу всех заинтересованных лиц присоединится к беседе. Сюда же выкладываю копию материала
топикстартера, за которую он столько переживал.
К сожалению, не имею полномочий восстановить её сюда.barsik wrote:Тема интересная, но всё-же бейсик для 8-ми разрядки это явно не тот язык, чтобы писать компиляторы. Если даже могучие Паскаль и Си для написания ассемблеров 8-ми разрядок не нашли применения, то бейсик для этого - это вообще нонсенс.
Это делали лишь на заре цивилизации в 1975-76 годах, когда другого инструментария не было. Кстати, это не первый и не единственный ассемблер 6502 на бейсике. Есть ассемблер даже на TINY-бейсике (менее 300 операторов), написанный когда DOS ещё не было.Написать ассемблер на бейсике - это хорошее упражнение для совершенствования в бейсике, даже сейчас.Lavr wrote:Quick and Dirty 8080 Assembler... написан на BASIC... под М$ QBasic адаптируется довольно легко
Но для 1985 года ассемблер на бейсике - это нонсенс. Объяснение в том, что было написано человеком, который хорошо знал именно бейсик (т.к преподавал его) и для конкретной одноразовой цели в конкретной ситуации. В 1985, уже было явно неразумно использовать бейсик для этой задачи, хотя для конкретного автора это имело смысл.
Использование бейсика вместо ассемблера для задач такой сложности даёт некоторый выигрыш по трудозатратам. Но и результаты несравнимы по качеству продукта. Помимо учебных целей бейсик для 8-ми разрядки почти не имеет смысла (а для PC, где скорости на многие порядки выше, а ограничений по объёму кода и текста нет, это иначе).
Судите сами. Этот ассемблер по уровню равен 2-х килобайтовому МИКРОНУ для РК86 написанному Барчуковым и Фадеевым. В ассемблере МИКРОН ~1200 строк ассемблера. В этом ассемблере КР580 на бейсике 340 строк, но в большинстве строк по 2-3 оператора бейсика. Т.е примерно 750 операторов бейсика (аналогичный ассемблер 6502 - 570 операторов). В памяти интерпретатора программа занимает ~8 кб и ещё 10 кб или более отнимает интерпретатор. Т.о без-DOS-овый вариант на бейсике - невыгоден (т.к остаётся мало места под буфер текста и буфер трансляции).
Если (адаптированный под Microsoft-бейсик вариант) откомпилировать с помощью BASCOM, то такой продукт для без-DOS-ового варианта тоже будет бессмысленным, т.к в силу ущербности бейсика получится слишком большой файл (более 32 кб). Но в дисковом варианте, где не требуется буфер для всего текста, а идет построчное чтение из файла, компиляция ускоряет трансляцию.
Автор написал этот ассемблер на бейсике за 2 дня. Но за те же два, максимум три, дня аналогичный примитивный ассемблер можно написать и на ассемблере. Я это знаю, т.к делал это. Будучи совсем неопытным я написал ассемблер КР580 аналог МИКРОНА (2400 строк) за 2 недели, а значит опытному программисту для этого нужно всего 2 дня.
Но главный довод в том, что не получится доработать примитивный ассемблер на бейсике в нормальный ассемблер. Сравните размер ассемблера МИКРОН в 2 кб и Microsoft M80 с размером в 18 кб. Но сложность разработки нарастает не пропорционально размеру кода, а на порядок больше. Если написание примитивного ассемблера занимает всего несколько дней, то доработка его до макроассемблера занимает несколько месяцев.
Более разумно использовать Паскаль, в нём работа со строками не хуже (и точно лучше, чем в TINY-бейсике). Примитивный ассемблер точно получится неплохим, даже макро-ассемблер возможно удастся сделать одноблочным (или придётся использовать оверлеи для каждого из трёх проходов).
А вообще, компиляторы ассемблера для 8-ми разрядки всегда писали на ассемблере. Даже компиляторы ЯВУ, которые ещё на порядок сложнее, до середины 80-тых тоже писали на ассемблере (хотя Си и Паскаль для 8-ми разрядок появились в 1979). Лишь с середины 80-тых компиляторы ЯВУ для 8-ми разрядок стали писать в основном на Си.
Но давайте обсудим "Компиляторы ассемблера на бейсике", которые сам топикстартер рекомендовал
писать на других языках.
P.S. И чтобы не омрачать начало темы ненужным препирательством, расширил её название, а всё лишнее и личное - убрал.
iLavr
-
- Admin
- Posts: 24097
- Joined: 08 Jan 2003 23:22
- Location: Silicon Valley
Re: Компиляторы ассемблера
А ассемблер это вроде транслятор - не?...
Я тут за главного - если что шлите мыло на me собака shaos точка net
-
- Supreme God
- Posts: 16701
- Joined: 21 Oct 2009 08:08
- Location: Россия
Re: Компиляторы ассемблера
Да, транслятор. Но трансляторы бывают компилирующего и интерпретирующего типов.Shaos wrote:А ассемблер это вроде транслятор - не?...
Интерпретатор ассемблера я лично не встречал.
А вот Васик-транслятор бывает обоих типов.
P.S. Хотя, возможно, эмулятор какого-либо процессора на другой платформе и можно назвать
интерпретатором его ассемблера.
iLavr
-
- Supreme God
- Posts: 16701
- Joined: 21 Oct 2009 08:08
- Location: Россия
Re: Компиляторы ассемблера
Ну и чтобы помочь Барсику в новой его теме, подкину сюда два компилятора ассемблера для х86 на Бейсике.
на GW-BASIC.
На немецком языке.
Замечательная вещь, по крайней мере для меня она поставила точку во всех спорах о том, что
и на каких языках можно написать, а на каких типа - нет.
Написать можно всё что угодно, на том языке, котoрым владеешь...
Это, правда, будет боян от 2010 года, но ведь Барсика тогда с нами не было...
И, может быть, как-нибуть найду у себя архив, как 2 немца написали операционную системуна GW-BASIC.
На немецком языке.

Замечательная вещь, по крайней мере для меня она поставила точку во всех спорах о том, что
и на каких языках можно написать, а на каких типа - нет.
Написать можно всё что угодно, на том языке, котoрым владеешь...
Это, правда, будет боян от 2010 года, но ведь Барсика тогда с нами не было...

You do not have the required permissions to view the files attached to this post.
iLavr
-
- Supreme God
- Posts: 16701
- Joined: 21 Oct 2009 08:08
- Location: Россия
Re: Компиляторы ассемблера
Топикстартер заявил следующее:
viewtopic.php?f=72&t=19127
А мы тут всё же, я думаю, продолжим топик о компиляторах ассемблера, ибо обсудить есть что.
Я ассемблеры и сам писал, и не только на Бейсике. Самый ближайший пример есть здесь:
viewtopic.php?f=67&t=9310, хотя это ассемблер
для самодельной системы команд, похожей на i8080, но все черты нормального ассемблера есть.
Поскольку такой системы команд ни у чего больше нет (кстати, PIC здесь получается интерпретатором
команд выдуманного ассемблера), то мне пришлось написать ассемблер самому и он нужен был мне быстро.
Я никуда подсмотреть не успевал и действовал по следующему лобовому алгоритму:
ассемблер работает в два прохода.
На 1-м группируются все строковые метки и вычисляются их адреса.
Проверяется синтаксис строк и строки выводятся в окно. Окно не текстовое, окно - строчный список.
Если первый этап прошел удачно, можно скомандовать 2-проход: собрать bin-файл, а после него и hex.
На 2-м этапе генерируется код по таблицам мнемоник, которым поставлены в соответствие их коды.
Разбор строк у меня был самый лобовой:
1. Ищется комментарий ";". Если он наден, отрезается вся строка до ";" - это предположительно команда и метка.
Если ";" НЕ наден, то вся строка - предположительно команда и метка.
2. Ищется признак метки в строке ":". Если он наден, отрезается вся строка до ":" .
Удаляются концевые пробелы, метка посимвольно проверяется на соответствие разрешенным символам.
Если всё хорошо - метка заносится в строковый массив, её численный адрес - в массив адресов.
Если ":" НЕ наден, то вся строка - предположительно команда и её аргумент, если он есть.
3. Ищется разделитель в строке пробел, если от найден, то, видимо, это оператор.
Проверяется список операторов. Если оператор такой есть, и он без операнда, то строка более не анализируется.
Всё записывается в строку окна-списка. Номер строки и операнд.
4. Анализируется операнд. Тут всё чуть муторнее:проверка на текст в операнде - одинарные кавычки.
Всё, кроме текста переодится в верхний регистр, пробелы удаляются.
По массиву ищутся всякие H, A,B, B,C... и т.п., т.е. НЕ численные аргументы.
Так же делается проверка на числа, размер чисел, наличие меток.
Если найдена метка, проверяется по списку меток, запоминается строка с меткой в массив.
Всё также записывается в строку окна-списка. Номер строки и операнд.
На втором проходе метки расставляются, формируются коды команд с аргументами и без.
В общем примерно так оно приемлемо работало.
Мне не давался удачный алгоритм разбора длинной строки аргумента, включающей скобки, метки
и математические операции.
Понятно было, либо должен быть какой-то хитрый алгоритм, либо число операций в строке надо ограничить,
вместе с числом операндов.
Я выбрал второй вариант, хотя и там разбор математики "+", "-", метки, числа (скобок нет), получился весьма
тяжелым и некрасивым, но всё-таки всё работало.
Я поинтересовался настойчиво в Гугл, какие есть устоявшиеся и распространеные методы парсинга
строки с аргументами, и нашел их два в весьма доходчивом изложении:
Алгоритм обpатной польской нотации: Парсер методом рекурсивного спуска: Выложил здесь оба архива для тех, кому, возможно, это тоже интересно.
В обоих архивах есть и описание и пример на С++.
Я пока ни один вариант не попробовал, но вскоре я один ассемблерчик писать буду.
Ассемблеры, который я выложил в ветке 6502 и ранее в этом топике - я смотрел, как
люди пишут свои самодельные ассемблеры, в качестве примеров.
Да в общем-то примерно так, как и я: где-то лучше, где-то хуже. Ничего сверх-крутого
не увидел, но посмотреть есть на что.
Возможность поболтать у нас всем предоставляется в курилке, поэтому флейм туда и перенесен.тема бесполезная, чисто историко-просветительская, мало кому интересная и то, что писать ассемблеры на бейсике невыгодно, и-так ясно. Тема изначально была флеймовая, - расширить кругозор ссылками и немного поболтать.
viewtopic.php?f=72&t=19127
А мы тут всё же, я думаю, продолжим топик о компиляторах ассемблера, ибо обсудить есть что.
Я ассемблеры и сам писал, и не только на Бейсике. Самый ближайший пример есть здесь:
viewtopic.php?f=67&t=9310, хотя это ассемблер
для самодельной системы команд, похожей на i8080, но все черты нормального ассемблера есть.
Поскольку такой системы команд ни у чего больше нет (кстати, PIC здесь получается интерпретатором
команд выдуманного ассемблера), то мне пришлось написать ассемблер самому и он нужен был мне быстро.
Я никуда подсмотреть не успевал и действовал по следующему лобовому алгоритму:
ассемблер работает в два прохода.
На 1-м группируются все строковые метки и вычисляются их адреса.
Проверяется синтаксис строк и строки выводятся в окно. Окно не текстовое, окно - строчный список.
Если первый этап прошел удачно, можно скомандовать 2-проход: собрать bin-файл, а после него и hex.
На 2-м этапе генерируется код по таблицам мнемоник, которым поставлены в соответствие их коды.
Разбор строк у меня был самый лобовой:
1. Ищется комментарий ";". Если он наден, отрезается вся строка до ";" - это предположительно команда и метка.
Если ";" НЕ наден, то вся строка - предположительно команда и метка.
2. Ищется признак метки в строке ":". Если он наден, отрезается вся строка до ":" .
Удаляются концевые пробелы, метка посимвольно проверяется на соответствие разрешенным символам.
Если всё хорошо - метка заносится в строковый массив, её численный адрес - в массив адресов.
Если ":" НЕ наден, то вся строка - предположительно команда и её аргумент, если он есть.
3. Ищется разделитель в строке пробел, если от найден, то, видимо, это оператор.
Проверяется список операторов. Если оператор такой есть, и он без операнда, то строка более не анализируется.
Всё записывается в строку окна-списка. Номер строки и операнд.
4. Анализируется операнд. Тут всё чуть муторнее:проверка на текст в операнде - одинарные кавычки.
Всё, кроме текста переодится в верхний регистр, пробелы удаляются.
По массиву ищутся всякие H, A,B, B,C... и т.п., т.е. НЕ численные аргументы.
Так же делается проверка на числа, размер чисел, наличие меток.
Если найдена метка, проверяется по списку меток, запоминается строка с меткой в массив.
Всё также записывается в строку окна-списка. Номер строки и операнд.
На втором проходе метки расставляются, формируются коды команд с аргументами и без.
В общем примерно так оно приемлемо работало.
Мне не давался удачный алгоритм разбора длинной строки аргумента, включающей скобки, метки
и математические операции.
Понятно было, либо должен быть какой-то хитрый алгоритм, либо число операций в строке надо ограничить,
вместе с числом операндов.
Я выбрал второй вариант, хотя и там разбор математики "+", "-", метки, числа (скобок нет), получился весьма
тяжелым и некрасивым, но всё-таки всё работало.
Я поинтересовался настойчиво в Гугл, какие есть устоявшиеся и распространеные методы парсинга
строки с аргументами, и нашел их два в весьма доходчивом изложении:
Алгоритм обpатной польской нотации: Парсер методом рекурсивного спуска: Выложил здесь оба архива для тех, кому, возможно, это тоже интересно.
В обоих архивах есть и описание и пример на С++.
Я пока ни один вариант не попробовал, но вскоре я один ассемблерчик писать буду.
Ассемблеры, который я выложил в ветке 6502 и ранее в этом топике - я смотрел, как
люди пишут свои самодельные ассемблеры, в качестве примеров.
Да в общем-то примерно так, как и я: где-то лучше, где-то хуже. Ничего сверх-крутого
не увидел, но посмотреть есть на что.
You do not have the required permissions to view the files attached to this post.
iLavr
-
- Doomed
- Posts: 585
- Joined: 19 Feb 2017 03:46
- Location: Санкт-Петербург, Россия, третья планета от Солнца, галактика Млечный Путь
Когда у Вас есть доступ к Microsoft-ассемблеру М80 глупо серъёзно думать, что сможешь написать что-то лучшее. Последние версии М80 ассемблируют для 8080, Z80 и 6502, так что другой ассемблер для 6502 теряет всякий смысл.
Вставлю несколько заметок о своём о опыте написания ассемблеров. Это может помочь кому-то заинтересоваться темой и написать свой ассемблер.
Ассемблер МИКРОН написан грамотно, буду очень уважать того, кто сейчас сможет написать аналогичный ассемблер и уложится в размер менее 2 кб. Ассемблеру МИКРОН не хватало макросредств (и раздражало, что он не допускает пустые строки). Хотелось поиметь ассемблер допускающий многофайловость (использующий DOS для RAM-диска на РУ7) и макро.
Макро ассемблер ASSMAK для Специалиста, что попал в руки в конце 80-тых оказался дохлым. А макро ассемблер МИКРОШИ попал ко мне только в 1994 на дискетах Лианозово. Потому в самом конце 80-тых начал писать свой ассемблер для Специалиста.
Оказалось, что написать примитивный ассемблер совсем просто, уже на 3-тий день что-то компилировало (без вычисления выражений и меток вперёд). Задача ставилась разработать полный аналог МИКРОНА и это получилось. Но получившийся ассемблер имел размер в 1.5 раза больший, чем МИКРОН. Это потому, что использовал лобовой алгоритм (только 64 кода MOV-ов синтезировались побитово, а всё остальное было табличным).
За последующие годы доработал этот ассемблер до макро. Получилось 5000 строк. Код получился неоптимальным и сложным в отладке. Я писал программы и намного большего объёма, но макроассемблер стал самой сложной программой. Писалось много лет, но собственно трудоёмкость ~3 месяца. На ЯВУ это можно написать намного быстрее.
Нашёл описание алгоритма и документацию версии для РК86. Это лишь моё личное мнение, но считаю, что любой ассемблер, который слабее описанного, для серьёзного программиста - просто бесполезный хлам.
А вот описание макро-ассемблера от РК86 (адаптированнного от МИКРОШИ), разработанного профессиональными программистами ЛЭМЗ (Лианозово). Точнее это не описание, а составленный мной для себя краткий дайджест из документации по этому макро-ассемблеру (полное описание слишком большое, т.к написано для чайников). Я пользовался этим макро-ассемблером. Он тоже удовлетворяет почти всем требованиям, хотя и не имеет специальных макросредств (что позволяет делать на макро-ассемблере хитрые трюки).
- - - Дробавлено - - -
Вот ещё одна тема для творчества на ниве ассемблеров. Для отечественных бытовых ЭВМ такого не было, но для некоторых западных ЭВМ были системы программирования на ассемблере. Они также как пакет МИКРОН представляли полную среду для разработки и содержали текстов редактор. Но принципы редактора и метод хранения исходников были другие.
Использовалась идея бейсика, - вводимая строка ассемблера сразу проверялась на соответствие синтаксису и сразу транслировалась в некий байт-код, что резко сокращает объём хранения. Видимо большинство команд сразу ассемблируется, отчего исходник занимает в разы меньше места, чем символьный текст. Для 6502 и 6800 такое сжатие исходника особенно удобно, т.к имеется много неиспользованных под команды кодов (из 256 возможных, это только в 8080 почти все байты заняты под команды).
Для лишённых дисковода ЭВМ такой трюк при том же объёме ОЗУ позволяет создавать и транслировать программы размером в несколько раз больше, чем 2 кб, что можно странслировать МИКРОН-ом.
Вставлю несколько заметок о своём о опыте написания ассемблеров. Это может помочь кому-то заинтересоваться темой и написать свой ассемблер.
Ассемблер МИКРОН написан грамотно, буду очень уважать того, кто сейчас сможет написать аналогичный ассемблер и уложится в размер менее 2 кб. Ассемблеру МИКРОН не хватало макросредств (и раздражало, что он не допускает пустые строки). Хотелось поиметь ассемблер допускающий многофайловость (использующий DOS для RAM-диска на РУ7) и макро.
Макро ассемблер ASSMAK для Специалиста, что попал в руки в конце 80-тых оказался дохлым. А макро ассемблер МИКРОШИ попал ко мне только в 1994 на дискетах Лианозово. Потому в самом конце 80-тых начал писать свой ассемблер для Специалиста.
Оказалось, что написать примитивный ассемблер совсем просто, уже на 3-тий день что-то компилировало (без вычисления выражений и меток вперёд). Задача ставилась разработать полный аналог МИКРОНА и это получилось. Но получившийся ассемблер имел размер в 1.5 раза больший, чем МИКРОН. Это потому, что использовал лобовой алгоритм (только 64 кода MOV-ов синтезировались побитово, а всё остальное было табличным).
За последующие годы доработал этот ассемблер до макро. Получилось 5000 строк. Код получился неоптимальным и сложным в отладке. Я писал программы и намного большего объёма, но макроассемблер стал самой сложной программой. Писалось много лет, но собственно трудоёмкость ~3 месяца. На ЯВУ это можно написать намного быстрее.
Нашёл описание алгоритма и документацию версии для РК86. Это лишь моё личное мнение, но считаю, что любой ассемблер, который слабее описанного, для серьёзного программиста - просто бесполезный хлам.
АЛГОРИТМ АССЕМБЛЕРА
- В проходе 1:
просматриваем программу и обрабатываем ORG, EQU, END и
заносим в таблицу все встреченные метки (если их имена
не операторы), причем во всех адресных метках таблицы меток
устанавливается старший бит в первом символе. Это признак,
что метка ещё не приняла значение. Если после 1-го прохода
нет END_FLG - выход.
Если встретился второй ORG - также выход.
Если встретится вторая метка с тем же именем (что может
быть в операторе SET), то корректируется сам исходный
текст - устанавливается старший бит в первом байте метки.
Метки полученные от EQU не имеют установленного старшего
бита в первом символе. Это флаг, в метках полученных от
EQU, от SET устанавливается старший бит во втором
символе. Это признак того, что это метка от EQU. В первом
проходе в таблицу меток заносятся все метки, в том числе и
метки от строк с оператором MACRO. Метки от оператора SET
на 1 проходе обрабатываются как адресные.
- В проходе 2:
просматриваем программу с ведением счётчика ассемблирования.
И каждую встреченную незаполненную метку (в том числе и метки
от SET и EQU) заполняем числом из счётчика ассемблирования,
причём старший бит в первом символе имени метки не сбрасываем.
В этом проходе ведётся счётчик ассемблирования (длины команд
выдает п/п-мма GETSIZ). В этом проходе заполняются значениями
метки образованные оператором SET, причем в метках SET
старший бит первого байта всегда установлен (отчего он может
получать новое значение). Если встречается слово MACRO
(т.е начало макроопределения), то делается следующее:
- проверяется, что строка имеет метку
- эта метка ищется в таблице меток
- эта метка удаляется из таблицы меток
- эта метка заносится в таблицу МАКРО
- 6,7 байтом туда заносится адрес следующей строки текста
- выставляется флаг MAC_FL, что мы в МАКРО-определении
(тогда все следующие строки до ENDM не генерят кода)
- В проходе 3:
Просматриваем программу и генерируем код в CODE BUFFER.
Каждую встреченную метку, если она не имеет установленного
старшего бита во втором символе (т.е метка EQU), проверяем
на соответствие счётчику ассемблера и если не совпадают, то
генерится ошибка. Во всех правильных метках сбрасывается
старший бит в первом символе. Также сбрасывается старший бит
во втором символе. Метки, где остался установленным старший
бит в первом символе - имеют несоответствие адреса во 2 и 3
проходах. Если встречается имя из таблицы МАКРО, то
- в (MACRET) заносится (NXTLIN)
- в (NXTLIN) заносится 6,7 байты из таблицы МАКРО
- выставляется флаг что в генерации МАКРО: XMA_FL=255
А вот описание макро-ассемблера от РК86 (адаптированнного от МИКРОШИ), разработанного профессиональными программистами ЛЭМЗ (Лианозово). Точнее это не описание, а составленный мной для себя краткий дайджест из документации по этому макро-ассемблеру (полное описание слишком большое, т.к написано для чайников). Я пользовался этим макро-ассемблером. Он тоже удовлетворяет почти всем требованиям, хотя и не имеет специальных макросредств (что позволяет делать на макро-ассемблере хитрые трюки).
Code: Select all
МАКРО-АССЕМБЛЕР ОТ РК-86
========================
Команды ассемблера: 1, 2, 3 или G. По нажатию 'G' делается JMP на
начало буфера кодов (адрес ORG должен быть равен буферу кодов)
Этот МАКРО-ассемблер требует:
- Главное - в исходном тексте не должно быть табуляций !!!
- Метки в макро должны быть не длиннее 4 символов
и должны кончаться обратным слэшем '\'. При трансляции
слэш заменяется на номер макрогенерации.
- Есть локальные метки. Они действуют только до следующей
локальной метки. Локальные метки начинаются с '?' и состоят
из одной буквы.
Пример:
?C: DCR B
JNZ ?C
- Длина глобальных меток не ограничена в 6 символов, а может
быть до 16 символов.
- Адреса параметров в макрокомандах должны начиналься с '@'.
- Все метки (в т.числе и в строке с SET) и имена макрокоманд в
их определении должны заканчиваться двоеточием
- Метки всегда должны начинаться в самом начале строки
- Есть блоки повторов REPT...ENDM, WHILE...ENDW (не WEND !),
макрокоманды MACRO...ENDM и условная компилляция (IF...ENDIF).
Но оператора ELSE - нет. Допускается вложенность условий и
циклов до 8.
- допустимо указывать имена двойных регистров полностью
(т.е правильно и LXI H,0 и также LXI HL,0)
- Плохо обрабатываются ошибки, если встречается ошибка в МАКРО,
то далее много правильных строк также отмечаются ошибкой
- Допускает числа HEX (суффикс H), BIN (суффикс B) и OCT
(суффикс Q !) и символьные строки (1 или 2 символа) как числа.
- Для вычисления выражений используются операторы:
* / + - (арифметика), > (больше), < (меньше), = (равно)
# (не равно), & (поразрядное И), ! (поразрядное ИЛИ),
% (поразрядное ИСКЛЮЧАЮЩЕЕ ИЛИ).
Также допустимо использовать скобки до любой вложенности.
Арифметические операции имеют наивысший приоритет,
а битовые операции - наименьший приоритет.
Коды ошибок:
U - undefined label
O - недопустимы операнд
C - несуществующая команда
L - недопустимая метка
D - двойное задание метки
S - лишний символ в поле операндов
T - неверный синтаксис в выражении
M - ошибка в макроопределении или макровызове
I - ошибка в условном операторе
W - ошибка в операторе цикла
E - превышение длины команды или метки
P - ошибка в макропараметре
ДАЛЕЕ ПРИМЕРЫ.
; ----------------------------------------------
CALLIF MACRO @FLAG,@ADR
LDA FLAG
ORA A
JZ LL\
CALL ADR
LL\:
ENDM
...
CALLIF FLG1,WORK
; ----------------------------------------------
LOOP: MACRO @ADR
DCX B
MOV A,B
ORA C
JNZ @ADR
ENDM
...
PAUSE: LXI HL,2000H
LOO: LOOP LOO
; ----------------------------------------------
WWW: SET 0
WHILE WWW # 20
WWW: SET WWW+1
DB WWW
ENDW
; ----------------------------------------------
IF ORION
COUT: EQU 0F809H
ENDIF
IF ORION = 0
COUT: EQU 0C337H
ENDIF
; ----------------------------------------------
Вот ещё одна тема для творчества на ниве ассемблеров. Для отечественных бытовых ЭВМ такого не было, но для некоторых западных ЭВМ были системы программирования на ассемблере. Они также как пакет МИКРОН представляли полную среду для разработки и содержали текстов редактор. Но принципы редактора и метод хранения исходников были другие.
Использовалась идея бейсика, - вводимая строка ассемблера сразу проверялась на соответствие синтаксису и сразу транслировалась в некий байт-код, что резко сокращает объём хранения. Видимо большинство команд сразу ассемблируется, отчего исходник занимает в разы меньше места, чем символьный текст. Для 6502 и 6800 такое сжатие исходника особенно удобно, т.к имеется много неиспользованных под команды кодов (из 256 возможных, это только в 8080 почти все байты заняты под команды).
Для лишённых дисковода ЭВМ такой трюк при том же объёме ОЗУ позволяет создавать и транслировать программы размером в несколько раз больше, чем 2 кб, что можно странслировать МИКРОН-ом.
-
- Fanat
- Posts: 53
- Joined: 31 May 2007 08:23
- Location: Украина
Re: Компиляторы ассемблера
В моих соображениях вырисовывается некая программа для PC,
Которая принимает на вход формулу типа (4+a)*b-(c|d-a+b)&c-1,
и выводит листинг ассемблера для 8-битного микропроцессора.такая программа(что в листинге) читает с ОЗУ abcd и рассчитывает по формуле (той самой)
Которая принимает на вход формулу типа (4+a)*b-(c|d-a+b)&c-1,
и выводит листинг ассемблера для 8-битного микропроцессора.такая программа(что в листинге) читает с ОЗУ abcd и рассчитывает по формуле (той самой)
-
- Doomed
- Posts: 585
- Joined: 19 Feb 2017 03:46
- Location: Санкт-Петербург, Россия, третья планета от Солнца, галактика Млечный Путь
Замечу, что на PC используя его неограниченное ОЗУ, скорость и нструментарий написать ассемблер намного проще, чем чисто из спортивного интереса написать что-то реально работающее на рэтро ЭВМ с маленьким ОЗУ.
Не понял о какой "некой программе на PC", которая на входе принимает текстовую строку и что-то выдаёт на выход, идёт речь. Тема ведь целый ассемблер. Программа вычисления выражений конечно должна входить в ассемблер. Я много раз писал упрощённый вариант такой процедуры (она же требуется и в бейсике).
Написать на ассемблере программу анализа простых выражений (т.е выражений без скобок и тем более без вложения скобок) легко. Вычислитель со скобками, но без их вложений, я тоже когда-то на ассемблере написал (очень неоптимально, потому и без вложений).
Но не вычислитель выражений самое сложное в ассемблерах. А макро генерация со всеми теми возможностями, что даёт М80 (кстати некоторых макро-возможностей М80 нет даже в ассемблерах 80x86, что затрудняет конверсию исходников).
Похоже, что грамотный анализатор выражений делается через стек (и может быть даже удобнее его делать на форте). А вообще алгоритм, даже при написании программы для 8-ми разрядки, выгодно отрабатывать на ЯВУ.
При программировании на ассемблере алгоритм виден с трудом, особенно, если разрабатывать программу без чёткого заранее составленного плана, а постепенно улучшать имеющийся код, что приводит к запутанности.
А на ЯВУ алгоритм более нагляден и его отладка намного проще. Отработав алгоритм можно переписать процедуру на ассемблер и это уменьшит вероятность того, что придётся терять уйму времени на отладку (что часто происходит при реализации сложных процедур на ассемблере).
ЯВУ, для разработки достаточно сложных по алгоритму программ намного выгоднее. Увы, у ЯВУ на 8-ми разрядке есть недостатки, что этому препятствуют, но это не мешает использовать ЯВУ как вспомогательное средство.
Не понял о какой "некой программе на PC", которая на входе принимает текстовую строку и что-то выдаёт на выход, идёт речь. Тема ведь целый ассемблер. Программа вычисления выражений конечно должна входить в ассемблер. Я много раз писал упрощённый вариант такой процедуры (она же требуется и в бейсике).
Написать на ассемблере программу анализа простых выражений (т.е выражений без скобок и тем более без вложения скобок) легко. Вычислитель со скобками, но без их вложений, я тоже когда-то на ассемблере написал (очень неоптимально, потому и без вложений).
Но не вычислитель выражений самое сложное в ассемблерах. А макро генерация со всеми теми возможностями, что даёт М80 (кстати некоторых макро-возможностей М80 нет даже в ассемблерах 80x86, что затрудняет конверсию исходников).
Похоже, что грамотный анализатор выражений делается через стек (и может быть даже удобнее его делать на форте). А вообще алгоритм, даже при написании программы для 8-ми разрядки, выгодно отрабатывать на ЯВУ.
При программировании на ассемблере алгоритм виден с трудом, особенно, если разрабатывать программу без чёткого заранее составленного плана, а постепенно улучшать имеющийся код, что приводит к запутанности.
А на ЯВУ алгоритм более нагляден и его отладка намного проще. Отработав алгоритм можно переписать процедуру на ассемблер и это уменьшит вероятность того, что придётся терять уйму времени на отладку (что часто происходит при реализации сложных процедур на ассемблере).
ЯВУ, для разработки достаточно сложных по алгоритму программ намного выгоднее. Увы, у ЯВУ на 8-ми разрядке есть недостатки, что этому препятствуют, но это не мешает использовать ЯВУ как вспомогательное средство.
-
- Admin
- Posts: 24097
- Joined: 08 Jan 2003 23:22
- Location: Silicon Valley
Re: Компиляторы ассемблера
Эта "некая программа для PC" называется кросс-компилятор Сиzooleek wrote:В моих соображениях вырисовывается некая программа для PC,
Которая принимает на вход формулу типа (4+a)*b-(c|d-a+b)&c-1,
и выводит листинг ассемблера для 8-битного микропроцессора.такая программа(что в листинге) читает с ОЗУ abcd и рассчитывает по формуле (той самой)

Я тут за главного - если что шлите мыло на me собака shaos точка net
-
- Supreme God
- Posts: 16701
- Joined: 21 Oct 2009 08:08
- Location: Россия
Re: Компиляторы ассемблера
Раз уж картинку я сюда запостил, пусть будет здесь, чтобы была ясность, кто из них - кто. Не все, оказывается, у нас эту градацию четко понимают...Lavr wrote:Да, транслятор. Но трансляторы бывают компилирующего и интерпретирующего типов.Shaos wrote:А ассемблер это вроде транслятор - не?...
You do not have the required permissions to view the files attached to this post.
iLavr
-
- Supreme God
- Posts: 16701
- Joined: 21 Oct 2009 08:08
- Location: Россия
Re: Компиляторы ассемблера
Ассемблерчик мне понадобился для моего 4-битного DIY-процессора: 4-bit Processor.Lavr wrote:Я ассемблеры и сам писал, и не только на Бейсике. Самый ближайший пример есть здесь:
viewtopic.php?f=67&t=9310, хотя это ассемблер
для самодельной системы команд, похожей на i8080, но все черты нормального ассемблера есть.
... вскоре я один ассемблерчик писать буду.
Я не занимался им с момента последней публикации, но сейчас созрел доработать проект и рискнуть
запихнуть его в CPLD, как я и планировал.
Но под CPLD проект надо доработать, что я сейчас и делаю, и протестировать хорошо систему команд,
одну ошибку уже нашел в операторе SFA.
В связи с этим приходится писать много тестовых программок, и сейчас я это делал в редакторе: Потом вручную ставил соответствие КОП по таблице кодов
........

И через WinHex это всё "компилировал" вручную в .bin-файл.

Процесс весьма муторный, поэтому ассемблер должен мне всё ускорить.
Я использовал собственные исходники, написаные еще в 2010 году, причем весьма неплохо!
Я еще тогда заложил в них некоторую универсальность, чтобы можно было сменить оперативно
систему команд - выяснил сейчас, что это получилось вполне приемлемо.
Основной функционал у меня уже сейчас практически заработал: Некоторые трудности были с тем, что исходный вариант был под работу с байтами, а здесь пришлось
работать с нибблами: команда и операнд - в одном байте.
Ну и я решил в этот раз совместить приятное с полезным и допилить в этот вариант корректную
работу с длинной строкой аргумента, содержащей скобки и математические операции.
Для 4-bit CPU в этом особой необходимости нет, но хочу сделать хороший программный шаблон
для компилятора ассемблера, как есть у Shaos-а.
Он оперативно адаптирует свои исходники ассемблера к разным системам комманд различных CPU,
хотя изначально он его вроде как под i8080 писал.
You do not have the required permissions to view the files attached to this post.
iLavr
-
- Supreme God
- Posts: 16701
- Joined: 21 Oct 2009 08:08
- Location: Россия
Re: Компиляторы ассемблера
В исходнике хорошо были сделаны обработчики DB (Define Byte) и DW (Define Word), поэтомуLavr wrote:Некоторые трудности были с тем, что исходный вариант был под работу с байтами, а здесь пришлось
работать с нибблами: команда и операнд - в одном байте.
решил их оставить, как есть.
По предшествующему опыту они очень удобны если есть необходимость оперативно компилировать
некий новый оператор, которого нет в наборе команд.
Я предполагаю, что должны появиться аналоги EI и DI, которых сейчас нет в наборе команд.
Ну и просто наборы символов удобно вставить в код.
Для 4-битного процессора сейчас реализую 4-битный аналог DB - DN (Define Nibble).
По структуре это должен быть полный аналог DB, типа:
Code: Select all
DN 1CH,'Press any key',0DH,0AH
Байты, определенные через DN, компилятор будет превращать в набор инструкций RETA Nibble.
Поскольку архитектура 4-bit CPU гарвардская, то массив байт в памяти программ хранится как в PIC.
То есть, в виде инструкций возврата с занесением операнда в регистр A (у PIC - это RETLW).
iLavr
-
- Supreme God
- Posts: 16701
- Joined: 21 Oct 2009 08:08
- Location: Россия
Re: Компиляторы ассемблера
Обещанного 3 года ждут, но это нехорошо по отношению к посетителям...Lavr wrote:И, может быть, как-нибуть найду у себя архив, как 2 немца написали операционную систему
на GW-BASIC.
Это, правда, будет боян от 2010 года, ...

Я покопался в своих архивах, и, вроде как, нашел то, о чем шла речь:
К архиву был текстовый файл с преамбулой:
Похоже, это как раз тот компилятор, на котором и была написана ОС. Вот только кодов ОС в моём архиве нет.Вы когда-нибудь видели компилятор, написанный на GW-Basic'е? Нет? Воображение не включается? Ну так посмотрите - это же ночной кошмар сишного программера!.. Входной язык компилятора почти полностью совместим с GW-Basic'ом. Что интересно, компилятор компилирует сам себя. В архиве также исходники небольшой IDE (тоже на Бэйсике).

You do not have the required permissions to view the files attached to this post.
iLavr
-
- Supreme God
- Posts: 16701
- Joined: 21 Oct 2009 08:08
- Location: Россия
Re: Компиляторы ассемблера
Это заработало... Байты упаковываются по нибблам в виде RETA Nibble - сначала младший ниббл, потом - старший,Lavr wrote:Для 4-битного процессора сейчас реализую 4-битный аналог DB - DN (Define Nibble).Байты, определенные через DN, компилятор будет превращать в набор инструкций RETA Nibble.Code: Select all
DN 1CH,'Press any key',0DH,0AH
Поскольку архитектура 4-bit CPU гарвардская, то массив байт в памяти программ хранится как в PIC.
То есть, в виде инструкций возврата с занесением операнда в регистр A (у PIC - это RETLW).
так удобно выдавать по интерфейсу SPI, и с 4-битными LCD работать тоже удобно.
Осталась арифметика со скобками в операнде. Она там в принципе есть, хотя совсем короткая.
В общем-то, мне трудно представить, что делать даже с 4-мя аргументами в строке операнда...
Чаще всего на практике я использую арифметику с меткой.
К примеру:
Code: Select all
MET:
CPI 41H
...
MVI A,42H
STA MET+1
JMP MET
Деление в строке аргумента удобно при работе с таймером, но тоже не требует 4-х аргументов.
Но чисто из интересу арифметику со скобками в строке операнда допишу...
You do not have the required permissions to view the files attached to this post.
iLavr