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

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

qqwe

Думаю, что он имел в виду отладчик, судя по скринам отладчик и в правду неплохой.

А инферно это ваша рук дело?

 

Z3N

А не надо париться, насчёт "гуано". Весь вопрос в том, сколько придётся на это затратить времени. Регекспами, на самом деле, достаточно просто парсить, главное не зацикливаться только на них. Иногда лучше вручную цикл перебора char'ов строки написать.
qqwe

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

К чему эта фраза, я чесслово не понял.

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

 

rpy3uH

Здраствуйте. Я, Кирилл. Хотел бы чтобы вы сделали игру, 3Д-экшон суть такова...

 

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

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

r90

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

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

 

qqwe
Grammar trace
File trace

 

Z3N
ага. понял. трассировка исходного текста с указанием какая лексер-парсер сущность взвелась. возможно, с указанием места в исходной грамматике.

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

 

qqwe
Дело в том, что я от коко не фанатею да и мне есть что писАть сейчас.
Возможно, добавлю эту идею в свой длинный лист TODO
Мне и без отладчика хорошо. Направил дебаг вывод лемона в консоль - и нормально.

 

Z3N
в 99.9% случаев критики следует подобный же ответ на предложение поучаствовать в исправлении критикованных недостатков. это был контрольный вопрос. хотя, в принципе, сделать подобное, таки да, несложно. 2-3 вечера.

 

qqwe

Давайте начистоту, что вы увидели в этом языке, что наводит вас на мысль, что язык не просто двинется дальше разговоров, но более того будет жить и развиваться долгие годы. Как я не стараюсь посмотреть, отринув предвзятость, всё что я вижу в этом языке -- изуродованный C. Может, конечно, я не о тех задачах думаю, и в каких-то ситуациях очень важно добиваться нужного расположения функций и переменных в памяти... Но даже если и так, то в лучшем случае, получится специализированный язык. "Многие вещи", о которых вы говорите, как правило были реализациями того, о чём все давно думали. C -- кроссплатформенный ассемблер. C++ -- ООП в C. UNIX -- ОС с открытым кодом, да ещё и кроссплатформенная. Здесь же, мы видим идеи понятные только ТСу. А я что-то не припоминаю исторических примеров, как язык годами оставался непризнанным и гонимым, но при этом жил и развивался. Точнее, если быть честным, я знаю несколько таких примеров, но то были языки написанные "для себя", которые даже не претендовали на выход в свет -- как раз здешняя ситуация, язык нужный исключительно автору.

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

 

qqwe

Даже все посты перечитал, чтобы понять, где я "критиковал". Я как-бэ вообще не критиковал. Просто написал ответ на ваше заявление о том, отладчика там нет... а я его видел... Меня анаграм впечатлил не больше коко.

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

Да, кстати...

Мне синтаксис не очень нравиться. Да и просто такое было первое впечатление

 

r90

гы. С, С++. та же юних.

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

меня ничего не наводит. я даже не думал над этим. хотя..

M: // как узнать адрес метки?

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

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

Z3N

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

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

 

Насчет грамматик могу сказать, что ИМХО куда проще спроектировать компилятор на алгоритмах рекурсивного спуска. Компилятор D именно так и работает, кстати, Вальтер Брайт писал все руками, и я с ним в этом деле согласен - самолично написанный код гораздо понятнее чем сгенерированный. А лексический анализатор вообще можно написать за вечер руками, и это будет гораздо правильнее и проще чем пользоваться генераторами.

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

Код (Text):

1. [section="code"]
2. DWORD x;

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

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

Код (Text):

1. void Func() {}
2. int s = sizeof(Func);
3. void *(pf)() = &Func;

- тип label для переменных-меток и оператор goto на динамические метки (полный аналог jmp). Метки кстати начинаются с какого-то спецсимвола, это элемент дизайна языка и сделано осознанно.

Код (Text):

1. label L[2] = {$$Lab1, $$Lab2 };
2. goto L[i];
3. $$Lab1://...
4. $$Lab2://...

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

Код (Text):

1. if(x>0) XGreaterThanZero
2. {
3.    while(i<10) ExternalLoop
4.    {
5.      for(j=0; j<n; j++) InternalLoop
6.      {
7.         if(condition)
8.            break XGreaterThanZero;
9.      }
10.    }
11. }

 

В чём цимес сплава fasm и Си? Неужели ручное формирование таблицы импорта намного круче .def?
Что-то я пока не впечатлился киллер фичами нового языка.

 

xcode

сгенерированный код на питоне для одного из из интерапетаторов

Код (Text):

1.    def SimExpr( self ):
2.       type = self.Term()
3.       while self.la.kind == 16 or self.la.kind == 17:
4.          op = self.AddOp()
5.          type1 = self.Term()
6.          #if type != self.lng.INT or type1 != self.lng.INT:
7.          #   self.SemErr(120)
8.          self.lng.Emit(op)
9.       return type
10.  
11.    def RelOp( self ):
12.       op = -1;
13.       if self.la.kind == 11:
14.          self.Get( )
15.          op = self.lng.EQU
16.       elif self.la.kind == 7:
17.          self.Get( )
18.          op = self.lng.LSS
19.       elif self.la.kind == 8:
20.          self.Get( )
21.          op = self.lng.GTR
22.       else:
23.          self.SynErr(56)
24.       return op
25.  
26.    def Term( self ):
27.       type = self.Factor()
28.       while self.la.kind == 18 or self.la.kind == 19:
29.          op = self.MulOp()
30.          type1 = self.Factor()
31.          #if type != self.lng.INT or type1 != self.lng.INT:
32.          #   self.SemErr(120)
33.          self.lng.Emit(op)
34.       return type
35.  
36.    def AddOp( self ):
37.       op = -1;
38.       if self.la.kind == 17:
39.          self.Get( )
40.          op = self.lng.ADD #PLUS
41.       elif self.la.kind == 16:
42.          self.Get( )
43.          op = self.lng.SUB #MINUS
44.       else:
45.          self.SynErr(57)
46.       return op

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

в С и С++ есть для таких целей оператор #pragma. просто доопределите свой если такого еще нет

Booster

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

 

qqwe

Сомнительное преимущество, да и наверняка дело вовсе не в ручном формировании.

 

я понял что мне нужно. мне не нужен урезанный С, мне нужен навороченный FASM.

идея примерно следующая: написать препроцессор для FASM который сконвертирует некоторые куски программы в на ассемблер. Сам исходник будет писаться на ассемблере, куски написанные на С будут помечаться специальными диррективами. Препроцессор будет искать такие куски и конвертить их на асм. Будет конвертить целые процедуры/функции или только куски кода.
например,

Код (Text):

1. format PE ....
2.  
3. entry start
4.  
5. section '.text' ....
6. [C_CODE_START]
7. stdcall int myproc(param1, param2)
8. {
9.    if (param1==param2) return 0;
10.    return 1;
11. }
12. [C_CODE_END]
13.  
14. start:
15.      push 1
16.      push 2
17.      call myproc

либо куски кода, например

Код (Text):

1. format PE ....
2.  
3. entry start
4.  
5. section '.data' ....
6.    varx dd ?
7.    vary dd ?
8.  
9. section '.text' ....
10. start:
11.      ;
12.      ;asm code
13.      ;
14. [C_CODE_BLOCK_START параметры] ; в параметрах можно указать какие регистры можно юзать какие нет,
15.                                                   ; какие  инструкции можно юзать какие нет и т.д.
16. whie (varx==vary)
17. {
18.    vary++;
19. }
20.  
21. [C_CODE_BLOCK_END]
22.      ;
23.      ;asm code
24.      ;

как вам такая идея?

 

rpy3uH
У фасма уже есть препроцессор. Вы же описываете что-то похожее скорее на транслятор. Мне одно не нравиться в этом случае усложняется отладка....

Эх, фасму бы нормальный макроязык....

А вообще форк фасма довольно правильная мысль.

 

врочем, да. это уже транслятор

макроязык в нём хороший, не надо гнать

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

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

 

rpy3uH

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

Код (Text):

1. macro str string{
2.  
3. rndname db string
4. return rndname}
5.  
6. В коде
7. mov eax,str "8|"

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

А вообще мне всегда хотелось чтобы была возможность писАть в ряд что-то вроде

Код (Text):

1. mov eax,eax; xor eax,eax; ret
2. //here do something usefull :)

 

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

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