Ну на ПК то шустро работает.) Да и раньше, в CP/M всякие изгаления придумывали, типа электронного диска. А так да, флоппи елозил здорово, ходили курить пока оттранслирует.
А вообще, ассемблер достаточно серьёзный. Под 2 процессора, ну и макросредства великая вещь. Одно время хотел было перейти на другой, не под CP/M, но перепробовал 2 десятка ассемблеров и ни один не подошел. То валятся, то одного нету, то другого... Проект большой был, а перепахивать много не хотелось. Так и успокоился.)
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Это да, теперь проблем с временем компиляции нет. Но нет и проектов под Z80 - какая несправедливостьСообщение от M80
У меня с ASC CP/M был RAM-DISK. Но даже на нем ассемблирование M80 и компоновка LINK исполнялись ужасно долго.
Я с двух сторон пытался решить эту проблему. Первая - пытался сделать свой компоновщик (см. выше) - хотя бы для того, чтобы ускорить сборку проекта, когда изменения внесены лишь в один небольшой исходный файл. Вторая сторона - хотел сделать турбо и процессора, и памяти. Турбо только процессора помогало мало. Много времени потратил на попытки турбировать память. Даже работало, пока микросхемы не нагреютсяТогда, в 1995г, знаний мне не хватило, чтобы довести проект до ума.
Даа, меня впечатлила библиотека твоих макросов
Чтобы такое создать, нужно иметь обширный опыт разработки под данный процессор. Чтобы почувствовать, какие конструкции имеет смысл облечь в макросы. Чтобы, с одной стороны, не генерировать с их помощью неэффективный код; с другой стороны - чтобы объем и понятность исходного кода улучшались. И чтобы не запоминать слишком много имен и параметров этих макросов.
- - - Добавлено - - -
Да, Microsoft Macro 80. Писали не под досом, а под CP/M.
- - - Добавлено - - -
Вот, если кто желает заняться REL-файлами - продизассемблированный LIB80 (оттуда я выяснил формат REL-файлов), и моя программа RelView2, которая считывает REL-файл и выводит его содержимое на экран в человекочитаемом виде.
По сути REL-файл представляет собой битовый поток, содержащий 8-битные кодовые литералы (им предшествует бит 0 в потоке) - они встречаются чаще всего и представляют собой результат ассемблирования, не требующий релокации. Также встречаются перемещаемые 16-битные слова - для них еще задается тип сегмента (CSEG, DSEG, COMMON). И прочие команды, задающие список символов ENTRY, EXTRN, имя модуля и т.д.
Остальные подробности легко выяснить, создав и ассемблировав пару коротких исходников и посмотрев с помощью RelView2 результаты.
aGGreSSor(17.10.2025)
Ну, тут на любителя.) На самом деле, важно что бы в голове не было много новых команд, с новыми параметрами... Просто я работал с другими семействами МК, с командами которых у меня сложилась ассоциация, и которые решил применить и с Z80. А так, многим это покажется лишним... Я просто показал как можно использовать макро. И считаю что это очень эффективное средство при низкоуровневом программировании.Даа, меня впечатлила библиотека твоих макросов
Чтобы такое создать, нужно иметь обширный опыт разработки под данный процессор. Чтобы почувствовать, какие конструкции имеет смысл облечь в макросы. Чтобы, с одной стороны, не генерировать с их помощью неэффективный код; с другой стороны - чтобы объем и понятность исходного кода улучшались. И чтобы не запоминать слишком много имен и параметров этих макросов.
Но это всё от бедности.) На самом деле, если есть возможность, нужно переходить на высокоуровневый язык, дабы не дублировать написание своего кода, и продуктивность своего труда была бы выше.
Barmaley_m(28.02.2024), Oleg N. Cher(09.03.2024)
Ну, что значит, бедности? В наше время любой владелец компьютера может себе позволить программировать на ЯВУ.
Только для разных средств - разные задачи. Иногда даже современные Си-компиляторы не справляются с задачей генерации эффективного кода. Или они справляются только при условии написания Си-кода определенным образом. Нужен, как минимум, контроль результатов компиляции в ассемблере для критичных участков кода; а как максимум - написание таких участков на ассемблере вручную.
Конечно, речь идет о критичных приложениях реального времени, когда быстродействия даже самых современных процессоров может не хватить. Или памяти. Или тактовую частоту нужно снизить для снижения энергопотребления. Тогда и приходится, по старинке, выжимать последние байты и такты. Это иногда нужно, и это реально помогает. Вычислительных ресурсов никогда не бывает слишком много. И навыки их экономии всегда останутся востребованы.
Последний раз редактировалось Barmaley_m; 28.02.2024 в 18:30.
Oleg N. Cher(09.03.2024)
Ну, это понятно. Сейчас да, тогда не всегда. Либо же были какие то ограничения - по скорости ли, по объёму ли... Но, я хотел сказать, что программирование на асм, зачастую пустая трата времени. Потому что его навыки не применишь к Си и его не перенесёшь в Си. Ну, перенесёшь конечно, но только чего это будет стоить.) Это не то что если бы изначально писал на Си, пусть даже применительно к какому то семейству.
Ну а сейчас, зачастую соревнования по объёму можно провести. И асм у Си не всегда выиграет.)
ПС. Да, само собой, когда нужна скорость, приходится писать на асм. Но, одно дело, это фрагменты, а не весь проект.
Последний раз редактировалось M80; 28.02.2024 в 20:11.
Не могу со всем согласиться, но участвовать в холиваре "Asm vs C" тоже не хочется. Останемся при своих.
Ты лучше посмотри по REL-файлам
И что? Я давно не в теме, да и просто лень. Извини.) И меня l80 во всём устраивает.
Я тоже не сторонник холиваров, но когда смотрю на кучу своей писанины на асм, берёт тоска. Давеча, как то, х-модем захотелось на AVR перенести... Плевался почём зря.(
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
