Форум TeamX
   Home   Members  
Pages: [1] 2 3 |   Go Down
 
Author Topic: Новая версия компилятора  (Read 4938 times)
Jordan
Пользователь
Posts: 416

476228895
Новая версия компилятора
« on: 01 June 2009, 06:41:18 »

KLIMaka

Помнишь ты писал

Quote
Вот такие вот пироги... Я как раз занимаюсь облагараживанием компилятора, пытаясь добавить немного нового и нужного - массивы, взятие адреса процедур, структуры (Непонимающий). В дальнейшем - сгибание языка в сторону ООП - наследование, инкапсуляция и проч... Ну пока это все на уровне концепции, и я прощупываю возможности ssl. Основной, на данный момент тормоз - отсутствие нормального импорта процедур, я уже поборол...

Как продвигается улучшение компилятора?
« Last Edit: 02 June 2009, 09:37:23 by Wasteland Ghost »

Воспрянет Россия, из праха отцов
Расправятся крылья, миллионов сердец
Поднимут все головы и грудью вздохнут
И громка скажут, что пришли
Мы пришли, со столетней войны
Jordan
Пользователь
Posts: 416

476228895
Новая версия компилятора
« Reply #1 on: 01 June 2009, 17:37:29 »

Quote
Насчет компилятора. Потихоньку продвигаюсь. Сначала хотел просто перевести sslc с С на стандартный С++, даже лексический анализатор полностью переписал, потом глянул на него и понял что это совсем не "C++ way" и решил полностью переписать на основе Boost.Spirit

http://ru.wikipedia.org/wiki/Boost это оно?

А как это будет работать?

Я как понял sslc компилирует файлы в свой байт код который понимает движок. Как джава. В движке список функций, например движок считывает опкод, считывает аргументы и передает внутренней функции в движке, а эта функция выполняется.

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

Воспрянет Россия, из праха отцов
Расправятся крылья, миллионов сердец
Поднимут все головы и грудью вздохнут
И громка скажут, что пришли
Мы пришли, со столетней войны
KLIMaka
Пользователь
Posts: 72


Новая версия компилятора
« Reply #2 on: 01 June 2009, 18:04:06 »

Да, оно, а конкретно http://ru.wikipedia.org/wiki/Boost#.D0.A0.D0.B0.D0.B7.D0.B1.D0.BE.D1.80_.D1.82.D0.B5.D0.BA.D1.81.D1.82.D0.B0

Работать будет это точно так же как и старый-добрый sslc, обратная совместимость - одна из главных целей. Просто хочется добавить несколько ноновведений по типу указателей на функции, ссылки, массивы, строгая статическая типизация, инлайн ф-ии, простая расширяемость (чтобы добавить новые опкоды не прийдется перекомпилировать исходники), некоторые оптимизации (sslc иногда компилирует абсолютно бестолковый код) и т.д. Вообще реализация SSL в фолле позволяет делать достоточно много интересных вещей.
Jordan
Пользователь
Posts: 416

476228895
Новая версия компилятора
« Reply #3 on: 01 June 2009, 19:23:22 »

Можешь показать примеры нововведений. Как это будет выглядеть.

Воспрянет Россия, из праха отцов
Расправятся крылья, миллионов сердец
Поднимут все головы и грудью вздохнут
И громка скажут, что пришли
Мы пришли, со столетней войны
KLIMaka
Пользователь
Posts: 72


Новая версия компилятора
« Reply #4 on: 01 June 2009, 22:22:09 »

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

1) Указатели на функции. Это то что уже было, но не там где нужно )) В AddRegionProc можно передавать указатели на функции и только в этом случае имена функций не воспринимаются как их вызов (это то, о чем я говорил ниже). Пример использования я уже приводил в топике http://teamx.ru/smf/index.php?topic=402.msg3140#msg3140

2) Массивы функций. Может случится, что к ф-ии будет удобно обратится по индексу а не по имени. Например:

pocedure foo[3]( var a );

procedure foo[0](var a) begin /*some 0*/ end
procedure foo[1](var a) begin /*some 1*/ end
procedure foo[2](var a) begin /*some 2*/ end

procedure main
begin
  call foo[random(0,2)](0);
end


3) Масивы (статические/динамические) и структуры

struct s1
begin
  var a;
  var b;
end

procedure foo( var a )
begin
  var s[5]; // статический
  var f[a]; //динамический
  s1 aa;
  aa.a := 12;
  s[3] := 10;
end

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

procedure foo1( var &a)
begin
  a := 0;
end

procrdure foo2( var a)
begin
  a := 0;
end

procedure main
begin
  var a := 1;
  call foo2(a); // а копируется, после выполнения а == 1
  call foo1(a); // а не копируется, после вызова a == 0
end

5) Строгая типизация. Большинство скриптовых ошибок можно отловить на этапе компиляции, тем самым экономя уйму времени на отлаживании кода, который по непонятным причиинам не работает. Отсутствие типизации в SSLC может приводить к множеству проблем:

obj_art_fid( 12 ) не имеет никакого смысла, и это ясно еще на этапе компиляции, но SSLC это проглатывает
obj_art_fid( "мама" ) смысла еще меньше, но опять же никаких вопросов

Вообще никаких гарантий насчет типа SSLC не дает, что есть очень плохо! Никогда нельзя быть уверенным что ты получишь в результате. А статическая проверка типов сможет оградить от таких банальных и опасных ошибок. Так, например в SSLC допустимо:

procedure ten_add( var a)
begin
  return a + 10;
end

procedure main
begin
  var b[20]; var c;
  c := b[ten_add(11)]; //все верно, b == 11
  c := b[ten_add("a")]; //все верно, но b == "а10"  а это не является допустимым индексом. Будет очень трудно понять, почему что-то не работает
end

С типизацией:

int ten_add( int a)
begin
  return a + 10;
end

void main
begin
  int b[20]; int c;
  c := b[ten_add(11)]; //все верно, b == 11
  c := b[ten_add("a")]; //не будет скомпилированно из-за несоответствия типов
end

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

var someverylongname;
var someverylongnena;
someverylongname := 12;
someverylongnena:= self_obj;
destroy(someverylongname ); //непредсказуемое поведение, хотя от этого можно былобы избавится за счсет проверки типов.

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

7) Расширяемость. Дополнительные опкоды можно вводить простым дописыванием их в конфигурационный файлик.
« Last Edit: 02 June 2009, 10:53:54 by KLIMaka »
Wasteland Ghost
Администратор
Posts: 869

Маленькое Злое Привидение


Re: Новая версия компилятора
« Reply #5 on: 02 June 2009, 09:47:11 »

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

PS А вот массивов часто не хватает...
KLIMaka
Пользователь
Posts: 72


Re: Новая версия компилятора
« Reply #6 on: 02 June 2009, 11:59:16 »

Да, с этим я полностью согласен, язык станет несколько сложнее для освоения новичками, но зато избавит от многих проблем в будущем. Это примерно то, о чем говорил Ален Голуб в своей книге "Веревка достаточной длинны, чтобы… выстрелить себе в ногу" (глава 1.4).

По поводу того, что скрипты не настолько сложны... Я считаю, что основной причиной их простоты стоит видить именно в недостатке выразительных средств sslc. На нем просто невозможно написать что-нибудь долее или менее сложное без превращения этого всего в кашу-малашу нечитаемых строк. sslc слишком многословен - а чем больше приходится писать, тем больше может возникнуть ошибок. Зачем все эти begin/end? Они катастрофически отвлекают от восприятия самой программы, намного лучше их заменить на С`ишные {/}. И так далее... Попробую привести еще несколько примеров:

функциональная форма записи

if (tile_distance_objs(self_obj, last_source_obj) < DOOR_CLOSE_DIST and critter_state(last_source_obj) != CRITTER_IS_DEAD) then

по-моему проигрывает по читаемости такой форме

if ( self_obj.dist_to(last_source_obj) < DOOR_CLOSE_DIST and  last_source_obj.critter_state() != CRITTER_IS_DEAD )


set/get_local/global_var

что читаемее:
  set_local_var(v1,1);
или
  v1 := 1;
Ответ по-моему очевиден.

Импорт-экспорт процедур/переменных... Как это выглядело в sslc:

s1.ssl

export procedure s1_a;
export variable s1_b;

s2.ssl

export procedure s2_a; //не дай бог это имя будет не уникальным для всех скриптов карты!
export variable s2_b;

s3.ssl

import procedure s1_a;
/***/ и т.д....

Достаточно нудно и подверженно ошибкам. А ведь можно так:

s1.ssl

public:
procedure a;
variable b;

s2.ssl

public:
procedure a;
private:
variable b;

s3.ssl

import s1;
import s2;

procedure main
{
  s1.a();
  s1.b := s2.b; //Ошибка, s2.b объявлен как private
}

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

Ну и дальше в том же духе...
Jordan
Пользователь
Posts: 416

476228895
Re: Новая версия компилятора
« Reply #7 on: 02 June 2009, 14:47:36 »

Quote
Во-вторых, не все скриптеры программисты. Более строгий вариант SSL лучше для программиста, но хуже для обычного модмейкера.

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

Воспрянет Россия, из праха отцов
Расправятся крылья, миллионов сердец
Поднимут все головы и грудью вздохнут
И громка скажут, что пришли
Мы пришли, со столетней войны
Jordan
Пользователь
Posts: 416

476228895
Re: Новая версия компилятора
« Reply #8 on: 02 June 2009, 16:44:03 »

KLIMaka

Когда будет готова первая версия компилятора? Примерно скажи.

Воспрянет Россия, из праха отцов
Расправятся крылья, миллионов сердец
Поднимут все головы и грудью вздохнут
И громка скажут, что пришли
Мы пришли, со столетней войны
Ray
Глобальный модератор
Posts: 220

336150559
Re: Новая версия компилятора
« Reply #9 on: 02 June 2009, 18:00:18 »

Очевидно, when it's done Улыбка
KLIMaka
Пользователь
Posts: 72


Re: Новая версия компилятора
« Reply #10 on: 02 June 2009, 20:07:27 »

2Ray
Именно Подмигивающий Сейчас пока занят самой "нижней" частью - базовые итераторы для преобразования последовательности байтов в последовательность опкодов/строк/заголовков процедур и обратно. Уже есть функциональность аналогичная int2ssl с ключем -d. Сначала будет некое подобие макроассемблера, позволяющее писать и компоновать скрипты используя "naked" опкоды.

Упор я делаю не на конечную программу, а всеже на библиотеку, которая позволит удобно оперировать с откомпилированными *.int скриптами. Например, нужно извлеч из всех скриптов отладочные сообщения и сохранить их в отдельном файле. Затем этот файл с текстом переводится на другой язык, и снова вшивается в откомпилированные скрипты, с учетом всех сдвигов адресов и прочее.
Или изменить номер гвары в откомпилированных скриптах. Работа вроде обезьянья, но прийдется наново писать весь разбор скрипта на кусочки, поиск нужных мест и прочее. А так будет готовая библиотека, с помощью которой все это просто можно будет сделать.
Wasteland Ghost
Администратор
Posts: 869

Маленькое Злое Привидение


Re: Новая версия компилятора
« Reply #11 on: 02 June 2009, 20:19:32 »

KLIMaka Как C++'ник я с тобой полностью согласна. Улыбка Но ООП — штука не для всех. Для меня главная проблема вот в чём: снова вернётся разделение по компиляторам, которое исчезло с выходом sslc. Снова будем иметь два лагеря со своими понятиями и своими наборами несовместимых скриптов. А это не есть гуд.
Quote
//не дай бог это имя будет не уникальным для всех скриптов карты!
Для этого есть препроцессор и include. Каменный век, но просто и логично. Тем не менее, большего для скриптового языка и не надо. А то так дойдём и до пространств имён, виртуальных функций и АТД. Улыбка
KLIMaka
Пользователь
Posts: 72


Re: Новая версия компилятора
« Reply #12 on: 02 June 2009, 21:02:12 »

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

А вопрос о том что нужно или не нужно скриптовому языку, глубоко риторический. Я прекрасно понимаю, что по-сути не существует большой потребности в том, что я собираюсь внедрять, но это лично мне интересно, и я хочу этим заниматся. Авось что-нить стоящее выйдет. Пока единственная довольно веская причина для написания нового компилятора - неудобство с дополнением опкодами, хотя и это не большая проблема. Я отдаю себе отчет в том, что это может и ни понадобится никому, но ПОКА это меня не останавливает ))
Wasteland Ghost
Администратор
Posts: 869

Маленькое Злое Привидение


Re: Новая версия компилятора
« Reply #13 on: 03 June 2009, 08:03:06 »

То, что твой компилятор будет компилировать стандартные скрипты — это хорошо, это я поняла. Но вот sslc уже не будет компилировать исходники, написанные с использованием функций твоего компилятора. А это уже плохо. Это два стандарта.
Ray
Глобальный модератор
Posts: 220

336150559
Re: Новая версия компилятора
« Reply #14 on: 03 June 2009, 18:41:54 »

Спорный момент. Скрипты, написанные с sfall тоже ни с чем не совместимы, но новые функции дают такие возможности, которые оригинальному Ф и не снились. Как по мне, так ответ тут очевиден...

Кроме того, sslc уже морально устарел. Ничего плохого в появлении нормальной альтернативы нет, которую можно использовать как стандарт. Ведь перешли же на С++ вместо С в своё время Улыбка
Pages: [1] 2 3 |   Go Up