Кроссассемблеры для 8080?

[Shaos]

На самом деле хардкод подобного рода считается очень плохим тоном среди современных программистов
Ну что есть, то есть - как уж написал в конце 90-х, а переписывать времени нету...

А вот этот момент не понял, что за "хардкод подобного рода считается очень плохим тоном среди современных программистов"?
Я тут, ты сам видел, гуглил примеры обработки строки на стеке - у всех очень похожие алгоритмы.

У правильно написанного алгоритма парсинга не должно быть ограничений на глубину стека или длину строки - все контейнерные типы данных должны иметь возможность динамически расти в размерах по мере нобходимости (как например при использовании библиотеки STL в C++), т.е. по сути в современных правильно написанных программах единственным ограничением является объём памяти компьютера, а не искусственные "захардкоденные" пределы типа глубины стека 200 или длины строки 1000

[Lavr]

У правильно написанного алгоритма парсинга не должно быть ограничений на глубину стека или длину строки - все контейнерные типы данных должны иметь возможность динамически расти в размерах по мере нобходимости...

Золотые слова! Надо в рамку выделить!
Вот этого я и хотел достичь, пока в разных топиках про ассемблеры "мучал" всех вас вопросами.
Но оргвывод только один для этого: массивы для стека и т.п. должны объявляться, как динамические.
В этом ничего сложного в принципе нет, даже в тех языках, где массив динамически объявить нельзя.
Сталкивался я раз с такой проблемой - решаемо...

Просто не всегда это легко вделать в существующий уже исходник - иногда проще переписать заново.
Я вот сейчас с трудом пытаюсь это сделать. Ассемблер был написан отдельно, про обработку строки
я задумался в самом конце.
Отдельно попробовал алгоритм со стеками - он работает, но в исходник вписывается тяжело.

А число 200 я выбрал из следующих соображений:

...в "Орионовских" ассемблерах возможны столько действий сложения и вычитания,
сколько уместится в текстовой строке на 64 символа.

Я утроил 64 и округлил.
В ассемблере "Специалиста" размер стоки 128 символов, хотя позже обрезали до тех же 64, но по идее
и для него 200 должно хватить, не бывает же строк из сплошных мат.операций...

[barsik]

У правильно написанного алгоритма парсинга не должно быть ограничений на... длину строки

С академической точки зрения может быть. Но с практической точки зрения применительно к реальному программному продукту это вызовет лишь впустую затраченные усилия программиста.

Конечно ассемблер не должен зависать, если длина выражения излишне большая. Для этого достаточно ввести обнаружение ошибки "слишком длинная строка" и описать это ограничение в документации на ассемблер. Для PC с неограниченным ресурсом памяти и скорости можно делать всё идеально, но когда пишется ассемблер на слабое железо необходим компромисс.

И объясните пожалуйста незнающему теорию и малоопытному программисту на ассемблере зачем в процедуре вычисления выражения нужен стек данных глубиной в 200, 1000 или бесконечно большой. Т.е расскажите подробно об алгоритме вычисления выражений, который это требует.

Очень давно я написал процедуру вычисления выражения совсем без стека данных (и потому без вложенности скобок), но ясно, что для получения некоторой, иногда нужной на практике, вложенности скобок достаточен небольшой стек для промежуточных данных глубиной 3-4, не более.

В процедуре не допускающей вложения скобок использовался такой алгоритм. Подпрограмма LEXEMA, используя текущий указатель по строке, возвращает код, соответствующий текущей лексеме или 0 (код ошибки). Это позволяет узнать, что далее следует оператор ассемблера (мнемоника команды, регистр), псевдокоманда, имя метки, имя макро-команды, число, знак операции, открывающая скобка, закрывающая скобка, конец строки или точка с запятой (и м.быть ещё что-то, уже не вспомнить).

До открывающей скобки выражение вычисляется линейно, формируя переменную RESULT (это число является результатом работы п/п-ммы вычисления выражения, возврат из этой п/п-ммы происходит по обнаружении конца строки или закрывающей скобки). Если же в начале выражения (или в ходе обслуживания операции) встречается открывающая скобка, то переменная RESULT копируется в TMPDIG и снова, т.е рекурсивно вызывается подпрограмма вычисления выражений (при входе в п/п-мму указатель позиции указывает на открывающую скобку, а при выходе - на позицию сразу за закрывающей скобкой).

Таким образом после разбора выражения в скобках возвращается число и никакой стек для строчных символов или промежуточных результатов не нужен. Но вложение скобок при этом невозможно. Алгоритм на самом деле чуть сложнее, т.к надо учитывать приоритеты операций до и после скобок.

Чтобы получить возможность иметь в выражении вложенные скобки достаточно ввести стек чисел и операторов вместо одной промежуточной переменной TMPDIG. Например, встретив после знака операции, например плюса "+", символ открывающей скобки, двухбайтовое число из переменной RESULT заносится в стек вместе с кодом операции сложения и снова рекурсивно вызывается подпрограмма вычисления выражения. Так как каждый текущий результат при всрече очередной открывающей скобки помещается в стек, то допустимо вложение скобок глубиной в размер стека. А т.к на практике в ассемблере обычно не встречаются выражения с вложением скобок более двух, то достаточно стека глубиной в 3-4.

Поэтому не понял зачем в подпрограмме вычисления выражений может понадобиться стек большей глубины. Интересует Ваш алгоритм со стеком и вопрос будет ли это проще описанного алгоритма.

[barsik]

Я бы тут поспорил, не всегда используются константы, иногда действия нужно провести с переменными.
P.S. Я ассемблер знаю...

Тут не важно каким инструментарием реализован алгоритм процедуры разбора выражений. Это м.быть как подпрограмма на ассемблере, так и процедура на Паскале или Си. Я использовал ассемблер, лишь потому, что тогда ассемблер уже знал, а ЯВУ ещё нет.

Не понял о каких переменных идёт речь. О переменных программы (а это просто байты в ОЗУ для которых задана адресная метка) или о переменных ассемблера. Они в отличие от констант, что однократно задаются оператором EQU могут меняться оператором SET многократно. Для ассемблера нет переменных программы, для него они просто адресные метки, т.е просто проименованные двухбайтовые числа занесённые в первом и втором проходах в таблицу меток. Т.е в ассемблерах метками считаются все проименованные числа, что хранятся в таблице меток - реальные адресные метки, константы и переменные (что по сути те же константы, но которые можно изменять в ходе трансляции и в зависимости от их значения менять поведение компилятора или ход трансляции).

И конечно речь идёт о полноценном ассемблере, а не о примитивном, потому под выражением понимается любое выражение содержащее как числа (DEC, HEX, OCT, BIN), константы (они задаются по EQU), адресные метки, так и переменные (они задаются оператором SET и по ходу трансляции могут меняться).

Т.о при вычислении выражения процедура вычисления выражения "знает" адрес начала таблицы меток (её структура: 6 байт имя, 2 байта значение, т.е шаг 8 ), в которую кроме адресных меток, также занесены и константы заданные по EQU и переменные заданные по SET. Для ассемблера все эти именованные числа совершенно равнозначны. Узнав (после вызова подпрограммы LEXEMA), что следующая лексема это метка, константа или переменная, ассемблер начинает сканировать таблицу меток в поисках 6-ти совпадающих байтов имени, и найдя, просто извлекает из таблицы двухбайтовое значение.

Вопрос о том, чем плох линейный алгоритм вычисления выражений?

Имеется текущий RESULT, встретив лексему "знак операции", например оператор MOD, выполняется (табличный) переход на процедуру вычисления "взятия выражения по модулю". Эта процедура, имея на входе указатель по строке указывающий на байт следующий за словом MOD, считывает из строки число (или рекурсивно вычисленное выражение), берёт текущий RESULT, делает вычисления над этими двумя числами (в случае операции MOD делит RESULT на число, считанное из строки, и полученный остаток от деления помещает в RESULT) и делает возврат из процедуры обслуживания оператора MOD.

Как видите, какие бы ни были знаки операций (арифметические, битовые или логические) нет никакой нужды в стеке данных (до тех пор пока не используется вложенность скобок). Линейный алгоритм, мне кажется, должен быть проще, чем хитроумно преобразовать строку в какую-то странную обратную польскую запись, а затем стеково вычислять это выражение. Или строить сложное дерево. Эти алгоритмы очень сложно даже объяснить словами. А ещё их сложно сделать на ассемблере.

На всякий случай уточню. Под стеком данных имеется ввиду вовсе не аппаратный стек процессора (речь же не о форте). Аппаратный стек в ассемблере занят для обычных целей, как в любой программе (для хранения адресов возврата из подпрограмм). Стек данных организуется программно, для чего есть две подпрограммы PUT и GET (аналоги PUSH и POP, но эти имена для меток в ассемблере запрещены). Кстати, для процессоров у которых два стека (обычный стек программы и стек пользователя) стек данных может быть аппаратным.

При вызове PUT число из HL заносится в программную структуру имеющую шаг в 2 байта и указатель стека (программный, т.е просто двухбайтовое число под меткой UKAZSP) сдвигается на 2 адреса. При вызове GET делается обратное и в HL возвращается значение из стека данных.

Стек данных нужен для того чтобы встретив открывающую скобку, где-то запомнить текущий результат вычисления выражения и следующий знак операции, чтобы освободить переменные процедуры вычисления выражений для новой рекурсии. Кстати, знак операции в ассемблере это не обязательно один символ, например: AND, XOR, EQ, LT, SHR, HIGH. Потому в стеке сохраняется не символьная строка, а соответствующий однобайтовый код (возвращаемый процедурой LEXEMA).

Кстати, тут видно, что аппаратный стек удобнее иметь двухбайтовым, как это сделано во всех процессорах, кроме 8-ми разрядных моторолла-производных (6800, 6502, 6809). Из-за этого компиляторы для этих процессоров оказываются более громоздкими, а генерируемый ими результирующий код - менее эффективным.

P.S. Был бы благодарен, если бы кто-нибудь дал мне готовый REL-модуль прогрессивной процедуры вычисления выражений. Могу дать в обмен свой аналогичный REL-модуль, который видимо уже в ближайшие годы доработаю до вложенности скобок.

- - - Добавлено - - -

В принципе, тут речь не об кроссассемблере, а вообще о любом ассемблере. Поместил 2 поста сюда, т.к вопрос о стеке и всё-равно тут обсуждение и до меня "заоффтопилось" на компиляторы КР580 на родной платформе. Логично было бы эти мои посты поместить в тему просто "Компиляторы ассемблера".

Но сейчас тема "Компиляторы ассемблера" заполнена обсуждениями не ассемблера, а наоборот, кроссассемблера, причём 4-х разрядного (что как бы немножко иная тема, чем ассемблер для 8-ми разрядной ретро-ЭВМ, что по умолчанию подразумевается исходя из основной тематики форума). Потому если добавить туда эти 3 поста, то возникнет "салат", неудобный для чтения.

Если хотите, то можно перенести 3 последних поста в тему "Компиляторы ассемблера", убрав оттуда обсуждение 4-х разрядного кросс-ассемблера (в данную тему или в отдельную).

Есть ещё неудачный вариант выделить отдельную тему "Вычисление выражений в ассемблере и бейсике" и настрогать туда вырезки постов из всех тем, где обсуждается вычисление выражений. Хотя непонятно тогда, что обсуждать в темах про сами ассемблеры и эти темы станут почти пустыми.

И раз уж 80% этой темы уже сползло от темы кросс-ассемблеров 8080 на просто ассемблеры 8080, м.быть разумно сменить название темы на "Кроссассемблеры и ассемблеры для 8080" или "8080 (кросс)ассемблеры" или "Инструменты для программирования на ассемблере 8080".

А вообще эта тема очень давно родилась как вопрос "где скачать кросс-компилятор?". Но этому посвящены лишь посты, что идут в самом начале темы. А затем разговор переключился на другое "как писать компилятор", какие общепринятые соглашения, каковы алгоритмы отдельных процедур внутри компилятора.

Может быть разумно сделать две темы: "Где скачать кросс ассемблер 8080" (пополнив тему новыми ссылками) и тему "Компилятор ассемблера 8080" или даже "Некоторые аспекты написания компилятора ассемблера" или что-нибудь подобное.

[barsik]

Ну вот, по отсутствии реакции, видно, что никому неохота разбираться в каком-то рекурсивном спуске и построении каких-то деревьев (или хотя бы низкорослых кустарников). Если любители и пишут ассемблер, то используют лобовой линейный алгоритм разбора выражений.

Ретро-программистов в этом хобби всегда было мало. Гораздо больше в этом хобби любителей запаха канифоли. И раньше так было, а теперь особенно. Программистов для ретро платформ остались единицы и среди них желающих трахаться над написанием приличного ассемблера и тем более для реального железа, похоже, вообще нет. Т.е никого не интересуют сложные нюансы программной реализации компиляторов. Как говорил Эркюль Пуаро "Никому неохота без необходимости напрягать свои серые клеточки".

Понятно, что сейчас, когда есть доступ к нескольким десяткам разных кросс-ассемблеров, уже нет необходимости писать свой, а тем более ассемблер на родной платформе. Я поднял вопрос лишь имея ввиду доработку самодельного ассемблера. Что имеет смысл лишь чисто из спортивного интереса, т.к ныне все программируют на PC, а на реале лишь проверяют результат.

С начала 90-тых мне для всех нужд ассемблирования хватает CP/M-ассемблера Microsoft M80, который можно запускать под TSR-эмулятором CP/M в Windows XP (но не более поздних, они не запускают напрямую программы MSDOS).

Но сохранились старые исходники с единственным разделителем 0D, двоеточиями в EQU и, главное, метками с русскими буквами и символом "?". На то, чтобы переделать одну такую программу, чтобы она транслировалась М80, приходится тратить по часу и более на ручную коррекцию исходника.

Если утомительно редактировать, то остаётся вариант использования "реала" или эмулятора ОРИОНА (или, если ОЗУ хватает, РК86) и запуск в нём соответствующего ассемблера или макроассемблера. Это результат даёт, но неудобно, если надо разобраться или что-то изменить, т.к при этом исходник остаётся в неудобных мнемониках КР580, которые уже мало кто понимает (и нельзя конвертировать в мнемоники Z80).

Более удобен кросс-ассемблер, аналог МИКРОНА, написанный в кодах 80x86 работающий в Windows или хотя-бы в MSDOS и лучше даже с IDE подобном ASMIDE. Для мнемоник КР580 и Z80. Возможный путь получения этого, - это конверсия программы КР580 в программу в кодах 8086 и снабжение её загрузчиком исходного файла и "выгрузчиком" на винчестер результирующего объектного кода.

К сожалению, конверсия исходников КР580 в 8086 для программ написанных с извратами очень утомительна. А это практически 95% программ любителей (только новички, которые ещё не познали пользы извращений, писали "нормальные" программы, что конвертируются без хлопот). Без проблем конвертируются лишь программы любого размера написанные на ЯВУ, т.к компиляторы не используют привязанных к кодам CPU программистских трюков.

Конверсия не составит особых проблем, если сам автор программы займётся конверсией своей программы изначально написанной для КР580, особенно, если автор сразу привык писать без использования кодо-привязанных извращений.

К сожалению, исходники программ написанные для Z80 или для КР580ВМ1 никак не конвертировать в исходник 8086. Такие программы требуется переделать для КР580, что иногда сложно и даже не всегда возможно (например, Турбо-Паскаль невозможно переделать под КР580, т.к в нём не хватает индексных регистров).

Или, что интереснее и полезнее, можно сразу написать компилятор ассемблера 8080 / Z80 на каком-либо ЯВУ и странслировать для Windows. Можно даже на презренном бейсике (например Power-бейсике для Windows).

Конечно уже есть несколько самодельных кросс-ассемблеров 8080 разработанных любителями. Но не видел таких, что транслируют программы в формате МИКРОНА, и большинство из тех, что я видел используют непривычную моторолловскую лексику ассемблера.

Эта извращённая мода возникла из-за табличного ассемблера TASM. Он был написан в 80-тые сначала для 6502 и 6800, в которых и приняты такие соглашения для ассемблера, а затем в него лишь добавили таблицы для Intel-производных процессоров.

Из-за этого ассемблер TASM для других процессоров стал похож на моторолловский. А ни один профессиональный ассемблер КР580 / Z80 из 70-тых, и 80-тых не использовал моторолловские операторы и потому программисты для КР580 / Z80 привыкли к иному. Лично я ненавижу TASM и, соотвественно, все другие ассемблеры, что похожи на него. К тому же он убогий, т.е в нём меньше макро-возможностей, чем у М80. Когда я вижу что-то подобное, меня тошнит и такой ассемблер я сразу удаляю.

Вышеизложенным я лишь изложил мысль, что ниша кроссассемблеров КР580 / Z80 для Windows в принципе ещё не закрыта.

[shoorick]

Я когда писал макросы команд 8080 для fasmg, не ставил перед собой целью совместимость с форматом ассемблера Микрон, но если загвоздка именно в этом, думаю, это возможно. Наоборот, меня просили сделать совместимость с ассемблером ТАСМ: несколько операторов в одной строке, разделенных косой чертой, тогда как косая в фасме наоборот позволяла разбить длинную строку на несколько, но Томаш (автор фасма) написал макрос и это решил.

[barsik]

форматом ассемблера МИКРОН, но если загвоздка именно в этом

На форумах часто встречаются рекомендации, что новичку изучающему программирование на ассемблере удобнее и проще начать с пакета МИКРОН (в реале или эмуляторе), но я считаю, что это плохой совет, а этот пакет, отличный для 1986, будучи перенесённым на несколько других платформ, позднее стал тормозом в программировании.

Хотя при изучении ассемблера и написании маленьких программ с МИКРОНОМ получается быстрее, чем в CP/M с отдельным редактором и ассемблером, но я считаю, что изучать ассемблер разумнее сразу в мнемониках Z80, они намного более удобны для программиста и легче осваиваются. К тому же изначально в пакет МИКРОН входит совсем убогий и неудобный редактор.

Не знаю, как для других, кто сохранил исходники программ из 80-тых и начала 90-тых, но для меня использование исходников в формате МИКРОНА стало неактуальным, - почти все из двух десятков сохранившихся КР580 исходников в формате МИКРОНА, потратив на ручное редактирование кучу времени, я уже конвертировал в Z80 исходники в формате CP/M-ассемблеров и поудалял оригиналы.

И вряд-ли осталось много людей, кто сохранил исходники в формате МИКРОН и сейчас нуждается в их перетрансляции или тех, кто и сейчас набирает тексты микроновским редактором (редактор МИКРОН-1 совсем плох, а МИКРОН-2 нормально-экранный). Так что реально нет нужды в изготовлении макроса для ассемблера FASMG для исходников в формате МИКРОНА.

К тому же, похоже, для MSDOS или Windows нет текстового редактора, который мог бы редактировать тексты в формате МИКРОНА (хотя загружать такие файлы может UltraEdit). Редактирование и создание таких файлов я делал UltraEdit-ом, редактируешь как нормальный текст, а перед записью в файл конвертируешь табуляции в пробелы, в HEX-режиме удаляешь байты 0A и ставишь в конец FF, после чего запускаешь конвертор из АЛЬТ-кодировки в КОИ-7.

Гораздо разумнее сделать не ассемблер для исходников в формате МИКРОНА, а конвертор таких файлов в формат CP/M-ассемблеров, желательно сразу с заменой мнемоник КР580 в мнемоники Z80, чтобы не требовалось затем запускать отдельный конвертор.

Впрочем МИКРОН (не весь пакет, лишь ассемблер) сохранил актуальность для ROM-диска ОРИОНА и РК86. Вместе с редактором (но другим, экранным с блоками) он прошит у меня в ROM-диске. Он нужен, когда дисковод или КНГМД сдох или просто отсутствует. Написать крошечную отладочную программку для железа проще в редакторе, чем в миниассемблере отладчика MONS (который у меня тоже прошит в ROM-диске).

 spoiler

.
Несколько слов почему МИКРОН, да и все ассемблеры которые выдают на выходе сразу объектный код плохи. Серъёзные программисты такие ассемблеры не используют.

Понятно, что небольшую программку, размером в 4-5 кб можно написать и в виде одного файла размером в 80 кб. Удобнее разбить файл на модули и использовать часто используемые подпрограммы в виде файлов библиотек (используя для их создания программу библиотекарь). Но основной недостаток не в удобстве редактирования, а в выходном формате.

Профессиональные ассемблеры создают перемещаемый REL-формат, стандартный для всех компиляторов 8080 / Z80 платформы (и для 6502 тоже). Это позволяет отдельные модули хранить уже в странслированном виде, обмениваться REL-файлами и включать чужие модули в свою программу, без необходимости иметь исходник. К тому же серъёзные программы обычно пишутся не одним человеком, а коллективом, потому разбиение на модули и их независимая трансляция это просто необходимость.

А при трансляции в реале, независимая компиляция существенно ускоряет. Зачем тратить 10 минут при трансляции всей программы (впустую изнашивая дисковод), если был изменён только один модуль, достаточно перетранслировать только его, потратив минуту на это и линковку. Кроме того, на 8-ми разрядке (в силу мизерности её ОЗУ) программа из модулей в целом транслируется быстрее, чем один огромный файл исходника в 300 кб, который будет транслироваться полчаса.

А для 8-ми разрядки без дисковода линкующие ассемблеры одновременно решают проблему, которая является главным недостатком пакета МИКРОН - ограничение размера объектного кода (на РК86 это 2 кб, на ОРИОНЕ 3 кб). Это позволяет на бездисководном РК86 создавать программы с объёмом кода в 28.5 кб. Первый ассемблер с линковщиком для отечественной восьмиразрядки написал А.Вакуленко в 1993, хотя при наличии CP/M в этом уже не было необходимости.

Кроме того, что и есть самое главное, использование REL-формата позволяет удобно включать в программу написанную на ЯВУ фрагменты на ассемблере. И даже наоборот, включать в программу написанную на ассемблере сложный для ассемблера фрагмент написанный на ЯВУ.

Потому, если любительский кросс-ассемблер для 8080 / Z80, даже качественный, на выходе выдаёт лишь готовый объектный код, а не стандартный REL-формат, то он и даром не нужен, т.к это лишь очередная бесполезная программка для новичков изучающих ассемблер, не кардинально лучшая, чем пакет МИКРОН.
.

[shoorick]

 

на всякий случай уточняю: под названием темы я понимаю "ассемблеры, которые генерируют код для 8080, но выполняются на иных процессорах"

что изучать ассемблер разумнее сразу в мнемониках Z80

не все с этим согласны, и для этого есть ассемблеры для Z80, можно их и использовать, в т.ч. fasmg.
хотя никто не запрещает применять и другие мнемоники, например, х86:

Code: Select all

0000 3E 05       MOV A,5
0002 32 17 04    MOV [LIVES],A

и т.п.

транслятор мнемоник может оказаться нетривиальной задачей, это практически ассемблер, генерирующий другие мнемоники, хотя в простых случаях может быть и sed справится

что касается выходных перемещаемых форматов - при наличии описания вполне возможно генерение тем же фасмом, для этого в команды, использующие адреса, нужно добавить код для помещения соответствующих меток в таблицу перемещения. для таблиц переходов также можно описать аналог dw, который на самом деле будет понимать, что в нем находяться адреса, которые нужно релоцировать, а не просто двухбайтовые слова. единственное но - кому это интересно и кто это будет делать? с каким яву связывать? для меня 8080 перешел в ранг микроконтроллера, мне гораздо комфортнее склепать прогу на "младшем брате" и потом ему скормить - и никаких проблем с объемом текста, длиной строки и инлайн-математикой.

[barsik]

изучать ассемблер разумнее сразу в мнемониках Z80

не все с этим согласны

Да, конечно. Но это происходит лишь потому, что отечественной учебной литературы намного больше для КР580 и часто используется журнал "Радио". А у тех кто пробовал и то и то, никогда не возникало сомнения, что мнемоника Z80 более удобна. А т.к она более логична и без перевода понятна любому англоязычному, то и освоение ассемблера в мнемониках Z80 проходит легче. Спор на эту тему считается "холиваром", но он возникает не из фактов, а из упрямства, вызванного нежеланием переучиваться в ситуации, когда к чему-то сильно привык и всё и так устраивает.

транслятор мнемоник может оказаться нетривиальной задачей, это практически ассемблер, генерирующий другие мнемоники

Тут не соглашусь. Это же просто поиск и замена в тексте одних слов другими. Сложность ассемблера и конвертора мнемоник несопоставимы. Конвертор пишется за один день, а ассемблер пишется много месяцев и дорабатывается годами. Потому конверторов мнемоник много, их писал каждый второй, а хороших ассемблеров единицы.

что касается выходных перемещаемых форматов - при наличии описания вполне возможно генерение тем же фасмом...

Нет смысла заставлять FASMG заставлять делать то, на что он не рассчитан.

Кому это интересно?

Ещё остались программисты для 8-ми разрядок, кто использует ЯВУ, а не исключительно голый ассемблер. Хороший новый инструментарий всегда найдёт применение.

Для PC это не так, а для 8-ми разрядки из-за её скоростных ограничений, что-то приличное можно получить, только используя для написания всех критичных к скорости процедур ассемблер. А также для сокращения размера кода программы, и всех простых процедур, что легко переписать на ассемблер. На ЯВУ оставляют только сложные участки программы, которые в силу их сложности, слишком трудоёмко написать на ассемблере.

... и кто будет это делать?

А делать, возможно, уже никто не будет, это даже на ЯВУ сравнительно сложно и всё-равно лучше М80 не получится. Кросс-ассемблеры КР580 сейчас пишут скорее из спортивного интереса, чем из неотложной необходимости. Потому и выбирают чаще КР580, т.к ассемблер Z80 написать намного сложнее.

С каким ЯВУ связывать?

Без разницы с кодом от какого ЯВУ производится линковка ассемблерного модуля, REL-формат у них стандартный.

[shoorick]

Нет смысла заставлять FASMG заставлять делать то, на что он не рассчитан.

FASMG как раз и есть генератор кода, предназначенный в основном для построения ассемблеров. Понимаемый синтаксис и формат получаемых файлов определяется написанием соответствующей системы макросов.

[jdigreze]

Несколько слов почему МИКРОН, да и все ассемблеры которые выдают на выходе сразу объектный код плохи. Серъёзные программисты такие ассемблеры не используют.

Серьёзные программисты... Таких у нас, на постсоветском, наверно, каждый второй, а вот действительно хороших программистов крайне мало. И сдаётся мне, что от системы образования это. IMHO.

К тому же серъёзные программы обычно пишутся не одним человеком, а коллективом, потому разбиение на модули и их независимая трансляция это просто необходимость.

Скорее исключение, нежели правило. Во всё время существования восьмибиток большая часть программ, в том числе серьёзных, писалось "в одну каску". Исключения - по пальцам пересчитать.
А трансляция с линковкой - дисководная блажь. То же скажу про 80Кб исходников одним куском. Если программа была действительно большая - били на обозримые законченные куски, компилировали под заданные адреса, а потом уже сращивали бинарники в единый файл.

[barsik]

Серьёзные программисты. Таких... наверно, каждый второй, а вот действительно хороших программистов крайне мало. И сдаётся мне, что от системы образования это.

Видимо имеется ввиду сфера современного профессионального программирования. Современный программист должен усвоить на несколько порядков больше информации, чем программист 8-ми разрядки. Ещё должен непрерывно учиться. И это даже не каждому под силу.

А в сфере 8-ми разрядок и их ассемблера всё совсем иначе. Ассемблер для 8-ми разрядки можно было изучить за час, освоить за день и этих знаний хватало на последующие 30 лет. Также и древние классические ЯВУ просты, изучаются легко и быстро. Это и делает ретро-программирование доступным и приятным.

Хорошим программиста делает опыт. Важны способности и энтузиазм, даже фанатизм. Некоторые имеют лучшие способности или больше фанатизма и достигают высокого уровня программирования за месяцы. У других на это уходят годы. Но в итоге все программисты на ассемблере достигают примерно одного уровня. Программист на ассемблере, который написал всего 50 тысяч строк, не намного уступает в эффективности тому, кто написал 500 тысяч строк ассемблера.

Потому отличие в эффективности может вызываться только тем, что один программист грамотно использует макро-ассеблер с линковкой, а другой использует неэффективный любительский ассемблер.

А трансляция с линковкой - дисководная блажь

Это не блажь, а острая необходимость в разы повышающая эффективность работы программиста. А в случае отсутствия дисковода - на порядки.

Типичная программа 8-ми разрядки это 8-12 тысяч строк ассемблера. Такая программа обычно разбивается на 10...20 файлов (это основные модули с расширением ASM и инклюдэ-файлы с расширением INC). В одном файле в 10 тысяч строк легко запутаться и это очень неудобно для редактирования и трансляции.

Специально посчитал сколько байтов приходится на строку в пяти разных программах размера от 7 до 10 тысяч строк. Получилось, что в среднем строка занимает 19...22 байта. В программе на Си в тысячу строк с куском на ассемблере 80x86 в 21 тысячу строк (в 18-ти файлах) оказалось 24 байта на строку.

Каждая строка ассемблера транслируется в ~1.3 байта. Теперь можно считать. Исходник программы в 2 кб (почти без комментариев), имеет размер в 1600 строк и размер файла в 32 кб. Для РК86, чтобы странслировать 2 кб надо исходник изуродовать, удалить комменты и форматирование, только тогда объёма ОЗУ хватит для трансляции. ОРИОН имеет в 1.5 раза больше сплошного ОЗУ, что позволяет странслировать код до 3 кб. Средняя программа с размером кода в 10 кб имеет 8000 строк ассемблера и ~200 кб исходников.

Если программа была действительно большая - разбивали на обозримые законченные куски, компилировали под заданные адреса, а потом уже сращивали бинарники в единый файл.

А Вы сами это делали, хоть раз? Без линкующего ассемблера это каторжная работа.

Даже чтобы странслировать МИКРОНОМ крошечную программу в 4 кб, её надо разбить на 2 куска, каждый кусок транслировать по отдельности, задавая в исходниках перекрёстные ссылки вручную. Т.к МИКРОН не позволяет даже передать таблицу меток из одного исходника в другой, то приходится вручную переписывать на бумажку десятки и сотни адресов меток и вручную набивать их в каждом из исходников. Причём повторять эту кошмарную процедуру приходится при каждой перетрансляции. А при написании программы транслировать приходится сотни раз.

Из-за этого даже при написании всего лишь двухблочной программы в 4 кб очень хочется сбросить бездисководный компьютер с 9-го этажа. Скорость разработки падает в разы. А если программа имеет размер более 4 кб, то надо транслировать и монтировать вместе уже 3 куска. Проще сразу повеситься. Потому для РК86 программы с размером более 4 кб написаны на кросс-ассемблере для "Электроники-60".

Однозначно, что нелинкующий ассемблер, не позволяющий разбивать большую программу на модули (при необходимости применяя ЯВУ для сложных модулей) и извлекать нужные в конкретной программе подпрограммы из библиотек, не годится для разработки серьёзных программ

[Lavr]

А трансляция с линковкой - дисководная блажь. То же скажу про 80Кб исходников одним куском. Если программа была действительно большая - били на обозримые законченные куски, компилировали под заданные адреса, а потом уже сращивали бинарники в единый файл.

Вот тут вынужден не согласиться.
Конечно, для трансляции с линковкой какой-то носитель большого объёма нужен.
Но уже в "Специалисте" с RAM-диском и ОС RAMFOS трансляция с линковкой была предусмотрена.
По той простой причине, что в противном случае саму ОС RAMFOS на ассемблере было бы невозможно
собрать.

Я не знаю, использовали ли в фирме Афанасьева из Магнитогорска кроссассемблеры для 8080, но когда
я сам декомпилировал RAMFOS, пришлось аккуратно разделить его, чтобы собирался он потом с линковкой,
в противном случае был выход за допустимую верхнюю границу памяти.
И это при всём при том, что в пакете RAMFOS "Специалиста" Редактор и Ассемблер загружались
в верхние адреса, подменяя друг друга, а область памяти с 0000Н до примерно 7FE0H отводилась
под исходный код и компилируемый бинарник.

[jdigreze]

Понимаю, что затронутая тема заведомо холиварная, ибо у каждого свой собственный опыт и своё видение.
По-этому поместил серым цветом. И нет никакого желания спорить. Бессмысленно и бесперспективно.

P.S. barsik, если б сам не собирал большие бинарники описанным способом, то, наверно, сам бы не поверил. Самые большие непрерывные исходники на асме у меня бывали под 40 Кб. Бинарники собирал около 30 Кб, это только код, без предопределённых данных, типа таблиц и прочих текстов. Так что нет в этом ничего необычного, просто тетрадка с описанием блоков под рукой всегда. До сих пор всегда тетрадь под рукой, что под электронику, что под программирование. Правда тут решил подробно изучить систему версионироания GIT. Этим сейчас и занимаюсь.