Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Вт ноя 21, 2017 4:32 pm

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 43 сообщения ]  На страницу Пред. 1 2 3 След.
Автор Сообщение
 Заголовок сообщения: Re: BASIC
СообщениеДобавлено: Вс сен 25, 2011 7:09 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Вт май 08, 2007 12:44 am
Сообщения: 340
А, ну да. Вчера настолько заинтересовался сайтом автора, что пропустил модификацию для Колибри.

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

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

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


Последний раз редактировалось Freeman Пт сен 30, 2011 8:14 pm, всего редактировалось 3 раза.

Вернуться к началу
 Заголовок сообщения: Re: BASIC
СообщениеДобавлено: Вс сен 25, 2011 7:24 pm 
Не в сети

Зарегистрирован: Пн сен 24, 2007 11:11 am
Сообщения: 2814
В Колибри нет pipes. Это единственное, что затрудняет портирование приложений - лично для меня.


Вернуться к началу
 Заголовок сообщения: Re: BASIC
СообщениеДобавлено: Вс сен 25, 2011 7:47 pm 
Не в сети
Аватара пользователя

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

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

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

..bw


Вернуться к началу
 Заголовок сообщения: Re: BASIC
СообщениеДобавлено: Вс сен 25, 2011 7:56 pm 
SoUrcerer писал(а):
В Колибри нет pipes. Это единственное, что затрудняет портирование приложений - лично для меня.

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


Вернуться к началу
   
 Заголовок сообщения: Re: BASIC
СообщениеДобавлено: Вс сен 25, 2011 7:59 pm 
Не в сети

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

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


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


Вернуться к началу
   
СообщениеДобавлено: Вс сен 25, 2011 8:17 pm 
Не в сети

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


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


Вернуться к началу
   
СообщениеДобавлено: Вс сен 25, 2011 8:29 pm 
Не в сети

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


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


Вернуться к началу
   
СообщениеДобавлено: Вс сен 25, 2011 8:43 pm 
Не в сети

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


Вернуться к началу
СообщениеДобавлено: Пт сен 30, 2011 8:22 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Вт май 08, 2007 12:44 am
Сообщения: 340
По техническим причинам статья стала доступна только сегодня.

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


Вернуться к началу
СообщениеДобавлено: Пт сен 30, 2011 8:41 pm 
Цитата:
И тут оказалось, что я кретин.

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

Ошибка, на самом деле в macros.inc
Код:
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


Вернуться к началу
   
СообщениеДобавлено: Пт сен 30, 2011 10:17 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Вт май 08, 2007 12:44 am
Сообщения: 340
Ассемблерщики такие ассемблерщики. :-) Вот где вы видели, чтобы программист на ЯВУ писал что-то вроде:
Код:
PutPixel(1, X, Y, Color);

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

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

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

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


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

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

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

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


Вернуться к началу
   
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 43 сообщения ]  На страницу Пред. 1 2 3 След.

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 2 гостя


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB