| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Язык программирования GOODWELL
Kladov © (2003-02-22 14:42:00)Потихоньку готовлю к публикации предварительную спецификацию разрабатываемого мною языка. Собственно, спецификация уже готова. Просто перевожу на английский. Все, кто желают ознакомиться, я сейчас выложу русскую версию спецификации здесь: http://bonanzas.rinet.ru/goodwell/GOODWELL-spec-RU.htm
Предвосхищая вопрос При чем тут KOL - редактор будет делаться на KOL/MCK, компилятор поначалу тоже. Ну и автор тот же. И сторонников я надеюсь набирать из тех же людей, что занимаются улучшением KOL. И сайт будет тот же - нет возможности еще и сайт отдельный создавать :)
alek111 (2003-10-24 18:08:00) [1]Использование абзацев вместо ограничителей блоков реализовано в Python, кстати, очень неплохой язык его-бы переработать немного для полного счастья.
Fantasist. (2003-03-26 22:24:00) [2]Начал читать - очень интересно! Особенно впечатлила идея использования абзацов вместо огранечителей блоков. Так сразу не скажу, что идея бесспорная, но мне кажется очень здравой. Правда, хотелось бы все-таки чтобы определения функций имели какую-то закрывающую лексему. Хотя бы как в бэйсике:
function ...
endf;
Во-первых, в теле функции часто оставляю пустые строки для разделения подэтапов функции (типа инициализация, цикл обработки, завершение) - читается удобнее. Во-вторых, удобно при отладке - можно бряк поставить на выход из фунции. В-третьих, все-таки нагляднее.
Да. И сами определяния функций по-моему лучше в стиле С++. Вот что меня в паскале очень достовало, так то что надо писать то function то procedure, писать жутко неудобно, многословно, читабильность ничуть не лучше.
Равноправность скобок это тоже интересно, однако мне кажется внесет это больше путаницы, нежели облегчение восприятия.
Ничего не увидел по поводу модульности (сборка нескольких модулей, использования скомпилированных модулей и пр.).
puky@ukr.net (2003-03-26 21:00:00) [3]Как там прогресс???
АлексейС (2003-03-13 11:53:00) [4]Насчет PI-cod, то что бросается в глаза и возможно является непринципиальным, но люди работающие на разных платформах по разному понимают тип данных WORD и DWORD, например для процессоров с гарвардской архитектурой машинное слово, т.е. WORD может быть равно 14 битам, 12битам. Возможно для кросплатформенности (точнее для взаимпонимания программистов разных платформ) стоит в PI коде указывать дополнительную секцию настройки на тип данных или использовать тип данных одназначно говорящий о ширине (в битах данного). Может так B16, B32, B64, B12? По поводу системы счисления в константах, может приблизить ее к более традиционному H,B,O в замен 16,2,8 (учитывая заодно и экононмию в символе на шестнадцатиричной системе).
Ketmar (2003-03-11 11:31:00) [5]>Kladov (06.03.03 19:46)
>Главное - примитивность представления кода. Чем примитивней, тем лучше.
перл.
>И пожалуйста, больше не надо - см. туда, читаем сюда. Некуда смотреть. Было бы куда, не писали бы мы на Delphi сейчас.
И не пытался бы никто изобретать новые языки.
ещё один перл.
вся ветка -- коллекция перлов. Владимир, неужели ваш фанатизм НАСТОЛЬКО зашорил ваше мышление?
Satanas Nobiscum! 11-Mar-XXXVIII A.S.
Kladov (2003-03-06 19:46:00) [6]Ну а при чем тут juice. Умершая (или неживая, что то же самое) альтернаива явы, платформ-независимый. Более эффективный, чем ява. (Но яву браузеры поддерживают, а juice нет). Не знаю, есть в нем свой п-код, или нет. А дальше? В goodwell эффективность самого п-кода не имеет значения. Не будет интерпретатора. Главное - примитивность представления кода. Чем примитивней, тем лучше.
И пожалуйста, больше не надо - см. туда, читаем сюда. Некуда смотреть. Было бы куда, не писали бы мы на Delphi сейчас.
И не пытался бы никто изобретать новые языки.
Ketmar (2003-03-06 15:22:00) [7]>Kladov (05.03.03 21:05)
отвечаем не читая полностью сообщение. плохо. повторяю: см. juice.
Satanas Nobiscum! 06-Mar-XXXVIII A.S.
Kladov (2003-03-05 21:05:00) [8]
> а зачем вообще p-код?
1. Чтобы плагин, который переводит в код целевой платформы, не заморачивался с синаксисом исходного языка.
2. Пока код представлен в виде P-кода, можно выполнять предварительные оптимизации путем последовательных инвариантных преобразований. В том числе все плагины, переводящие из P-кода в код целевой машины, могут использовать один и тот же модуль оптимизации, подавая на вход свои правила преобразования, удобные для этого плагина и для этой целевой платформы. Правила можно представлять в виде пар сигнатура-преобразование. Это намного упрощает процесс создания плагина для каждой новой платформы.
Ketmar (2003-03-05 16:59:00) [9]а зачем вообще p-код? см. juice.
Satanas Nobiscum! 05-Mar-XXXVIII A.S.
Yury Sidorov (2003-03-04 18:06:00) [10]Ответ меня устроил :)
Главное чтобы алгоритм эффективного компилятора с Р-кода был простым.
Kladov (2003-03-04 17:09:00) [11]эээ метка там должна быть :1 (сдвоило)
Kladov (2003-03-04 16:30:00) [12]
> Команда сравнения есть в наборе команд практически любого
> процессора
Но не у любого процессора есть регистр флажков в том же виде, как на PC. Когда идет перевод с ЯВУ в п-код, это неважно, потому что в ЯВУ мы сразу пришем IF ... THEN ... . Здесь и вычисление условия, и переход. А когда с P-кода в тот же ассемблер, то уже намного хуже получится. Что должно быть? IF-последнее-сравнение-дало-истину-THEN ... ? Что считать последним сравнением? Где искать команду, если она отстоит на сколько-то уже вверх. А если их несколько? И при этом они по-разному воздействуют на флажки? То, что я предполагаю, означает всего лишь косвенное указание на ту операцию, которая была выполнена. А там уже дело компилятора, будет он ассоциировать регистр с настоящим регистром, памятью или флажком процессора.
> нужно ввести команды Р-кода для работы с блоками памяти
Совсем не обязательно. Совсем не трудно перевести цикл
:11 D[{P5}]=0
{P5}+4
{D4}-1
{D4}>0?:1
В что-то вроде
MOV EDI, {P5}
MOV ECX, {D4}
XOR EAX, EAX
REP STOSD
Вообще, чем проще язык, тем лучше. На простом языке можно организовать анализ сигнатур (что-то похожее на анализ сигнатур полиморфных вирусов) - с целью оптимизации, и вообще компилятор в код любого процессора можно построить как анализатор таких сигнатур. Такую технологию я использовал еще аж в 1988 г. при написании компилятора с С, тогда еще не ++.
Например, для вышележащего P-кода сигнатура могла быть именно такой, как сам код, только отличались бы номера регистров ( команды {P5}+4 и {D4}-1 можно было бы записать в одну строку, как бы помечая, что их можно переставить. Или нужно две сигнатуры - на каждый порядок этих команд ). Найдена сигнатура, а дальше компилятор знает, какой код генерировать для такой сигнатуры. Для каждого типа процессора свой набор сигнатур. Можно и выходные шаблоны поставить в прямое соответствие. Транслятору только остается отслеживать занятось реальных регистров.
А вот почему я решил, что нужна независимая команда для выделения локального массива: потому что тут уже проблема не команды переставить местами. А вообще ухитриться без знания того, что это за память, как она получена, где располагается, все-таки описать это выделение (оно обычно статическое в том смысле, что в начале блока делается один раз, и при выходе из блока память освобождается, но мало ли - для оптимальности и на платформе PC бывает выгодно заменять getmem простым сдвигом ESP). Где-то будет сдвинут указатель стека, а где-то придется выделять участок памяти из динамики. Тут уже просто никак иначе нельзя. Не стоит, однако, сразу поступать так же со всеми прочими вещами.
В общем, как дойдет до компилятора, тогда и смотреть будем давайте :)
Yury Sidorov (2003-03-04 10:36:00) [13]Покритикую P-код.
Суть критики в следующем: не стоит делать набор команд P-кода проще (примитивнее) чем набор команд хотя бы одного процессора, на который будет компилироваться P-код программа.
По моему не логично не ввести в язык Р-кода команду сравнения (cmp, например), а использовать вычитание и сравнение результата с нулем. Команда сравнения есть в наборе команд практически любого процессора, и не используя такой команды в Р-коде усложняется алгоритм компилятора для конечного процессора (компилятору нужно угадывать, что в данном случае вычитание нужно заменить сравнением). Также при предварительном вычитании используется дополнительный регистр для хранения результата, чего при использовании нормального сравнения не происходит.
Дополнительно нужно ввести команды Р-кода для работы с блоками памяти - копирование, сравнение, поиск, заполнение значением, т. к. подобные комадны есть, по крайней мере, в процессорах Интел. Конечно, можно для пересылки блока памяти организовать цикл, но компилятору (если в процессоре есть команды для работы с блоками памяти) будет очень трудно заменить этот цикл на команду пересылки блока памяти. А если в конечном процессоре нет команд для работы с блоками памяти, то такие команды легко заменяются на цикл из поддерживаемых процессором команд.
Т. е. суть всего сказанного такая: сложное легко заменить простым, а простое не всегда просто заменяется сложным.
Bartov (2003-03-04 00:32:00) [14]2Кладов
> Добавил спецификацию P-кода, если кому интересно.
Дейтсвительно интересно, исли это будет так как описано, то GOODWELL цены не будет.
Kladov (2003-03-03 19:15:00) [15]bonanzas.rinet.ru / GOODWELL -> главная -> P-code
По-русски только.
Boguslaw (2003-03-03 12:24:00) [16]Where ? Give a link.
Kladov (2003-03-01 21:26:00) [17]Добавил спецификацию P-кода, если кому интересно.
Kladov (2003-02-28 04:54:00) [18]
> БД и визуализацию к ней
А это сами, пожалуйста. Мне оно не надо. То, что я сделал, было сделано только для того, чтобы показать, что ничего невозможного нет. Дальше все уже легче.
Bartov (2003-02-28 01:15:00) [19]2Кладов
Ну, а что в KOL развивать-то?
Да БД и визуализацию к ней.
Kladov (2003-02-27 16:45:00) [20]2Bartov
Ну, а что в KOL развивать-то? Будет использоваться, будут и новые функции появляться. Вот сейчас, в связи с задачей построения 2D-редактора, который доллжен рисовать Unicode-символы, среди прочего мне придется усилить KOL.TCanvas, чтобы можно было рисовать Unicod-овский текст. Это и есть развитие.
Писать справочники я никому не запрещаю. Хоть книги. Но ИМХО - пока не нужно.
| |
Страницы: 