Язык программирования GOODWELL

← →
Kladov (2003-02-27 04:39) [40]

Очень жаль. Человеку, призывающему перечитать Вирта, не хватило терпения, чтобы внимательно прочитать то, что я изложил. Почему я так решил? Меня зовут не Дима.

← →
Bartov (2003-02-27 10:49) [41]

2Kladov

AB> Что будет с KOL в будующем, не забросите ли вы его со своим новым компилятором?
VK> Нет, не заброшу. Но развивать его дальше на базе Delphi не вижу смысла.

А я, и надеюсь многие другие поддержут меня, - вижу смысл. Если ни какого развития не будет, то KOL - умрет! Ну и что, то что он хромой, Винда не хромая? Нет не хромая - КАРЯВАЯ, но ведь все на ней работают. А то чуствую я, что при выходе новой версии Делфи, мы просто не увидим к KOL"у МСК... Или я не прав?!...

С другой стороны, если вы не хотите развивать его на Делфи, то не надо ;-(
СРАЗУ ОГОВОРЮСЬ.
Прежде чем забросить развитие KOL на Делфи, вам НЕ мешало бы написать пару статей ( кратких СПРАВОЧНИКОВ ) о MCK и KOL, где было бы расмотрено по шаговое построение КОЛ объекта, а про - МСК не плохо было бы - описать весь принцып его работы (что где находится и как все это выполняется), а то на чистых исходниках тяжеловато разбираться.
А вот после этого можете на КОЛ уже меньше времени уделять и больше GOODWEEL"у. Поверьте, 90% нужно писать под Виндами...
Будующее покажет что к чему, но нелепую смерть КОЛа не хотелось бы увидеть (типа: год 2005, последния версия КОЛ 1.75)...

P.S. Это лично мое мнение и я буду его отсаивать.

← →
Ketmar © (2003-02-27 11:17) [42]

>Kladov (27.02.03 04:39)
"Владимир" для меня подсознательно сократилось в "Дима". извиняюсь, если обидел или оскорбил.

Satanas Nobiscum! 27-Feb-XXXVIII A.S.

← →
SerB (2003-02-27 12:48) [43]

Владимир, а есть ведь еще один вариант "организации труда"... KOL&MCK должен развиваться на существующей базе, что не должно помешать созданию GoodWell, как я понял включающего KOL&MCK как бузу для IDE... А т.к. в сутках 24 часа, семья и работа отнимают немного времени, да и спать иногда надо, можно переложить поддержку этого проекта на приКОЛистов...
Ну а... "кетмаров" (ничего личного не имею)бояться - в лес не ходить... Удачи...

← →
Kladov (2003-02-27 16:45) [44]

2Bartov
Ну, а что в KOL развивать-то? Будет использоваться, будут и новые функции появляться. Вот сейчас, в связи с задачей построения 2D-редактора, который доллжен рисовать Unicode-символы, среди прочего мне придется усилить KOL.TCanvas, чтобы можно было рисовать Unicod-овский текст. Это и есть развитие.

Писать справочники я никому не запрещаю. Хоть книги. Но ИМХО - пока не нужно.

← →
Bartov (2003-02-28 01:15) [45]

2Кладов

Ну, а что в KOL развивать-то?
Да БД и визуализацию к ней.

← →
Kladov (2003-02-28 04:54) [46]

> БД и визуализацию к ней

А это сами, пожалуйста. Мне оно не надо. То, что я сделал, было сделано только для того, чтобы показать, что ничего невозможного нет. Дальше все уже легче.

← →
Kladov (2003-03-01 21:26) [47]

Добавил спецификацию P-кода, если кому интересно.

← →
Boguslaw (2003-03-03 12:24) [48]

Where ? Give a link.

← →
Kladov (2003-03-03 19:15) [49]

bonanzas.rinet.ru / GOODWELL -> главная -> P-code

По-русски только.

← →
Bartov (2003-03-04 00:32) [50]

2Кладов
> Добавил спецификацию P-кода, если кому интересно.
Дейтсвительно интересно, исли это будет так как описано, то GOODWELL цены не будет.

← →
Yury Sidorov (2003-03-04 10:36) [51]

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

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

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

Т. е. суть всего сказанного такая: сложное легко заменить простым, а простое не всегда просто заменяется сложным.

← →
Kladov (2003-03-04 16:30) [52]

> Команда сравнения есть в наборе команд практически любого
> процессора

Но не у любого процессора есть регистр флажков в том же виде, как на 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). Где-то будет сдвинут указатель стека, а где-то придется выделять участок памяти из динамики. Тут уже просто никак иначе нельзя. Не стоит, однако, сразу поступать так же со всеми прочими вещами.

В общем, как дойдет до компилятора, тогда и смотреть будем давайте :)

← →
Kladov (2003-03-04 17:09) [53]

эээ метка там должна быть :1 (сдвоило)

← →
Yury Sidorov (2003-03-04 18:06) [54]

Ответ меня устроил :)
Главное чтобы алгоритм эффективного компилятора с Р-кода был простым.

← →
Ketmar © (2003-03-05 16:59) [55]

а зачем вообще p-код? см. juice.

Satanas Nobiscum! 05-Mar-XXXVIII A.S.

← →
Kladov (2003-03-05 21:05) [56]

> а зачем вообще p-код?

1. Чтобы плагин, который переводит в код целевой платформы, не заморачивался с синаксисом исходного языка.
2. Пока код представлен в виде P-кода, можно выполнять предварительные оптимизации путем последовательных инвариантных преобразований. В том числе все плагины, переводящие из P-кода в код целевой машины, могут использовать один и тот же модуль оптимизации, подавая на вход свои правила преобразования, удобные для этого плагина и для этой целевой платформы. Правила можно представлять в виде пар сигнатура-преобразование. Это намного упрощает процесс создания плагина для каждой новой платформы.

>Kladov (05.03.03 21:05)
отвечаем не читая полностью сообщение. плохо. повторяю: см. juice.

Satanas Nobiscum! 06-Mar-XXXVIII A.S.

← →
Kladov (2003-03-06 19:46) [58]

Ну а при чем тут juice. Умершая (или неживая, что то же самое) альтернаива явы, платформ-независимый. Более эффективный, чем ява. (Но яву браузеры поддерживают, а juice нет). Не знаю, есть в нем свой п-код, или нет. А дальше? В goodwell эффективность самого п-кода не имеет значения. Не будет интерпретатора. Главное - примитивность представления кода. Чем примитивней, тем лучше.

И пожалуйста, больше не надо - см. туда, читаем сюда. Некуда смотреть. Было бы куда, не писали бы мы на Delphi сейчас.
И не пытался бы никто изобретать новые языки.

>Kladov (06.03.03 19:46)
>Главное - примитивность представления кода. Чем примитивней, тем лучше.
перл.

>И пожалуйста, больше не надо - см. туда, читаем сюда. Некуда смотреть. Было бы куда, не писали бы мы на Delphi сейчас.
И не пытался бы никто изобретать новые языки.
ещё один перл.

вся ветка -- коллекция перлов. Владимир, неужели ваш фанатизм НАСТОЛЬКО зашорил ваше мышление?

Satanas Nobiscum! 11-Mar-XXXVIII A.S.

← →
АлексейС (2003-03-13 11:53) [60]

Насчет PI-cod, то что бросается в глаза и возможно является непринципиальным, но люди работающие на разных платформах по разному понимают тип данных WORD и DWORD, например для процессоров с гарвардской архитектурой машинное слово, т.е. WORD может быть равно 14 битам, 12битам. Возможно для кросплатформенности (точнее для взаимпонимания программистов разных платформ) стоит в PI коде указывать дополнительную секцию настройки на тип данных или использовать тип данных одназначно говорящий о ширине (в битах данного). Может так B16, B32, B64, B12? По поводу системы счисления в константах, может приблизить ее к более традиционному H,B,O в замен 16,2,8 (учитывая заодно и экононмию в символе на шестнадцатиричной системе).

← →
puky@ukr.net (2003-03-26 21:00) [61]

Как там прогресс???

← →
Fantasist. (2003-03-26 22:24) [62]

Начал читать - очень интересно! Особенно впечатлила идея использования абзацов вместо огранечителей блоков. Так сразу не скажу, что идея бесспорная, но мне кажется очень здравой. Правда, хотелось бы все-таки чтобы определения функций имели какую-то закрывающую лексему. Хотя бы как в бэйсике:
function ... endf;

Во-первых, в теле функции часто оставляю пустые строки для разделения подэтапов функции (типа инициализация, цикл обработки, завершение) - читается удобнее. Во-вторых, удобно при отладке - можно бряк поставить на выход из фунции. В-третьих, все-таки нагляднее.
Да. И сами определяния функций по-моему лучше в стиле С++. Вот что меня в паскале очень достовало, так то что надо писать то function то procedure, писать жутко неудобно, многословно, читабильность ничуть не лучше.
Равноправность скобок это тоже интересно, однако мне кажется внесет это больше путаницы, нежели облегчение восприятия.

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

← →
alek111 (2003-10-24 18:08) [63]

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

Язык программирования GOODWELL Найти похожие ветки