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

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

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

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

    ..bw
  • 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 разрушается
    Замечания:
    * Область памяти физически освобождается (с забыванием всех данных
    и высвобождением физической памяти), когда её закроют
    все открывшие потоки.
    * При завершении потока освобождаются все открытые им
    области памяти.
  • bw, я буду ждать с нетерпением. Такие интересные люди, как ты, в проекте на пересчет. Среди моих знакомых Free Pascal в Колибри будет очень востребован. По крайней мере, в той школе, где моя мама работает учителем информатики.
    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 - это понятия, виртуальные для Колибри, как я понимаю.
  • Хм... по таким куцым сведениям сделать что-то нереально и я так и не понял что конкретно требуется тебе. Просто в *nix сама концепция изначально все рассматривать в виде файлов (именно по этому кстати падает производительность на некоторых участках - слишком большая величина абстракции), в Колибри естественно такое не проканает - запись в файл это одно, запись в расшаренную память это другое и писать полноценную реализацию как в *nix это все равно что треть ядра Linux сделать.
  • Хм. Я тут подумал, pipelines - это вещь, в Колибри совершенно ненужная. Без нее не будет работать куча всяких консольных утилит, но они в Колибри и не нужны. Вот так. :) В конце концов, мы же не еще один клон Unix.
  • По техническим причинам статья стала доступна только сегодня.
  • И тут оказалось, что я кретин.
    Сильно! Самокритичность нужна в меру! Стоит заменить более мягким вариантом.
    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
  • Ассемблерщики такие ассемблерщики. :-) Вот где вы видели, чтобы программист на ЯВУ писал что-то вроде:

    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 как родного типа вызова было бы глупо.
  • Еще раз: mcall - это не вызов, вызов это прерывание int 0x40
    И раз уж пишешь именно про Колибри, то забывать или игнорировать, что первым параметром в mcall идет именно EAX - мне это кажется весьма странным поведением.
    Все мои замечания касались именно ассемблерной части, которую ты вольно так употребляешь.
    Если ты подразумевал mcall который не для ассемблера, то стоит это явно обозначить, иначе фигня какая-то получается - без обид.
    Как это должно выглядеть в Колибри? Во-первых, в ней, как и в любой другой уважающей себя ОС, есть свой тип вызова — mcall. В разговоре с dunkaist-ом я пытался всё назвать его kcall или kocall, но сейчас, глядя в исходники, вспомнил, что тут Колибри хранит традиции, тем более, что сам формат вызова не изменился: ¶

    Code: Select all

    mcall: EBX, ECX, EDX, ESI, EDI, EBP
    EAX используется для передачи номера функции и возврата результата, а EBX — передачи номера подфункции, если есть. Для программиста ЯВУ выглядит странно, но на ассемблере — вполне даже.
    Вот в этой части ты ведь говоришь именно об ассемблере, никак не об формате для ЯВУ и почему-то в приведенной как код структуре опущен EAX, но присутствует EBP.
    Может я такой весь из себя странный ассемблерщик, но по моей логике никак такое не укладывается.
  • Who is online

    Users browsing this forum: No registered users and 5 guests