| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Кому чего в KOLnMCK не хватает?
_gandalf_ © (2006-11-23 22:42:00)Я уже както задавал - но было довольно давно - интересно как сейчас дела обстоят...?
Galkov (2006-11-26 20:34:00) [21]Кстати, если кто знает консольную "нарезку" с того FPC, который знает object, наша благодарность не будет иметь границ, в разумных пределах.
:)))))))))))
Galkov (2006-11-26 20:30:00) [22]Offtop немного....
имею некоторое отношение к проекту, который на основание некой схемы, (понятной даже, скажем так, незнакомому с программированием челу) генерирует исходные коды.
Т.е., является надстройкой над неким компилятором.
Когда среда весит пару метров, сложновато как-то говорить о компиляторе в 20М. Или 320 :)
С 4-м Дельфи все прелестно - вместе с KOL-ом, упакованый весит всего метр.
С FPC посложнее, прямо скажем. Из-за размеров - это 1.9.X
Просто не знаю консольного варианта для 2.X.X, которым уже известны object. Следовательно - это портирование KOL под классы
Проблемы, в общем :)
Кстати, первое (но очень не сразу) на что я "наступил" в портированном варианте:
procedure TObj.DoDestroy;
begin
if fRefCount <> 0 then
begin
if not LongBool( fRefCount and 1) then
Dec( fRefCount );
end
else
Self.Destroy; //Было просто Destroy, но FPC это понимает как TObj.Destroy
end;
Vladimir Kladov (2006-11-26 19:43:00) [23]Так если что надо от KOL в этом направлении, мы всегда по мере сил. И даже народ помогал авторам FPC (т.е. участвовал в open source) чтобы и гора к магомету тоже пришла. Было же, что FPC не хотел object, так "уговорили", чтобы хотел.
Galkov (2006-11-26 18:30:00) [24]
> Ну, сделайте допуск * 2 на тупость компилятора
Согласен. Даже где-то 1.5...2.0 (по опыту) :))
Но сделать KOL для FPC (5-10 раз конечно хочется :)) - серьезные напряжения вызывает сегодня...
Безглючного портирования я как-бы и не видел...
Пользую, конечно. Но порой такие прелести, что цензурных слов-то и нет :(
Vladimir Kladov (2006-11-26 18:00:00) [25]Даже если он такой тупой, то это все равно не смертельно. Я сейчас глянул, пустое приложение, которое ничего не делает, в версии 2 всего 29,5К. Это не 16К от Delphi, конечно, тем более не 5,5К от Delphi+замены system, но уже и не 50К, как было раньше. Размер приложений чаще растет не за счет своего кода, а засчет всяких сторонних модулей, и ресурсов, а их размер и там, и там будет примерно одинаковый. Библиотеки для работы с графикой, например, часто делаются на С и прилинковываются из obj-файлов. (Кстати, в отличие от Delphi, FPC умеет это делать). В этом случае все равно будет размер нивелироваться с ростом приложения. Еще может быть такое, что большая часть кода - это код, сгенерированный для инициализации формы (если проект портируется из Delphi, а там он делался в MCK). И тогда вполне возможно использовать Collapse, и эта часть не только не будет зависеть от компилятора, но еще и будет меньше в 2 раза, чем даже после "умного" Delphi. Ну, сделайте допуск * 2 на тупость компилятора, но я уверен - это не фатально, и малые приложения останутся все равно малыми, потому что просто порядки размеров другие для KOL: в 5-10 раз все равно меньше.
Galkov (2006-11-26 11:33:00) [26]Слова, слова.... :)
А если конкретно, при использовании FPC с такой шапкой
Free Pascal Compiler version 1.9.6 [2004/12/31] for i386
Copyright (c) 1993-2004 by Florian Klaempfl
Target OS: Win32 for i386
следующий простенький код (специально ничего не делал, просто дернул со своего форума)
procedure THICounter._work_doReset;
begin
if _prop_Type = 0 then
FCounter := _prop_Min
else FCounter := _prop_Max;
end;
делается вот так:
0040ECA0: 55 push ebp
0040ECA1: 89E5 mov ebp,esp
0040ECA3: 83EC0C sub esp,0000000C
0040ECA6: 8945F4 mov dword ptr [ebp-0C],eax
0040ECA9: 8955FC mov dword ptr [ebp-04],edx
0040ECAC: 66894DF8 mov word ptr [ebp-08],cx
0040ECB0: 8B45F4 mov eax,dword ptr [ebp-0C]
0040ECB3: 0FB64018 movzx eax,byte ptr [eax+18]
0040ECB7: 85C0 test eax,eax
0040ECB9: 7402 jz 0040ECBD
0040ECBB: EB0E jmp 0040ECCB
0040ECBD: 8B45F4 mov eax,dword ptr [ebp-0C]
0040ECC0: 8B55F4 mov edx,dword ptr [ebp-0C]
0040ECC3: 8B400C mov eax,dword ptr [eax+0C]
0040ECC6: 894204 mov dword ptr [edx+04],eax
0040ECC9: EB0C jmp 0040ECD7
0040ECCB: 8B45F4 mov eax,dword ptr [ebp-0C]
0040ECCE: 8B55F4 mov edx,dword ptr [ebp-0C]
0040ECD1: 8B4010 mov eax,dword ptr [eax+10]
0040ECD4: 894204 mov dword ptr [edx+04],eax
0040ECD7: C9 leave
0040ECD8: C3 ret
Для сравнения, как это же самое делает дельфя:
00411198: 80781800 cmp byte ptr [eax+18],00
0041119C: 7507 jnz 004111A5
0041119E: 8B500C mov edx,dword ptr [eax+0C]
004111A1: 895004 mov dword ptr [eax+04],edx
004111A4: C3 ret
004111A5: 8B5010 mov edx,dword ptr [eax+10]
004111A8: 895004 mov dword ptr [eax+04],edx
004111AB: C3 ret
И вот теперь было бы уместно порассуждать: чего надо, или нет для Debug....
Хотя мне представляется, что комментарии тут излишни.
И аналогичное - по всему коду, естественно.
Вот ОТСЮДА и возникали у меня сомнения про то, что разница в размере кодов на больших проектах нивелируется
И если кто-то подскажет комбинацию ключей для fpc делающую его умнее - то просто нет слов. Я пока не нашел. :(
И что версии 2.X.X - умнее не очень верится.
Но если кто продемонстрирует (у кого есть зачанные эти версии, конечно) что я ошибаюсь - придется качать :)))
Как видите, аргументация-то очень простая - вот код, а вот результат :)
Но, она ведь действительно аргументация...
Vga (2006-11-25 21:19:00) [27]> [29] Galkov © (25.11.06 15:36)
Быть может, ты включал оптимизацию по скорости выполнения, а не по размеру кода? В одном тесте AFAIK Intel C++ намного обскакал ассемблерщика по производительности и изрядно отстал по размеру кода.
Galkov (2006-11-25 15:36:00) [28]
> а оптимизацию включали? в дебуг-режиме код от Delphi тоже
> не блещет остроумием
Да. Перепробованы все варианты. Что именно там называется оптимизацией - осталось загадкой.
А тупость такая, что Debug-ом объяснять очень трудно...
Да и про гнутый линкер... Не для этой темы, наверное :))))
Vga (2006-11-25 15:21:00) [29]> что стандалоне не запустился, это возможно проблемы триала.
Вроде не триал был...
Vladimir Kladov (2006-11-25 15:13:00) [30]что стандалоне не запустился, это возможно проблемы триала. Или в настройках надо ковыряться. Надо попробовать, что он мне скажет. Правда у меня кайликс-1 только.
Vga (2006-11-25 14:46:00) [31]> Для MCK надо делать standalone-приложение, которое имеет
> свой дизайнер форм, и использует именно код из MCK по максимуму,
> чтобы задействовать наработанный код зеркал. Делать надо
> на VCL/CLX (иначе как использовать классы MCK), так его
> можно будет откомпилировать по крайней мере для Windows
> И Linux. (Ну можно попробовать и на FPC, но MCK сразу был
> под Windows заточен, так что могут появиться проблемы).
Standalone - да, согласен, а вот насчет CLX... Кратковременное знакомство с кайликсом вызвало ощущение, что не только он сам как-то странно сделан (это возникло после просмотра запущенных им профессов - он много чего для своей работы запустил, включая wine), но и компилирует через то же место (во всяком случае, хотя тестовый проект хорошо работал из IDE/Debugger'а, но непосредственно исполнимый файл запустить не удалось - линукс его ни в какую не признавал).
Vladimir Kladov (2006-11-25 13:52:00) [32]а оптимизацию включали? в дебуг-режиме код от Delphi тоже не блещет остроумием.
Galkov (2006-11-25 12:00:00) [33]Про FPC.
Версии выше 2-й не проверял... Просто потому, что не нашел их консольных вариантов. А качать 20M ради сомнительного удовольствия - не хотелось
А ниже, действительно, ASM - неприменим. И не только из-за синтаксических различий. Порой просто умирает по необъяснимым причинам (может потому, что -MDelphi)
С тем, что при увеличении проекта разница невелируется - не соглашусь.
Просто ОЧЕНЬ тупой компилятор. И это проявляется на КАЖДОЙ команде.
Свидетельством этого косвенно является еще и большая степень компрессии каким нибудь UPX.
Говорю потому, что мне не лень было полазить дизасмом. Что видел, то и говорю
Vladimir Kladov (2006-11-25 11:36:00) [34]GTK поддерживается для всех unix-платформ, и для Windows. Т.е. это тоже мультиплатформенная штука. Вот сейчас продолжу работу над переходом к нему, как раз после UNICODE боле-мене начал приходить в себя.
Для MCK надо делать standalone-приложение, которое имеет свой дизайнер форм, и использует именно код из MCK по максимуму, чтобы задействовать наработанный код зеркал. Делать надо на VCL/CLX (иначе как использовать классы MCK), так его можно будет откомпилировать по крайней мере для Windows И Linux. (Ну можно попробовать и на FPC, но MCK сразу был под Windows заточен, так что могут появиться проблемы).
Часть, которая встраивается в Delphi (а такая все-таки нужна) - в виде визарда, который обменивается с standalone-дизайнером сообщениями или через mapping-файл. Нужна она, чтобы сразу сообщать Delphi/BDS об изменениях в файлах pas и inc, и наоборот - тоже. Хорошо бы интерфейс сделать таким, что если появится возможность сделать аналогичный визард для Lazarus, то это тоже прошло бы без особых изменений в standalone-MCK.
Но standalone можно сделать так, что если визарда нет (или еще нет), работать все равно можно бы было.
Еще: standalone-MCK должен понимать / модифицировать dfm-файлы, они в текстовом виде в Delphi где-то с 4-5, так что это не великая проблема.
Так что, кто-то хочет взяться (Gandalf?). Срочности большой нет, сложности в не-визард-части тоже особо никакой не вижу (пока). Время только надо. У меня и так GTK подвис.
Vga (2006-11-25 11:25:00) [35]> [21] Vladimir Kladov (25.11.06 10:47)
А толку, если KOL (Windows) их не поддерживает? Разве что GTK версия будет компилироваться везде...
Vladimir Kladov (2006-11-25 10:47:00) [36]FPC добавлял примерно 50К за счет своего system.pp или как его там. Так было до версии 2, в 2 я не смотрел. Можно поискать, не делал ли кто замены system для него. Кроме того, наша асм-версия с ним несовместима, из-за некоторых отличий в синтаксисе. Для небольших проектов, использующих из KOL немного, это несущественно, ну 5К добавит. При увеличении проекта разница нивелируется. Зато FPC поддерживает очень много платформ, и не только разных ОС на PC, но и совсем других архитектур процессора и памяти.
Vedun (2006-11-24 23:34:00) [37]А размер программ, откомпилированных с использованием KOL в Delphi и FPC, сильно отличается?
Vga (2006-11-24 23:20:00) [38]> [18] ANTPro © (24.11.06 23:17)
Дельфи закрытый, его никак не перепишешь, увы. Разве что придурь разработчикам придет, как с InterBase 6.0 OpenSource.
ANTPro (2006-11-24 23:17:00) [39]> [16] Vga © (24.11.06 23:15)
Я то тут причем? Delphi стабильней будет намного...
Vga (2006-11-24 23:16:00) [40]> [15] Vedun (24.11.06 23:05)
LCL. Большая. И smart linking в FPC похоже хуже работает. Тем более своего линкера у него нет, он гнутым пользуется.
| |
Страницы: 