Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Будет ли KOL портирован на FreePascal?

Страницы: 1 2 >
Darts © (2002-12-23 12:56:00)

Или заточен только под Delphi?

_Vadim (2003-02-04 07:53:00) [1]

Можно и по мылу :))

Gandalf (2003-02-03 21:18:00) [2]

> примерчики "не того" качества компиляции у Kylix, если
> можно.
> Просто я в Kylix"e еще новичок :)).

Отсутсвие аппаратной оптимизации выше FPU. По моему это большой недостаток, опять же если сравнивать с GCC, p2cc эффективнее. Так же лично мне хотелось бы иметь ОДИН компилятор с адаптированной под него библиотекой, а не море компиляторов под разные платформы которые как тараканы разбигаются в свои стороны синтаксиса. По моему мы перешли на пустую полемику, которую если есть желание можно перевести на мыло. Тем более, что "необязательная" (в дальнейшем) открытость компилятора мне не очень нравится. Я не хочу делать новый компилятор, во всяком начитанать такой проект, ради библиотеки, лучше присоединится к готовым (тот же FPC, или GPC).

_Vadim (2003-02-03 15:58:00) [3]

2 Gandalf
А примерчики "не того" качества компиляции у Kylix, если можно.
Просто я в Kylix"e еще новичок :)).

Gandalf (2003-02-03 15:39:00) [4]

> чем ты компилишь KOL под виндой? Разве не DCC32? Если DCC32
> нельзя брать для компиляции KOL"а, то чем его нужно компилировать?

Конечно DCC32, больше (пока) KOL ничем не компилируется.

> А качество компиляции - это, как я понял, только страдания
> компилирующего по размеру полученого бинарника.
> Я не прав?

Это для кого как, для меня актуален вопрос качества компиляции, потому GNU Pascal не годится, хотя и держит ОЧЕНЬ много платформ, но не держит часть синтакчиса, и тут ищут компилятор который мульти платформенный, хороший (в плане качества компиляции), и под который реально адаптировать KOL не переделывая его полностью. Kylix конечно максимально совместим с Delphi, но качество компиляции оставляет желать лучшего, потому я лично его не рассматриваю. Но это мое мнение.

_Vadim (2003-02-03 11:50:00) [5]

2Gandalf

Честно говоря не понял твой ответ. А чем ты компилишь KOL под виндой? Разве не DCC32? Если DCC32 нельзя брать для компиляции KOL"а, то чем его нужно компилировать?
Прочитав высказывания в этом разделе я понял, что дело вовсе не в качестве компиляции (точнее, не совсем в качестве), а в том, что компиляторы паскаля под линух (и в частности free pascal) не поддерживают некоторых КЛЮЧЕВЫХ моментов, которые есть в DCC32 (под вин), поэтому KOL и не портируется под линух без особых ухищрений (скриптов например, как предлагал сам автор KOL"а. хотя и здесь есть свои сложности). Следовательно нужна именно совместимость по возможностям компиляции тех или иных компонент библиотеки). А качество компиляции - это, как я понял, только страдания компилирующего по размеру полученого бинарника.
Я не прав?

Gandalf (2003-02-03 11:16:00) [6]

> Можно глупый вопрос?
> А почему обязательно FreePascal? Как насчет Kylix? У него
> тоже есть open source версия, называется Open Edition. Я
> так понял, нужен только компилятор паскаля для порторования
> KOL, который бы один в один делал те-же действия с исходником
> библиотеки, что и DCC32?

Нам нужен не всякий компилятор, нам нужен хорошой компилятор, так один на тысячу... Тогда можно и DCC32 взять он максимально близок к Self. Дело ведь в качестве компиляции, а не в совместимости.

_Vadim (2003-02-03 08:11:00) [7]

Можно глупый вопрос?
А почему обязательно FreePascal? Как насчет Kylix? У него тоже есть open source версия, называется Open Edition. Я так понял, нужен только компилятор паскаля для порторования KOL, который бы один в один делал те-же действия с исходником библиотеки, что и DCC32?

Kladov (2003-02-01 10:00:00) [8]

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

Gandalf (2003-01-31 21:04:00) [9]

GNU Pascal:
1) Не держит половину необходимого синтаксиса (например property, private, public и т.п.)
2) Отвратительно компилирует (огромный по размеру код)

Virtual Pascal:
1) Не держит необходимый синтаксис (тот же property, нужен переход на классы)

Итак на повестке для перевод KOL на class, ну, кто возмется ?

PVOzerski (2003-01-17 18:20:00) [10]

Решил вот поднять эту ветку... Помнится, перед Новым годом [m]Dem0n брался собрать команду под сабж... Притом безо всяких смайликов. А я обещался, по мере сил и времени, помогать (если это было написано невнятно, прошу прощения). Так как, команда-то появилась? Еще раз подчеркиваю: IMHO, дело более сложное, чем на первый взгляд, но небессмысленное.

PVOzerski (2003-01-13 02:13:00) [11]

Теперь - что я думаю о применимости других компиляторов. Коммерческие (типа TMT или SpeedPascal) обсуждать, IMHO, смысла нет. Из free знаю FPC (AKA FreePascal), Virtual Pascal, gpc (GNU Pascal). Относительно FPC моя позиция понятна: принципиально пригоден, но требует доработки, причем на помощь официальныз разработчиков, похоже, рассчитывать не приходится. О GPC знаю мало, но складывается впечатление, что его совместимость по синтаксису с BP/Delphi весьма ограничена. Virtual Pascal, в принципе, мне кажется небезнадежным, но требует примерно тех же доработок, что и FPC (я проверял), однако поскольку его исходники недоступны, заниматься этими доработками самостоятельно невозможно.

PVOzerski (2003-01-13 01:58:00) [12]
Ситуация c VMT вот какая.

Вот текст тестовой программы.

{$smartlink on}
{$mode delphi}
type
t1=object
constructor create;
procedure proc;virtual;
destructor destroy;
end;
t2=object(t1)
procedure proc;virtual;
end;

constructor t1.create;
begin
end;

destructor t1.destroy;
begin
end;

procedure t1.proc;
begin
writeln("111111");
end;

procedure t2.proc;
begin
writeln("222222");
end;

var
o2:t2;
begin
o2.create;
o2.proc;
o2.destroy;
end.

А вот что получается в ассемблерном виде при компиляции FPC
для VMT (асм в стиле AT&T):

.data
.balign 4
.globl VMT_PROGRAM_T1
VMT_PROGRAM_T1:
.long 4,-4,0
.long _PROGRAM_T1_$_PROC$ //адрес метода t1.proc - мертвый код!
.balign 4
.globl VMT_PROGRAM_T2
VMT_PROGRAM_T2:
.long 4,-4
.long VMT_PROGRAM_T1 // ссылка на класс-родитель
.long _PROGRAM_T2_$_PROC$

Примерно такое же попадает в obj-файлы или библиотеки после компиляции юнитов. А поскольку заранее не известно, что из юнита понадобится при линковке, на этапе компиляции ненужные ссылки на неиспользуемые методы убрать нельзя.
Есть ли выход? IMHO, всё-таки есть, но он требует серьезной переделки компилятора. Я вижу такое решение (не настаиваю на его единственности и оптимальности): пусть этот код вообще не помещается в obj-файлы/библиотеки, соответствующие юнитам, но в виде "заготовок" хранится в соответствующих PPU-шках (кто знает FPC, поймет, о чем речь), а перед сборкой .exe/.dll компилятор на основе этих "заготовок" сгенерит VMT либо в главном модуле программы, либо в отдельном obj-файле, проверяя при этом ссылки на используемость. Возможно, пригодный для этой цели механизм хранения "заготовок" уже реализован в ветви 1.1 (но точно не знаю) - для хранения public inline-функций.
Так что вот материал для размышлений добровольцам :^)

Boguslaw (2003-01-11 21:32:00) [13]

Yes.You are right.You"ve written long time ago that Virtual Method Table should be rewritten.Could You explain in more details why is it so difficult , becouse maybe I do not realize where is the main problem.Will this broke compability with older versions of FPC ?

Boguslaw

PVOzerski (2003-01-10 15:36:00) [14]

FPC 1.1 понимает properties в старых объектах при Delphi-совместимом режиме компиляции -
{$ mode Delphi} или -Sd (кстати, сам эту фичу делал и специально для KOL).
Boguslaw, you did not understand me correctly. I"m not doubt that FPC supports OOP, but it is not able
to cut out fully overwritten and therefore unused virtual methods of parent old-style objects. That"s
a real problem. Всем остальным: извините за вставку по-английски, но я счел нужным сделать ее
специально для Boguslaw"а в надежде облегчить ему общение. Надеюсь, важность затрагиваемой
им проблемы позволит чуть-чуть нарушить правила форума, при том, что русский язык не является
для него родным.

Gandalf (2002-12-30 22:31:00) [15]

Незнаю, из всего обилия компиляторов FreePascal, GNUPascal,Virtual,Fast - самые, еще вектор хорош мощной оптимизацией под SIMD (но это не самое важное, пока). Я вот хочу попробовать приладить КОЛ к GNU (и ОС много, и платформ (например MIPS :))- думаю он в этом планее наиболее совместимый и перспективный. Вообще если кому интересно вот линк, на россыпь компиляторов http://www.thefreecountry.com/developercity/pascal.shtml.

У вирта совсем маленький набор портов, потому лично мне он не очень интересен. А на счет адаптации, пожалуй она под вирт не так уж и сложна.

Zanuda (2002-12-30 18:17:00) [16]

А как насчет? Virtual Pascal или покета компиляторов gcc допустим трейтьей версии?!

Boguslaw (2002-12-30 18:01:00) [17]

Bad news. FPC do not like properties in objects :-(
(FPC version 1.0.6)
What perfect compiler for KOL should have ?

Gandalf (2002-12-29 22:51:00) [18]

Я думаю всеж таки FPC еще далек от того состояния когда на него стоит портировать КОЛ. Да и многие другие вариации компиляторов тоже. Какие собственно компилятор даст плюсы? Размер - и сейчас неплохо, тем более уверен, он уменьшится не сильно. Скорость работы (мда... вот у Borland промах - особенно по ммм... железячной оптимизации, ни тебе MMX, XMM, SSE и т.п. - а не плохо бы). Мульти ОС - влечет за сабой довольно глобальную переработку KOLnMCK. Ну это я так в порядке здоровой критике, конечно же идея портирования - интересна и всегда актуальна для обсуждения, переодически просматриваю компиляторы, на тему - "а может уже пора?". Тут вопрос только на какой компилятор идти - их много.

Boguslaw (2002-12-29 21:00:00) [19]

I changed second procedure "proc" (You didn"t want to overload ths procedure right ?) and seem working even without DELPHI mode ;-)
Please confirm.
My FPC version = 1.0.6
That"s why I insist in FPC port of KOL :-0
Look below:

program demo1;
{$APPTYPE CONSOLE}
//{$MODE DELPHI}
{$smartlink on}

type
to1=object
procedure proc;virtual;
constructor create;
end;

to2=object(to1)
procedure proc;virtual;
end;

procedure to1.proc;
begin
writeln("111111111111111");
end;

procedure to2.proc;
begin
writeln("222222222222222");
end;

constructor to1.create;
begin
end;

var
o2:to2;
begin
o2.create;
o2.proc;
end.

Result := 222222222222222
For me it is well OK! (object inheritance is working) What do You think ?

Boguslaw

PVOzerski (2002-12-29 00:26:00) [20]

Я уже давно экспериментировал с перекомпиляцией, сразу же возникли проблемы с properties. Это была версия 1.1, но она не имеет релизов, это постоянно изменяющийся вариант компилятора, который когда-нибудь будет релизом с очередным четным номером версии. Так что насколько изменилась ситуация с его совместимостью с KOL к настоящему времени - не знаю. Но советую произвести простенькие опыты с Вашей версией. Например:
{$smartlink on}
type
to1=object
procedure proc;virtual;
constructor create;
end;

to2=object(to1)
procedure proc;virtual;
end;

procedure to1.proc;
begin
writeln("111111111111111");
end;

procedure to1.proc;
begin
writeln("222222222222222");
end;

constructor to1.create;
begin
end;

var
o2:to2;
begin
o2.create;
o2.proc;
end.

Пожалуйста, проверьте, содержит ли получившийся exe-файл 111111111111111. Если да - ситуация не изменилась :^(

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »