А, ну да. Вчера настолько заинтересовался сайтом автора, что пропустил модификацию для Колибри.
Сейчас скачал, но не понял, где там Колибри. Я понимаю, что поддержка Колибри может и должна быть добавлена как полноценная платформа, пусть даже и с кросс-компиляцией из-под Windows и/или Linux.
Завтра заработает хостинг, и в моём блоге станет доступна статья с описанием двух принципиальных, на мой взгляд, проблем портирования ЯВУ в Колибри.
Возможные будущие компиляторы для Колибри
-
Last edited by Freeman on Fri Sep 30, 2011 8:14 pm, edited 3 times in total.
В Колибри нет pipes. Это единственное, что затрудняет портирование приложений - лично для меня.
> написаны на Паскале, что практически сводит на нет возможность их портирования
> я не думаю, что это безумно сложная задача
Портировать FPC просто. Была бы ещё адекватная консоль.
Надеюсь получится в следующем году вернуться к этому вопросы, а то я как забросил это дело, больше никто им и не занимался.
> завышенные ожидания от FPC, и чтобы получить в нём что-то путное, надо намного дольше копаться
В своё время за пару дней смог завести под KOS. Нет там ничего феноменально сложного. Про include'ы, это да, согласен, не видал такого раньше, да и сам синтаксис не айс, но ведь работает зараза.
p.s. Надо опять резать тред, а то оффтопик попёр :-).
..bw
> я не думаю, что это безумно сложная задача
Портировать FPC просто. Была бы ещё адекватная консоль.
Надеюсь получится в следующем году вернуться к этому вопросы, а то я как забросил это дело, больше никто им и не занимался.
> завышенные ожидания от FPC, и чтобы получить в нём что-то путное, надо намного дольше копаться
В своё время за пару дней смог завести под KOS. Нет там ничего феноменально сложного. Про include'ы, это да, согласен, не видал такого раньше, да и сам синтаксис не айс, но ведь работает зараза.
p.s. Надо опять резать тред, а то оффтопик попёр :-).
..bw
Может я чего-то не знаю о pipe, но вот:SoUrcerer wrote:В Колибри нет pipes. Это единственное, что затрудняет портирование приложений - лично для меня.
Spoiler:
======================================================================
=== Функция 68, подфункция 22 - открыть именованную область памяти. ==
======================================================================
Параметры:
* eax = 68 - номер функции
* ebx = 22 - номер подфункции
* ecx = имя области. Максимум 31 символ, включая завершающий ноль
* edx = размер области в байтах для SHM_CREATE и SHM_OPEN_ALWAYS
* esi = флаги открытия и доступа:
* SHM_OPEN = 0x00 - открыть существующую область памяти.
Если область с таким именем не существует,
функция вернёт код ошибки 5.
* SHM_OPEN_ALWAYS = 0x04 - открыть существующую или создать новую
область памяти.
* SHM_CREATE = 0x08 - создать новую область памяти.
Если область с таким именем уже существует,
функция вернёт код ошибки 10.
* SHM_READ = 0x00 - доступ только на чтение
* SHM_WRITE = 0x01 - доступ на чтение и запись
Возвращаемое значение:
* eax = указатель на область памяти, 0 при ошибке
* при создании новой области (SHM_CREATE или SHM_OPEN_ALWAYS):
edx = 0 - успех, иначе - код ошибки
* при открытии существующей области (SHM_OPEN или SHM_OPEN_ALWAYS):
edx = код ошибки (при eax=0) или размер области в байтах
Коды ошибок:
* E_NOTFOUND = 5
* E_ACCESS = 10
* E_NOMEM = 30
* E_PARAM = 33
Замечания:
* Предварительно следует инициализировать кучу процесса вызовом
подфункции 11.
* Если создаётся новая область, то флаги доступа устанавливают
максимальные права доступа для остальных процессов. Попытка
открытия другим потоком с неразрешёнными правами провалится
с кодом ошибки E_ACCESS.
* Процесс, создавший область, всегда имеет доступ на запись.
======================================================================
=== Функция 68, подфункция 23 - закрыть именованную область памяти. ==
======================================================================
Параметры:
* eax = 68 - номер функции
* ebx = 23 - номер подфункции
* ecx = имя области. Максимум 31 символ, включая завершающий ноль
Возвращаемое значение:
* eax разрушается
Замечания:
* Область памяти физически освобождается (с забыванием всех данных
и высвобождением физической памяти), когда её закроют
все открывшие потоки.
* При завершении потока освобождаются все открытые им
области памяти.
bw, я буду ждать с нетерпением. Такие интересные люди, как ты, в проекте на пересчет. Среди моих знакомых Free Pascal в Колибри будет очень востребован. По крайней мере, в той школе, где моя мама работает учителем информатики.
Mario, через именованные шаренные области можно попробовать реализовать костыль, похожий на pipes (то есть вызывающая программа каким-то хитрым образом создает именованную область, указатель на которую каким-то образом передается вызываемой программе для дальнейших действий, причем эта вызываемая программа каким-то хитрым образом свои данные может передавать дальше, выводить в файл или stdout). Но мне кажется, что это не труЪ.
Кстати, разделил тему.
Mario, через именованные шаренные области можно попробовать реализовать костыль, похожий на pipes (то есть вызывающая программа каким-то хитрым образом создает именованную область, указатель на которую каким-то образом передается вызываемой программе для дальнейших действий, причем эта вызываемая программа каким-то хитрым образом свои данные может передавать дальше, выводить в файл или stdout). Но мне кажется, что это не труЪ.
Кстати, разделил тему.
Чего же тут такого хитрого? В расшаренной памяти можно организовать что-то вроде кольцевого буфера, а в самом начале будет служебная область, которая будет содержать всякие указатели. К примеру OpenDialog именно так и реализован. Указатель на именованную область передается в виде параметра, при запуске приложения. Единственный минус, я не стал пользоваться старой функцией IPC и для OpenDialog просто реализован периодический опрос мьютекса, что в его случае не является таким уж большим недостатком. Мне так кажется реализовать pipe на основе именованной расшаренной памяти и IPC мешает исключительно лень (лень разбираться с реализацией), а работать такое будет нисколько не хуже.
В моей ламерской голове такое не укладывается. Если такой механизм будет реализован, это будет нереально круто. Потом будет сделать межпроцессное взаимодействие - элементарно, и CGI - тоже.
Еще бы найти толковое описание как реализован тот pipe, который нужен именно тебе (и желательно на русском), а то я как почитал в *nix одно обозначает в win лругое.
http://ru.wikipedia.org/wiki/%D0%9A%D0% ... %28UNIX%29
По сути, проблема сводится к тому, что нет стандартных средств перенаправления stdin и stdout. Равно как и самих stdin и stdout - это понятия, виртуальные для Колибри, как я понимаю.
По сути, проблема сводится к тому, что нет стандартных средств перенаправления stdin и stdout. Равно как и самих stdin и stdout - это понятия, виртуальные для Колибри, как я понимаю.
Хм... по таким куцым сведениям сделать что-то нереально и я так и не понял что конкретно требуется тебе. Просто в *nix сама концепция изначально все рассматривать в виде файлов (именно по этому кстати падает производительность на некоторых участках - слишком большая величина абстракции), в Колибри естественно такое не проканает - запись в файл это одно, запись в расшаренную память это другое и писать полноценную реализацию как в *nix это все равно что треть ядра Linux сделать.
Хм. Я тут подумал, pipelines - это вещь, в Колибри совершенно ненужная. Без нее не будет работать куча всяких консольных утилит, но они в Колибри и не нужны. Вот так. В конце концов, мы же не еще один клон Unix.
По техническим причинам статья стала доступна только сегодня.
Сильно! Самокритичность нужна в меру! Стоит заменить более мягким вариантом.И тут оказалось, что я кретин.
Ошибка, на самом деле в macros.incmcall: EBX, ECX, EDX, ESI, EDI, EBP
Code: Select all
macro mcall a,b,c,d,e,f { ; mike.dld
__mov eax,a
__mov ebx,b
__mov ecx,c
__mov edx,d
__mov esi,e
__mov edi,f
int 0x40
}
MCALL это макрос и он не генерируется FASM'ом. Опять же смотреть macros.incРодной компилятор для Колибри должен уметь генерить mcall
Ассемблерщики такие ассемблерщики. Вот где вы видели, чтобы программист на ЯВУ писал что-то вроде:
где 1 -- это код функции PutPixel? Это на ассемблере "функция 1", а на ЯВУ -- PutPixel. Поэтому и нужно именование.
С точки зрения компилятора не важно, где что генерится. Если уж на то пошло, и stdcall, и cdecl, и fastcall можно генерить макросом. В Колибри именно что сложился свой тип вызова, с точки зрения ЯВУ выглядящий как импорт по номеру и порядок регистров, как я указал. Импорт по номеру не является из ряда вон выходящим -- где-то в Windows функции OLE32.dll, кажется, импортируются тоже по номеру.
Собственно, есть две вариации mcall:
где f и s -- номера функции и подфункции, соответственно. От этого и надо плясать. Где не получается компилятор научить -- ассемблерные прослойки писать. Подозреваю, что так и делается сейчас в GCC и FPC.
Но для дальнейшего развития ЯВУ в Колибри отрицать наличие mcall как родного типа вызова было бы глупо.
Code: Select all
PutPixel(1, X, Y, Color);
С точки зрения компилятора не важно, где что генерится. Если уж на то пошло, и stdcall, и cdecl, и fastcall можно генерить макросом. В Колибри именно что сложился свой тип вызова, с точки зрения ЯВУ выглядящий как импорт по номеру и порядок регистров, как я указал. Импорт по номеру не является из ряда вон выходящим -- где-то в Windows функции OLE32.dll, кажется, импортируются тоже по номеру.
Собственно, есть две вариации mcall:
Code: Select all
void func(word EBX, ECX, EDX, ESI, EDI, EBP); mcall f;
void func(word ECX, EDX, ESI, EDI, EBP); mcall f.s;
Но для дальнейшего развития ЯВУ в Колибри отрицать наличие mcall как родного типа вызова было бы глупо.
Еще раз: mcall - это не вызов, вызов это прерывание int 0x40
И раз уж пишешь именно про Колибри, то забывать или игнорировать, что первым параметром в mcall идет именно EAX - мне это кажется весьма странным поведением.
Все мои замечания касались именно ассемблерной части, которую ты вольно так употребляешь.
Если ты подразумевал mcall который не для ассемблера, то стоит это явно обозначить, иначе фигня какая-то получается - без обид.
Может я такой весь из себя странный ассемблерщик, но по моей логике никак такое не укладывается.
И раз уж пишешь именно про Колибри, то забывать или игнорировать, что первым параметром в mcall идет именно EAX - мне это кажется весьма странным поведением.
Все мои замечания касались именно ассемблерной части, которую ты вольно так употребляешь.
Если ты подразумевал mcall который не для ассемблера, то стоит это явно обозначить, иначе фигня какая-то получается - без обид.
Вот в этой части ты ведь говоришь именно об ассемблере, никак не об формате для ЯВУ и почему-то в приведенной как код структуре опущен EAX, но присутствует EBP.Как это должно выглядеть в Колибри? Во-первых, в ней, как и в любой другой уважающей себя ОС, есть свой тип вызова — mcall. В разговоре с dunkaist-ом я пытался всё назвать его kcall или kocall, но сейчас, глядя в исходники, вспомнил, что тут Колибри хранит традиции, тем более, что сам формат вызова не изменился: ¶EAX используется для передачи номера функции и возврата результата, а EBX — передачи номера подфункции, если есть. Для программиста ЯВУ выглядит странно, но на ассемблере — вполне даже.Code: Select all
mcall: EBX, ECX, EDX, ESI, EDI, EBP
Может я такой весь из себя странный ассемблерщик, но по моей логике никак такое не укладывается.
Who is online
Users browsing this forum: No registered users and 10 guests