Board.KolibriOS.org

Official KolibriOS board
It is currently Tue May 21, 2019 2:39 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 43 posts ]  Go to page Previous 1 2 3 Next
Author Message
 Post subject: Re: BASIC
PostPosted: Sun Sep 25, 2011 7:09 pm 
Offline
User avatar

Joined: Tue May 08, 2007 12:44 am
Posts: 346
А, ну да. Вчера настолько заинтересовался сайтом автора, что пропустил модификацию для Колибри.

Сейчас скачал, но не понял, где там Колибри. Я понимаю, что поддержка Колибри может и должна быть добавлена как полноценная платформа, пусть даже и с кросс-компиляцией из-под Windows и/или Linux.

Завтра заработает хостинг, и в моём блоге станет доступна статья с описанием двух принципиальных, на мой взгляд, проблем портирования ЯВУ в Колибри.

_________________
Разработчик языка программирования Кантор


Last edited by Freeman on Fri Sep 30, 2011 8:14 pm, edited 3 times in total.

Top
   
 Post subject: Re: BASIC
PostPosted: Sun Sep 25, 2011 7:24 pm 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
В Колибри нет pipes. Это единственное, что затрудняет портирование приложений - лично для меня.


Top
   
 Post subject: Re: BASIC
PostPosted: Sun Sep 25, 2011 7:47 pm 
Offline
User avatar

Joined: Thu Mar 01, 2007 4:16 pm
Posts: 426
> написаны на Паскале, что практически сводит на нет возможность их портирования
> я не думаю, что это безумно сложная задача
Портировать FPC просто. Была бы ещё адекватная консоль.
Надеюсь получится в следующем году вернуться к этому вопросы, а то я как забросил это дело, больше никто им и не занимался.

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

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

..bw


Top
   
 Post subject: Re: BASIC
PostPosted: Sun Sep 25, 2011 7:56 pm 
SoUrcerer wrote:
В Колибри нет pipes. Это единственное, что затрудняет портирование приложений - лично для меня.

Может я чего-то не знаю о pipe, но вот:
Spoiler: Show
Quote:
======================================================================
=== Функция 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 разрушается
Замечания:
* Область памяти физически освобождается (с забыванием всех данных
и высвобождением физической памяти), когда её закроют
все открывшие потоки.
* При завершении потока освобождаются все открытые им
области памяти.


Top
   
 Post subject: Re: BASIC
PostPosted: Sun Sep 25, 2011 7:59 pm 
Offline

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

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


Top
   
PostPosted: Sun Sep 25, 2011 8:11 pm 
Чего же тут такого хитрого? В расшаренной памяти можно организовать что-то вроде кольцевого буфера, а в самом начале будет служебная область, которая будет содержать всякие указатели. К примеру OpenDialog именно так и реализован. Указатель на именованную область передается в виде параметра, при запуске приложения. Единственный минус, я не стал пользоваться старой функцией IPC и для OpenDialog просто реализован периодический опрос мьютекса, что в его случае не является таким уж большим недостатком. Мне так кажется реализовать pipe на основе именованной расшаренной памяти и IPC мешает исключительно лень (лень разбираться с реализацией), а работать такое будет нисколько не хуже.


Top
   
PostPosted: Sun Sep 25, 2011 8:17 pm 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
В моей ламерской голове такое не укладывается. Если такой механизм будет реализован, это будет нереально круто. Потом будет сделать межпроцессное взаимодействие - элементарно, и CGI - тоже.


Top
   
PostPosted: Sun Sep 25, 2011 8:23 pm 
Еще бы найти толковое описание как реализован тот pipe, который нужен именно тебе (и желательно на русском), а то я как почитал в *nix одно обозначает в win лругое.


Top
   
PostPosted: Sun Sep 25, 2011 8:29 pm 
Offline

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


Top
   
PostPosted: Sun Sep 25, 2011 8:36 pm 
Хм... по таким куцым сведениям сделать что-то нереально и я так и не понял что конкретно требуется тебе. Просто в *nix сама концепция изначально все рассматривать в виде файлов (именно по этому кстати падает производительность на некоторых участках - слишком большая величина абстракции), в Колибри естественно такое не проканает - запись в файл это одно, запись в расшаренную память это другое и писать полноценную реализацию как в *nix это все равно что треть ядра Linux сделать.


Top
   
PostPosted: Sun Sep 25, 2011 8:43 pm 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
Хм. Я тут подумал, pipelines - это вещь, в Колибри совершенно ненужная. Без нее не будет работать куча всяких консольных утилит, но они в Колибри и не нужны. Вот так. :) В конце концов, мы же не еще один клон Unix.


Top
   
PostPosted: Fri Sep 30, 2011 8:22 pm 
Offline
User avatar

Joined: Tue May 08, 2007 12:44 am
Posts: 346
По техническим причинам статья стала доступна только сегодня.

_________________
Разработчик языка программирования Кантор


Top
   
PostPosted: Fri Sep 30, 2011 8:41 pm 
Quote:
И тут оказалось, что я кретин.

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

Ошибка, на самом деле в macros.inc
Code:
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 к сожалению нет, не знаю имеет ли смысл добавлять, но в некоторых системных вызовах он используется.
Quote:
Родной компилятор для Колибри должен уметь генерить mcall

MCALL это макрос и он не генерируется FASM'ом. Опять же смотреть macros.inc


Top
   
PostPosted: Fri Sep 30, 2011 10:17 pm 
Offline
User avatar

Joined: Tue May 08, 2007 12:44 am
Posts: 346
Ассемблерщики такие ассемблерщики. :-) Вот где вы видели, чтобы программист на ЯВУ писал что-то вроде:
Code:
PutPixel(1, X, Y, Color);

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

С точки зрения компилятора не важно, где что генерится. Если уж на то пошло, и stdcall, и cdecl, и fastcall можно генерить макросом. В Колибри именно что сложился свой тип вызова, с точки зрения ЯВУ выглядящий как импорт по номеру и порядок регистров, как я указал. Импорт по номеру не является из ряда вон выходящим -- где-то в Windows функции OLE32.dll, кажется, импортируются тоже по номеру.

Собственно, есть две вариации mcall:
Code:
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 как родного типа вызова было бы глупо.

_________________
Разработчик языка программирования Кантор


Top
   
PostPosted: Fri Sep 30, 2011 10:28 pm 
Еще раз: mcall - это не вызов, вызов это прерывание int 0x40
И раз уж пишешь именно про Колибри, то забывать или игнорировать, что первым параметром в mcall идет именно EAX - мне это кажется весьма странным поведением.
Все мои замечания касались именно ассемблерной части, которую ты вольно так употребляешь.
Если ты подразумевал mcall который не для ассемблера, то стоит это явно обозначить, иначе фигня какая-то получается - без обид.

Quote:
Как это должно выглядеть в Колибри? Во-первых, в ней, как и в любой другой уважающей себя ОС, есть свой тип вызова — mcall. В разговоре с dunkaist-ом я пытался всё назвать его kcall или kocall, но сейчас, глядя в исходники, вспомнил, что тут Колибри хранит традиции, тем более, что сам формат вызова не изменился: ¶
Code:
mcall: EBX, ECX, EDX, ESI, EDI, EBP

EAX используется для передачи номера функции и возврата результата, а EBX — передачи номера подфункции, если есть. Для программиста ЯВУ выглядит странно, но на ассемблере — вполне даже.

Вот в этой части ты ведь говоришь именно об ассемблере, никак не об формате для ЯВУ и почему-то в приведенной как код структуре опущен EAX, но присутствует EBP.
Может я такой весь из себя странный ассемблерщик, но по моей логике никак такое не укладывается.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 43 posts ]  Go to page Previous 1 2 3 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited