Возможные будущие компиляторы для Колибри

...
  • SoUrcerer
    Posts 2810
    Joined: Mon Sep 24, 2007 11:11 am

    В Колибри нет pipes. Это единственное, что затрудняет портирование приложений - лично для меня.
  • User avatar
    bw
    Posts 443
    Joined: Thu Mar 01, 2007 4:16 pm

    > написаны на Паскале, что практически сводит на нет возможность их портирования
    > я не думаю, что это безумно сложная задача
    Портировать FPC просто. Была бы ещё адекватная консоль.
    Надеюсь получится в следующем году вернуться к этому вопросы, а то я как забросил это дело, больше никто им и не занимался.

    > завышенные ожидания от FPC, и чтобы получить в нём что-то путное, надо намного дольше копаться
    В своё время за пару дней смог завести под KOS. Нет там ничего феноменально сложного. Про include'ы, это да, согласен, не видал такого раньше, да и сам синтаксис не айс, но ведь работает зараза.

    p.s. Надо опять резать тред, а то оффтопик попёр :-).

    ..bw
  • Mario

    SoUrcerer wrote:В Колибри нет pipes. Это единственное, что затрудняет портирование приложений - лично для меня.
    Может я чего-то не знаю о pipe, но вот:
    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 разрушается
    Замечания:
    * Область памяти физически освобождается (с забыванием всех данных
    и высвобождением физической памяти), когда её закроют
    все открывшие потоки.
    * При завершении потока освобождаются все открытые им
    области памяти.
  • SoUrcerer
    Posts 2810
    Joined: Mon Sep 24, 2007 11:11 am

    bw, я буду ждать с нетерпением. Такие интересные люди, как ты, в проекте на пересчет. Среди моих знакомых Free Pascal в Колибри будет очень востребован. По крайней мере, в той школе, где моя мама работает учителем информатики.
    Mario, через именованные шаренные области можно попробовать реализовать костыль, похожий на pipes (то есть вызывающая программа каким-то хитрым образом создает именованную область, указатель на которую каким-то образом передается вызываемой программе для дальнейших действий, причем эта вызываемая программа каким-то хитрым образом свои данные может передавать дальше, выводить в файл или stdout). Но мне кажется, что это не труЪ.

    Кстати, разделил тему.
  • Mario

    Чего же тут такого хитрого? В расшаренной памяти можно организовать что-то вроде кольцевого буфера, а в самом начале будет служебная область, которая будет содержать всякие указатели. К примеру OpenDialog именно так и реализован. Указатель на именованную область передается в виде параметра, при запуске приложения. Единственный минус, я не стал пользоваться старой функцией IPC и для OpenDialog просто реализован периодический опрос мьютекса, что в его случае не является таким уж большим недостатком. Мне так кажется реализовать pipe на основе именованной расшаренной памяти и IPC мешает исключительно лень (лень разбираться с реализацией), а работать такое будет нисколько не хуже.
  • SoUrcerer
    Posts 2810
    Joined: Mon Sep 24, 2007 11:11 am

    В моей ламерской голове такое не укладывается. Если такой механизм будет реализован, это будет нереально круто. Потом будет сделать межпроцессное взаимодействие - элементарно, и CGI - тоже.
  • Mario

    Еще бы найти толковое описание как реализован тот pipe, который нужен именно тебе (и желательно на русском), а то я как почитал в *nix одно обозначает в win лругое.
  • SoUrcerer
    Posts 2810
    Joined: Mon Sep 24, 2007 11:11 am

    http://ru.wikipedia.org/wiki/%D0%9A%D0% ... %28UNIX%29
    По сути, проблема сводится к тому, что нет стандартных средств перенаправления stdin и stdout. Равно как и самих stdin и stdout - это понятия, виртуальные для Колибри, как я понимаю.
  • Mario

    Хм... по таким куцым сведениям сделать что-то нереально и я так и не понял что конкретно требуется тебе. Просто в *nix сама концепция изначально все рассматривать в виде файлов (именно по этому кстати падает производительность на некоторых участках - слишком большая величина абстракции), в Колибри естественно такое не проканает - запись в файл это одно, запись в расшаренную память это другое и писать полноценную реализацию как в *nix это все равно что треть ядра Linux сделать.
  • SoUrcerer
    Posts 2810
    Joined: Mon Sep 24, 2007 11:11 am

    Хм. Я тут подумал, pipelines - это вещь, в Колибри совершенно ненужная. Без нее не будет работать куча всяких консольных утилит, но они в Колибри и не нужны. Вот так. :) В конце концов, мы же не еще один клон Unix.
  • User avatar
    Freeman
    Posts 374
    Joined: Tue May 08, 2007 12:44 am

    По техническим причинам статья стала доступна только сегодня.
  • Mario

    И тут оказалось, что я кретин.
    Сильно! Самокритичность нужна в меру! Стоит заменить более мягким вариантом.
    mcall: EBX, ECX, EDX, ESI, EDI, EBP
    Ошибка, на самом деле в macros.inc

    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
}
    EBP к сожалению нет, не знаю имеет ли смысл добавлять, но в некоторых системных вызовах он используется.
    Родной компилятор для Колибри должен уметь генерить mcall
    MCALL это макрос и он не генерируется FASM'ом. Опять же смотреть macros.inc
  • User avatar
    Freeman
    Posts 374
    Joined: Tue May 08, 2007 12:44 am

    Ассемблерщики такие ассемблерщики. :-) Вот где вы видели, чтобы программист на ЯВУ писал что-то вроде:

    Code: Select all

    PutPixel(1, X, Y, Color);
    где 1 -- это код функции PutPixel? Это на ассемблере "функция 1", а на ЯВУ -- PutPixel. Поэтому и нужно именование.

    С точки зрения компилятора не важно, где что генерится. Если уж на то пошло, и 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;
    где f и s -- номера функции и подфункции, соответственно. От этого и надо плясать. Где не получается компилятор научить -- ассемблерные прослойки писать. Подозреваю, что так и делается сейчас в GCC и FPC.

    Но для дальнейшего развития ЯВУ в Колибри отрицать наличие mcall как родного типа вызова было бы глупо.
  • Mario

    Еще раз: mcall - это не вызов, вызов это прерывание int 0x40
    И раз уж пишешь именно про Колибри, то забывать или игнорировать, что первым параметром в mcal