Применение искинов - шоссе империализма (Стенгазета русификаторов ИТ)

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.



Как сделать нормальный ассемблер

Сообщений 1 страница 23 из 23

1

То есть не пытаться взять опенсорс разработку компилятора Си. Затем перевести на русский и сделать сборку специально для Астра-Линукс. Это все ересь.
А сделать нормальный человеческий ассемблер.
Итак, составляем рецепт.
1. Навести порядок в философии. Или идеологии. Это смежные термины (отличие в направленности на социальные группы), но в нашем случае мы различия делать не будем. Будем считать это взглядом на мир с точки зрения достижения заявленной цели.
1.1. Выкинуть весь бред про патриотизм. Просто потому что 90% это не патриотизм, а консерватизм. Но признаваться в этом стыдно, потому что это прямым текстом заявление о том, что нужно ходить в лаптях и говорить через твердый знак. А так можно прикрыться типа заботой о Родине (нанося ей ущерб идиотскими инициативами, типа купить каждой бухгалтерше по Эльбрусу, когда в госконторах денег на бумагу уже нет и вовсю печатают на черновиках), да еще оппонентов удобно предателем Родины заклеймить. Итак, выкинуть это нафиг. А чем заменить? И тут ответ прост - не заменять ни чем. Ни демократией, ни открытым миром не патриотизмом, не русофобством, ни консерватизмом. Ничем. Вот русский ассемблер не рассматривается в этом контексте.
1.2. Выкинуть тараканы про русскость из всех инструментов. Вот 1Скрипт православный, а другие нет. Просто потому что так нравится Лису. Это очередная ересь, которая наносит ущерб общему делу. Поэтому выкинуть. Также и все что связано с этой дрянью. Ну типа Буржуйская винда плохо, а Астра Линукс в основе которого буржуйский Дебиан - это все от лукавого.
2. Перестать страдать фигней и придерживаться одной цели. Ну как там по-пацански - пацан сказал, пацан сделал. Это значит, что если Вы делаете ассемблер, то Вы не переводите буржуйский Си, называя это русским ассемблером. Это ересь.
3. Составить информационную модель.
Вкратце так:
3.1. Получаем на вход данные (файл)
3.2. Читаем го
3.3. Парсим
3.4. Строим внутренне представление
3.5. В зависимости от целевой платформы строим выходной файл в опкодах
4. Внутренняя структура. Это достойно обсуждения. Но предлагаю следующие костыли:
4.1. Синтаксис во внешнем файле. Мне нравится эта идея. Это удобно. Это позволяет проектировать синтаксис независимо от семантики.
4.2. Общий принцип модели также определяется внешним файлом - это позволяет получать код под разные платформы:
4.2.1. Заголовок файла  - опкоды в текстовом виде (строки в которых записаны шестнадцатеричные числа)
4.2.2. Команды - также наборы опкодов с параметрами. По сути это встраиваемые подпрограммы, а не бинарное представление мнемоники
4.2.3. Хвост - аналогично заголовку, служебные данные если они необходимы.
Такая структура позволяет писать ассемблер под любой процессор/платформу/микроконтроллер.

Вот пока вкратце так. Если интересно, то идем дальше, уточняем от общего к частному. Строим диаграммки и схемы.

0

2

увидев реальный прогресс по ранее опубликованному стратегическому плану (прогресс выражается в факте запуска ЛуаРус на Астра-линуксе), Уткин впал в панику и занялся саботажем дальнейшего продвижения по плану.

Страшно подумать, что начнётся, когда я буду публиковать примеры кода на 1Скрипт для Альт-линукса

Отредактировано Лис (2018-10-16 19:51:37)

0

3

Да как одно мешает другому-то? Делайте Луа. Просто не называйте это ассемблером и всё.

0

4

Уткин, Ваш троллинг не поможет сбить других читателей со стратегического лисопути. Ведь Лис всегда готов разьяснить, что его первой целью является написание парсера машкода. ЛуаРус тут это просто стартовый инструмент. Не заработал ЛуаРус, значит будет взят 1Скрипт.

У меня была договорённость (соглашение) с rst256 о совместной разработке на РусЛуа. Это причина попытки на него перейти. К сожалению, перейти пока не удалось.

Отредактировано Лис (2018-10-16 20:01:24)

0

5

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

0

6

MihalNik выбирает  Алфор  в течение такого же количества времени, сколько я выбираю 1Скрипт.

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

Отредактировано Лис (2018-10-16 20:19:26)

0

7

utkin
1. Определить способ манетизации
1.1 Определить целевую аудиторию. Кто конечный потребитель?
2. Нужно разделение труда.
3. Каму ваша модель нужна?
Открываем любую книгу по компиляторам срисовываем.
Лучше определиться с поддержкой макросов и их видом.

utkin написал(а):

Общий принцип модели

Это ещё что такое?

utkin написал(а):

Заголовок файла  - опкоды в текстовом виде (строки в которых записаны шестнадцатеричные числа)

Заголовок это шаблон, а не опкоды.  Вы видимо имели в виду DOS заглушку в EXE-PE.
Для описания формата файла есть куча стандартов. Только я не вижу смысла в их поддержке.  Нам же не парсить, а генерировать надо.
А общих данных в разных файлах почти нету. PE и ELF очень сильно отличаются.

utkin написал(а):

4.2.3. Хвост - аналогично заголовку, служебные данные если они необходимы.

Хвост понятие растяжимое. 
1.  У кого-то это неицированные данные. Секция BSS
2.  У кого-то таблица импорта или экспорта.
3   У третьего в хвосте лежит отладочная информация.
4.  У четвёртого тело архива или ещё чего нибудь.

Основная проблема для создания компилятора это слабая документация на секции импорта и экспорта, таблицы символов.

1. Количество мнемоник, их тысячи.
2. Способ кодирования. По сути там нет закономерностей.  Фактически идёт одна главная таблица которая распадается на поколения развития процессора (286, 386, MMX, SSE, SSE2, SSE4, AVX,..)которые потом делятся на группы.  Для примера 286: строки, сдвиги, вызовы, флаги, стек,... Которая кодируется каждая по своему. Просто иначе там ещё несколько таблиц.

А если брать ARM где сдвиги комбинируются с большинством арефметических и других команд. Они входят в опкоды. То понятно что ничего общего в таблицах не будет.

Лично я не стал возиться с таблицами, так как их отлаживать трудно в виду отсутствия наглядности.  Есть несколько готовых движков с уже набранными таблицами. Если самому это набирать, то уйдёт уйма времени у меня свой эмулятор х86 с ассемблером и дизассемблером, так что я знаю.

0

8

1. Определить способ манетизации

Это отдельный разговор. Цель же написать инструмент.

Определить целевую аудиторию. Кто конечный потребитель?

Лис на Эльбрусе под Астра Линуксе. Шучу конечно.

2. Нужно разделение труда.

Конечно. Как и в любом проекте.

3. Каму ваша модель нужна?
Открываем любую книгу по компиляторам срисовываем.

Там срисовывать нечего. Ассемблер же.

Лучше определиться с поддержкой макросов и их видом.

п. 4.2.2 частично решает эту проблему.

Это ещё что такое?

Это я не удачно выразился. Каюсь.

Заголовок это шаблон, а не опкоды.  Вы видимо имели в виду DOS заглушку в EXE-PE.

Я имел ввиду нечто более общее. В отрыве от конкретной платформы.

PE и ELF очень сильно отличаются.

Поэтому эти данные должны храниться во внешнем файле. Также как и синтаксис.

1. Количество мнемоник, их тысячи.

Но оно конечно. А значит не является проблемой.

Если самому это набирать, то уйдёт уйма времени у меня свой эмулятор х86 с ассемблером и дизассемблером, так что я знаю.

Есть же справочники. У Интела на 64 бит всего 4800 страниц текста и табличек.

0

9

MihalNik выбирает  Алфор  в течение такого же количества времени, сколько я выбираю 1Скрипт.

Во-первых он помнил про эту разработку много лет.
Во-вторых, не выбирает, а изучает и посматривает за её ходом.

Лис написал(а):

Ведь Лис всегда готов разьяснить, что его первой целью является написание парсера машкода.

Это вообще reengineering.

0

10

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

0

11

Павиа сообщал о том, что он завершил написание русскоязычного дизассемблера для архитектуры Интел.
Но он не отвечает на мои письма.

(а без исходников и лицензий можно считать, что лично для меня этот результат интеллектуальной работы недоступен)

Отредактировано Лис (2023-04-12 04:41:00)

0

12

Ссылка в тему (даже две):

http://compiler.su/o-russkom-assemblere.php
https://ruscomp.bb24.ru/viewtopic.php?id=42

В советское время тоже были проекты «универсального ассемблера»: языки АЛМО, Сигма, Эпсилон и другие. Возможно, там что-то можно найти что-то интересное.

Что же мы видим?

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

В наше время совершенно несложно оформить публикацию "печатного" материала, и по законодательству .pdf-копии документов будут направлены во все основные государственные библиотеки.

.pdf-документы, конечно, делать надо уметь. Например при помощи TeX (точнее LaTeX).

Отредактировано Лис (2023-04-13 22:40:27)

0

13

Весь план по созданию ассемблера надо переписать заново (по сравнению с замечаниями Уткина).
Замечания Уткина являются именно замечаниями, а не собственно планом создания ассемблера.

Нужно более подробно описать, какие (и зачем) потребуются и будут созданы артефакты.
Ну и feature set определить.

http://webster.cs.ucr.edu/AsmTools/WhichAsm.html

The usability of an assembler is directly related to the quality of its documentation. Given the amount of work that goes into the creation of a decent assembler, it is surprising how poor the documentation for many of the products is; for the most part, the authors of assemblers seem to be so busy extending their language to document those extensions. Unfortunately, those really great features won't do anyone any good if they don't know about the features; hence, having good documentation is equally important to having a good feature set.

У ассемблера MASM его синтаксис написан в BNF (и доступен в документации):
это, я считаю, признак мастерства,
видно, что 2024-1981=43 года разработки потрачено не зря.
Хотя...
https://learn.microsoft.com/en-us/cpp/a … nf-grammar
«It's provided as a supplement to the reference and isn't guaranteed to be complete»
бракоделы и проприертарщики!

У ассемблера yasm синтаксис парсится рекурсивным спуском. И тут одно из двух, либо сначала делать yacc, либо так.
Если рассматривать со стороны раскрутки, то yacc - это более поздняя стадия, значит базовый ассемблер будет "так".
Формальная грамматика бы всё равно могла бы пригодиться, как и говорил Павиа.

Ещё надо как-то описывать инструкции. Для этого существуют RTL-языки (register-transfer level),
то есть VHDL и Verilog. Первый хвалят за то, что он типизированный, второй ругают за нетипизированность (ну это как Си против Бейсика).
Так-то хорошо бы написать свой кириллический язык для описания инструкций (по аналогии с языком LISA),
но это отдельная тема (потому что там тоже свой синтаксис, своя грамматика, парсер и т.д.)

Очень простой ассемблер, без команд для работы с плавающей точкой, позволил бы написать yacc-подобную утилиту,
затем они обе - написать обработчик формальных описаний инструкций,
что позволило бы создать второй ассемблер второго уровня (FASM вон тоже в двух поколениях, второе вроде ещё не доделано).

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

А на каком языке писать код ассемблера - это не очень важно, наверное. Вариантов кириллических языков высокого уровня немало, начиная с русифицированного Си и заканчивая Рефал-ом. При переписывании ассемблера на самом ассемблере (как делает FASM, или в машинных кодах) весь этот первый код на ЯВУ станет ненужным и уйдёт (в историю).

0

14

http://compiler.su/o-russkom-assemblere.php#96

Gudleifr написал(а):

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

После этого на ассемблер уходит две недели работы. Говорить же "в общих словах" можно годами.

Мы делаем это (говорим годами) уже не менее 6 лет.

Отредактировано Лис (2024-08-16 12:20:55)

0

15

Лис написал(а):

уже не менее 6 лет.

За это время Вы вполне могли вырастить Бабу-Ягу в своем коллективе. Найдите хоть какой-то способ доступа к нужному вам маш.коду. Пусть пациент начнет на нем решать задачи. Например, https://gudleifr.forum2x2.ru/t70-topic#860 , https://gudleifr.forum2x2.ru/t43-topic, Уэзерелла, наконец. Наладьте для него каналы получения информации - книги, журналы, форумы...

0

16

gudleifr написал(а):

Очевидно, кто-то "ответил на все три вопроса", а теперь ждет, что кто-то сделает все за него.

Почему сразу "кто-то"? Зачем эти ненужные переходы на личности? Нам всем нужен кто-нибудь!

Что б вы не умничали, сразу ссылку дам
https://ru.wikipedia.org/wiki/Трагедия_общих_ресурсов

Отредактировано Лис (2024-08-16 14:06:25)

0

17

Лис написал(а):

Почему сразу "кто-то"?

Это "стратегический" ответ.

Лис написал(а):

Нам всем нужен кто-нибудь!

И я написал, кто.

Отредактировано gudleifr (2024-08-16 14:13:10)

0

18

gudleifr написал(а):

И я написал, кто.

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

Отредактировано Лис (2024-08-16 14:25:48)

0

19

Лис написал(а):

Мы не можем точку входа показать

При чем тут точка входа? Для начала написания своего ассемблера ван нужен специалист по маш.коду.

0

20

gudleifr написал(а):

ван нужен

А вам не нужен? Ок, тогда мы вас вычёркиваем.

0

21

Лис написал(а):

А вам не нужен?

Мне проще самому. Но не раньше, чем я приду к необходимости написания 64-разрядного FOBOS. Пока большинство моих "рабочих станций" 32-разрядные и спешить некуда.

0

22

gudleifr написал(а):

Пока большинство моих "рабочих станций" 32-разрядные и спешить некуда.

Вот вам 32-х разрядный российский Risc-V в продаже:
МК32АМУР

0

23

Мне слово "нормальный" не нравится..

https://www.plantation-productions.com/ … index.html

The Assembler Developer's Kit

As far as computer languages go, most assembly languages have a fairly simple syntax. As a result, many programmers have actually written their own assembler. Though many open source assemblers exist and one could argue that there is no real reason for writing an assembler from scratch, there are many benefits to doing exactly that. Among these benefits include:

    Writing an assembler will give a programmer a good appreciation of the instruction encoding
    Writing an assembler will let the programmer insert the features they want into the assembler
    Writing an assembler allows the author to design a syntax for the assembly language that they prefer
    Writing an assembler is a good medium-sized project that many beginning to intermediate programmers can handle, allowing them to sharpen their programming skills on a practical project.

Unfortunately, there are some disadvantages to writing an assembler, as well:

    Creating a "hobby-quality" assembler isn't a difficult task, but creating a "commercial-quality" assembler with a professional feature set is a large project, often requiring skills that beginning to intermediate programmers don't possess.
    Creating a modern assembler requires a lot of advanced compiler knowledge, again that most beginning to intermediate programmers don't have.
    Creating a fast assembler, one that others will want to use, requires a commanding knowledge of data structures and algorithms. It's easy enough to whip out a little "toy" assembler that works fine for small projects; it's a bit more difficult to create a high-performance system that handles large projects just as well as small projects.
    While writing code to process individual machine instructions is fun and interesting, a professional-quality modern assembler requires a lot of other code to handle declarations, data types, macros, and other advanced features. These features are not particularly easy or obvious to implement.

0