Я думаю моя идея не новая

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

1. никаких классов и прочего задротства в этом духе.
2. чтобы точку входа можно было указать любую, как в это делается в FASM, дирректива entry и имя метки или процедурки.
3. чтобы можно было указывать секции программы как это делается в FASM
4. в С/С++ все глобавльные переменные которые мы указываем сразу отправляются в секцию с данными при этом по барабану где они были объявлены. хочу чтобы можно было писать так

Код (Text):

1. void proc1()
2. {
3.   return ;
4. }
5.  
6. DWORD x;
7. CHAR y;
8.  
9. void proc2()
10. {
11.   return ;
12. }

т.е. чтобы переменные x и y были не где-то там в секции данных, а прямо посреди кода.
5. чтобы не генерировалась всякая ерунда, только мой код переведённый на асм и всё!
6. чтобы вручную указывать таблицу импорта и экспорта. И никакого дрочилова с LIB и DEF файлами
7. Чтобы можно тупо без каких-либо ограничений мешать ассемблер и С. например

Код (Text):

1. void proc1()
2. {
3.   return ;
4. }
5. asm
6. {
7. asmproc:
8.     shr eax, 1
9.     ;asm code
10.     ret
11. }
12.  
13. void proc2()
14. {
15.    asm
16.    {
17.     mov eax, N
18.     call asmproc
19.     }
20.    return ;
21. }

т.е. идёт процедурка на С потом сразу код на асме и т.д.
8. никаких приведений типов, всё как на ассемблере. примерно так

Код (Text):

1. PCHAR string;
2. UINT value;
3. value =  string; // value = (UINT)string, вот зачем мне этот (UINT)?

и ещё куча мелких деталей, описывать просто лень.
Я думал вы поняли что я хочу. Ваши коментарии по этому поводу.

 

И что секция кода будет RWE ?

И потом искать их не известно где?

забавный плагин для фасма получился бы

 

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

если интересно будет, то у него есть порты под разные процы. под арм например

 

И мне пожалуйста

 

rpy3uH
о А на чём писать будете? Тулзы какие(flex,re2c,bison,lemon,ANTLR,CoCo)? А может вручную? Писать грамматики, имхо, намного легче. Я бы даже сказал, что грамматики для тривиальных языков это очень просто.

о Чем отлаживать будете? Без символов отлаживать ядерные вещи, сделанные вашим языком вряд ли кто согласиться... хотя такие найдутся, не исключено.

о Зачем избегать оптимизации? Код ЯВУ без оптимизаций будет довольно медленным, хотя бы из-за неумелого использования регистров.

Приведение типов позволяет отловить неявные ошибки.

Или дальше идеи пока не дошло?

 

Это делает код более медленным на x86 и 64. (если в эти данные можно писать). Объяснять почему, я думаю, не надо.

UPD
qqwe
Положите в общий доступ, очень хочется посмотреть на реализацию.

 

я же сказал что атрибуты секци будут задаваться вручную

ну потом можно будет добавить опцию в компилер, которая добавляла инфу для отладки в исполняемый файл

да ПО БАРАБАНУ! можно и свой парсер написать. глючный, да и по херу, главное чтобы работало

да не в этом суть...

идея только, не более

 

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

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

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

 

qqwe
Ок, ждём-с.

Надо будет взглянуть, какой код коко генерирует, а только я только немного мана прочитал. Меня он что-то не впечатлил.

 

LL(1)
Лучшее по теме - http://www.parsifalsoft.com/ (Now - FREE).

 

gazlan
посмотрел примеры к http://www.parsifalsoft.coм. 4 оп и жабопарсер
в чем выражается лучшесть если не секрет? он дает лучше код?

 

Z3N
чем именно он вас не впечатлил? минимализмом? так это же хорошо

 

http://basmp.narod.ru/9/8l-win32-pe-src.zip

это только линкер. сорцы сишняка (8c), асма (8a) и прочих интересующих утилит находятся в сорс дереве инферно.
там же находятся все скрипты нужные для сборки
правите mkconfig только 2 места про ось и проц и дальше mk all.
можно и отдельную утиль, но я с 0 отдельныене пробовал, потому и не скажу

да, соpцы линкера или подменяете или просто вносите правки (там 2 файла. точнее счас глянуть затруднительно)

 

qqwe

http://gazlan.freetzi.com/links/parsers.html

EBNF, LALR(1), визуальная отладка, исключительная гибкость (собственный код в обеих частях грамматического правила, подмена токенов on-the-fly), общая продуманность и простота работы. + Отличный комплект примеров + встроенный контекстный хелп.

 

форкните Clang

 

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

мнение о коко приведенное в ней, не знаю ваше или нет, видится или предвзятым или поверхностным

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

документацию имеет краткую, подробную, с примерами

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

имеет команду метки для игнорирования ошибок

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

[ IF( <команды целевого языка> ) <блок then> ] -- если блок в if = true, тоассматривается и then, иначе переход к следующей лексемме

( IF( <команды> ) <then> | <else> ) -- тоже самое, но с блоком иначе

{ IF( <ком> ) ... } -- вайл по условию

обвязочные конcтрукции обычные конструкции коко и дополнительного разбирательства не требуют

ну а для самых сложных случаев есть конструкция PRAGMA. в ней можно вручную разобратьсамые замороченные куски

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

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

ну и навязываемый стиль не заформализирован. только самые необходимые объявления и конструкции.

 

qqwe

Мнение мое собственное. IMHO, игрушка. LL(1) слишком ограничена для многих вещей, время уходит не на работу, а на разрешение shift/reduce конфликтов в грамматике. Синтаксис (a la Pascal) для меня отвратителен. Визуализации, разумеется, нет. Coco было первым, за что я хватался в нескольких проектах и всякий раз, поигравшись, отказывался в пользу чего-то другого. Кроме того (та же проблема и с Anagram) я привык к двухфазному разбору (Lexer/Parser) и как только возникает задача разбора нетекстовых потоков, однофазные парсеры (с прикручиванием Lexer'а через ж.), делаются просто неудобными. Наконец, Pascal-подобные языки специально разрабатываются под LL(1) грамматику, проблемы начнутся, когда потребуется разобрать что-то реальное

 

rpy3uH

Вот это зря, по-моему. Главное преимущество C над asm'ом -- это типизация. Асм с его ограниченным видением типов, сводящемуся к C'шному sizeof -- это на самом деле убожество. Пока кроме int'ов и их адресов ничего нет, то вроде как даже и ничего, а вот в дополнение к адресам появляются указатели, адреса указателей, и указатели хранящие адреса других указателей -- это уже мозг свернёшь.

Лучше наоборот, взять asm и внести в него C'шную типизацию. =)


А насчёт парсера... Человек задумал никому не нужный язык, и вы предлагаете ему писать парсер, использовать какие-то там "грамматики"? Это же бессмысленная трата времени. Куда проще и быстрее всё можно организовать регекспами. На скорость работы того что получится -- накласть. Никто не будет перекомпилировать раз за разом сотни тысяч строк кода на этом языке. А если всё же будет, то вот тогда и можно будет подумать о грамматиках, ручном разборе или генераторах парсеров и токенайзеров.
Хотя, я думаю, что в данной ситуации, можно поступить ещё проще: https://sparse.wiki.kernel.org/index.php/Main_Page
Это библиотека-парсер. Он правда под парсинг C заточен, но есть у меня подозрение, что его даже патчить не придётся, чтобы отловить ассемблерную вставку "не на месте" и обработать её самостоятельно. Плюс к этой библиотеке приложены примеры, типа законченного компилятора C, всяческих там статистических анализаторов кода и пр.
А можно, кстати, регекспами:
1. разбить код на отдельные функции, каждую сложить в отдельный временный файлик
2. нестандартные вставки типа asm на глобальном уровне, сложить в asm файлики
3. перед каждым C выражением/подвыражением поставить приведение типа к int (то есть, например: a=1+2 преобразовать в a=(int)1+(int)2); хотя может и без этого можно обойтись -- grep'ом отфильтровать варнинги о некрасивых приведениях типов
4. скомпилять каждый файлик компилятором C, а чтобы "не генерировалась ерунда", я предпочитаю использовать флаг -Os -- от большинства "ненужностей" избавляет.
5. собрать линкером, чётко указав ему, что, в какую секцию и в каком порядке складывать.

Короче, изуродовать C избавив его от каких-то его фичей гораздо проще, чем добавить в него фичи. И для этого вовсе не надо знать слово "грамматика".

 

Всё перечисленное никак не тянет на отдельный язык программирования. Это ведь тот же C получится, только с преферансом и куртизанками. Часть из того, что ты описал, уже есть в C. Правда, в некоторых местах придётся написать макросы, но это не суть. Короче, не трать время.

 

r90
почему никому не нужный? как минимум ему то он интесен?
и даже если это только ради развлечения, то лучше уж так развлекаться, чем массово качать права и мериться насчет кто больше тру, а кто совсем не больше тру.

как минимум потренируется в написании/модификации/отладке парсеров-виртуалок-кодогенераторов. понравится - ненастраиваемых каменных прог писать станет не интересно. да и в принуипе и выйти может чтото хорошее. почему нет? и С и С++ и уних родились и долго развивались как проекты фофан.
короче, польза может быть

(ну и парсить регекспами сложные конструкции немного совсем не то)

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

думал думал где вы увидели в коко паскалевый синтаксис? мне он больше функциональщину напоминает. даже спросить решил

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

что вы понимаете под визуализацией? граф связей в грамматике? сорец коко есть. сам коко парсер написан на коко. сделайте ему вывод не на код а в граф.

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