Можно ли FASM сделать высокоуровневым?

Приветствую всех.
Вопрос к специалистам: можно ли с Вашей позиции FASM, с учетом наличия в нем макросов, превратить в язык высокого уровня? И если нет, то чего в нем не хватает, что нужно доработать, чтобы выполнить эту задачу?
Заранее благодарю за ответы.

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

0

flamehowk, зачем FASM делать высокоуровневым?
Теоретически всё можно, только нужно будет написать почти компилятор (парсер с преобразованием в код на ассемблере) на языке макросов fasm (или fasmg). А это задача для истинного мастера извращений

Вроде как есть какие-то реализации "высокоуровневых ассемблеров", но я с ними не знаком, не знаю как выглядит код на них и как они работают...

2

Jin X, ничего, уж до чего раньше извратились, до того мы никакими извращениями не докатимся. Благодарю за ответ.

0

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

1

Jin X, я Вашу мысль понял и по сути оно так и должно быть, но ведь нужно с чего-то начинать? Писать в машинных кодах с самого нуля - это, конечно, отлично, но я надеялся, что можно будет начать хотя бы с асма, ведь, по идее, он должен быть максимально приближен к машинному коду.
Собственно из-за того, что я прекрасно понимаю как писать в машинных кодах, так как сам разрабатываю архитектуры устройств и логику обработки сигналов под них, но при этом никогда не работал с ассемблерами, у меня имеется явный пробел в понимании того - чего они стоят. Потому и спрашиваю у специалистов, чтобы понять - в какую сторону начинать движение наиболее оптимально.
Если Вам не трудно, могли бы Вы немного расширить свою мысль и аргументировать - почему лучше в основу ассемблер не ложить? Буду весьма признателен.

0

Сообщение от flamehowk почему лучше в основу ассемблер не ложить?

Это смотря что понимать под "ложить в основу".
Можно сделать компилятор, который будет по факту являться парсером исходного кода и переводить его в fasm-код.
Т.е. в исходнике, скажем, a=b+c, а этот "компилер" будет генерировать, грубо говоря:
и дальше запускать fasm. Чтоб машинные коды не генерировать самому.
Просто писать парсер кода через макросы fasm'а - это изврат. К тому же, не получится реализовать гибкий синтаксис.
Т.е. тот же a=b+c уже не написать, т.к. надо вызвать макрос, который будет парсить a=b+c. Например, do a=b+c. Ну и много других подводных камней будет, не говоря уже об ограниченности макропроцессора fasm'а.

1

То есть Вы таки предлагаете все делать с нуля и сразу в машинный код... Но ведь мы все-равно будем ограничены архитектурой и ее возможностями, если будем ориентироваться на современные машины. Новая архитектура - отдельная тема и там еще много работы, я уже не говорю о ее реальной реализации. То есть а=в-с все равно никак не получится, придется с=~с; а=в+с; ну и тому подобное. Отсюда как ни крути вырастут макро-сборки кодов, по сути - функции, мало чем отличающиеся от асм. То есть, по сути, получается, что Вы предлагаете заново разработать Ассемблер!? но уже по некой иной, заранее сформированной ТЗ схеме... я верно Вас понял? А потом над ним сделать высокоуровневую надстройку в виде второго этажа ЯП. Так?

0

Сообщение от flamehowk То есть Вы таки предлагаете все делать с нуля и сразу в машинный код...

Ммм...

Сообщение от Jin X Можно сделать компилятор, который будет по факту являться парсером исходного кода и переводить его в fasm-код.

Сообщение от flamehowk То есть, по сути, получается, что Вы предлагаете заново разработать Ассемблер!? но уже по некой иной, заранее сформированной ТЗ схеме... я верно Вас понял? А потом над ним сделать высокоуровневую надстройку в виде второго этажа ЯП. Так?

Я про новую архитектуру вообще ничего не говорю. Работа компилятора, особенно кроссплатформенного достаточно сложна и состоит из нескольких этапов. Я в этом вопросе не спец, поэтому советов давать не буду.
Ассемблер для каждой архитектуры свой. И модули будут свои (для разных ОС). А сразу это должно переводиться в машинный код или сначала в какой-то псевдо-код, я не знаю. Читайте про устройство компиляторов...
p.s. И я не понимаю, почему нужно разрабатывать ассемблер? Ассемблер – низкоуровневый язык. Вам же нужен высокоуровневый... с возможностью вставки асм-кода, например.

0

Сообщение от Jin X Ассемблер – низкоуровневый язык. Вам же нужен высокоуровневый...

Думаю, что нам нужен язык ШИРОКОГО уровня, а значит в нем должна быть база низкого уровня, а сверху надстройка, которая на этой базе будет реализовывать высокоуровневые концепции.
В любом случае - благодарю за участие.

0

Jin X, flamehowk, синтаксис языка и конечного ЯВУ, будет зависеть, только от текущих возможностей макросов ассемблера.

0

Constantin Cat, конечно, я об этом и говорю.

0

0

Сообщение от flamehowk Если Вам не трудно, могли бы Вы немного расширить свою мысль и аргументировать - почему лучше в основу ассемблер не ложить?

Вы бы лучше пояснили, что Вы хотите получить ?
Голую самодельную архитектуру, для которой ничего нет, обуть транслятором ЯВУ ?

Транслятор ЯВУ часто создается путем написания на ассемблере, но никогда путем расширения ассемблера.
Язык, расширяя который можно создать другой язык, называется мета-языком. Но ассемблер не есть мета-язык.
К нему можно создать хоть вагон макросов-шмакросов, но он так и останется ассемблером.

Мета-языком является, например, Форт. Сам процесс написания программ на Форте является процессом расширения языка. Потому-что Форт не может различить то, что было на нем написано после от того, что существовало в нем с самого начала. Кроме того в Форте можно перекрыть все, что угодно. Хоть разбор входного потока, хоть интерпретатор. Они доступны общим порядком. В итоге Форт можно как угодно расширить, а можно и вообще путем перекрытия превратить в абсолютно другой язык, с совершенно иным синтаксисом и идеологией.

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

Но если нужно обуть голую архитектуру транслятором ЯВУ часто используют третий подход. Сначала на архитектуре у которой все есть пишут на языке А минимальный компилятор языка Б и компилируют. Минимальный настолько, лишь бы смог скомпилировать самого себя. Получают исполняемый файл. Потом переписывают тот-же компилятор на языке Б и получают исходник. Потом компилируют исходник исполняемым файлом. Когда это получается, то выходит, что был создан компилятор компиляторов, что компилирует самого себя. Потом изменяют в компиляторе компиляторов кодогенерацию под другую архитектуру и компилируют. Перекидывают исполняемый файл для новой архитектуры вместе с исходником на нее. И уже там начинают раскрутку. Последовательно дописывают исходник и компилируют предыдущей версией новую, до тех пор, пока не получат полновесный транслятор языка. Короче, это метод написания компилятора компиляторов, его кросс-компиляции на новую платформу и последующей раскрутки на ней.

Добавлено через 6 минут
Это вот если нужно расширить мысль глобальными идеями и аргументировать.

Добавлено через 14 минут

Сообщение от flamehowk Вопрос к специалистам: можно ли с Вашей позиции FASM, с учетом наличия в нем макросов, превратить в язык высокого уровня? И если нет, то чего в нем не хватает, что нужно доработать, чтобы выполнить эту задачу?

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

0

Сообщение от Constantin Cat синтаксис языка и конечного ЯВУ, будет зависеть, только от текущих возможностей макросов ассемблера.

О! Собственно обо что и был вопрос, о возможностях макросов конкретного компилятора асм. Ну ведь проще спросить, чем самому тратить время и изучать вопрос, не зная, поможет это изучение делу или нет. Как у нас говорят: "Хто пытае, той нэ блудыть".

Сообщение от Ethereal Голую самодельную архитектуру, для которой ничего нет, обуть транслятором ЯВУ ?

Это задача №2. Она не спешная и будет выполняться вместе с развитием новой архитектуры постепенно и сразу в машинных кодах - иначе никак, уж больно там все по-другому. Вот как только прототип на ПЛИСах сварганю, так и начну писать, но это еще будет не сейчас.
А была еще и задача №1 - под уже имеющуюся РИСКовую архитектуру х86-64 на базе ДРАКОНа создать транслятор, используя в качестве ЯВУ модифицированный ДРАКОН. И стоял вопрос - как лучше это сделать, писать транслятор с нуля или просто пришить лапти ДРАКОНа к fasm-у. Чтобы сделать выбор мне нужно было понять возможности макросов fasm-а, позволят ли они широко махать руками и загребать под себя все, что физически возможно реализовать на данной архитектуре. В результате было принято решение не заморачиваться и все делать с нуля. На GTK+ будет писаться оболочка под ИСР, а на С++ и ASM напишем транслятор, который будет прямо из блок-схем генерировать машинный код. Проект называется "ВАЯТЕЛЬ". Сейчас потихоньку разрабатываем идеологию, проектируем методы и всяко-разно одеваем ДРАКОНа в новую шкуру.
Вот, собственно, и все дела.

0

Сообщение от flamehowk О! Собственно обо что и был вопрос, о возможностях макросов конкретного компилятора асм. Ну ведь проще спросить, чем самому тратить время и изучать вопрос, не зная, поможет это изучение делу или нет. Как у нас говорят: "Хто пытае, той нэ блудыть".

Так, мы ж уже об этом говорили выше, неоднократно, причём

1

Я отвечал Constantin Cat-у...

0

Вы спросили:

Сообщение от flamehowk можно ли . . . FASM, . . . превратить в язык высокого уровня?

Вам ответили:

Сообщение от Jin X Теоретически всё можно . . . это задача для истинного мастера извращений

Представьте, что есть несколько чисел и нужно с ними сделать несколько операций. С помощью ЯВУ-ассемблера получится приблизительно такой код:
Даже при беглом просмотре видно, что длина кода многократно увеличилась на ровном месте, оптимизация по скорости пропала, потерялся сам смысл языка ассемблер. Причиной этого являются макросы, т.к. они живут сами по себе, им безразлично, что делал макрос до него или будет делать после. С таким же успехом, можно в Delphi получить исполняемый файл такой же длины, что и с помощью ЯВУ-ассемблера, при этом не напрягая мозги наличием всяких там макросов.

Спрашивается: на кой мне такой ЯВУ-ассемблер?

0

По поводу транслятора графического языка Дракон в машинный код:

1. Возможно, что решение имеет смысл искать после рассмотрения структур аналогичных проектов. Первое, что приходит на память - несколько проектов компилятора FBD (графический язык, подобный составлению электрической схемы из микросхем) для микроконтроллеров AVR и PIC. Там FBD транслировался в C, а потом avr-gcc превращал это в файл прошивки. Как понимаю, это было попыткой избежать проблемы макросов за счёт оптимизатора gcc (ну и плюс не нужно самостоятельно следить за развитием семейства процессоров). Ну и существующие разработки ДРАКОНа не стоит забывать.

2. Сейчас существует оптимизационная прослойка для C (и нескольких других языков), позволяющая дополнительно оптимизировать код - LLVM.

Ссылки на FBD for AVR
Графический язык ДРАКОН для программирования микроконтроллеров
http://flprog.ru/
http://flprogwiki.ru/wiki/inde... зделы_Wiki
http://horizontautomatics.ru/ - FBD --> assembler
http://cq.cx/ladder-ru.html

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

0

Сообщение от Constantin Cat Даже при беглом просмотре видно, что длина кода многократно увеличилась на ровном месте,

В корне с Вами не согласен, почему-то создается ощущение, что Вы не совсем понимаете что такое макрос и зачем он нужен. Конечно, не спорю, макрос можно написать так, что он будет увеличивать длину кода и даже уничтожать оптимизацию на корню - но зачем же его так писать, если такой цели не стоит?

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

Сообщение от ФедосеевПавел Там FBD транслировался в C, а потом avr-gcc превращал это в файл прошивки.

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

Сообщение от ФедосеевПавел Считаю, что в данной теме добавить нечего.

Давно согласен, тему можно закрывать.

0

Разобрался, кое что почитав, откуда взялось "макроподстановка = подпрограмма".
А вот если

Сообщение от flamehowk я никогда не работал по профессии программиста

а потом основательно забытое со студенческих времен восстанавливать вот по такой макулатуре
http://drakon.su/_media/biblio... iption.pdf
а там смотрим страницу 59 и читаем
Икона "Вставка" - это команда "Передай управление в процедуру".
ЧТО ТАКОЕ ПОДСТАНОВКА ?
Операция "подстановка" связана с использованием иконы-вставки.
Вот все в голове и замкнулось. Подстановка=макроподстановка стала передачей управления в процедуру=подпрограмму.

З.Ы. Книга написана бывшим начальником над программистами при разработке Бурана. Не программистом. А язык Дракон был разработан и использовался для записи тех.заданий для программистов. Точнее алгоритмов самого верхнего уровня для разрабатываемого устройства. А детализация нижнего уровня оставлялась исполнителям. Позже (с 2010 кажется) автор Дракона зачем-то начал пиарить его как универсальный язык и новое слово в программировании. Думаю, уже старческий маразм пошел. Можно извинить.

Добавлено через 4 минуты
З.З.Ы. Дракон, видимо, привлекателен для тех, кто так и не осилил научиться программировать. Ибо там все ясно понятно. Можно ли из него сделать какую-нибудь конфетку - вопрос. Но сильно вряд ли. Уж очень нишевое средство, хотя в своей нише может быть и красивое.

0