- ничего не тестировалось и если что-то есть, то это не значит что оно работает, классика;
- нельзя создавать динамические библиотеки;
- нельзя загружать динамические библиотеки;
- при сборке KEX-а не инициализированные секции заливаются нулями, как и "дыры" между секциями;
- есть обработка параметров командной строки;
- стандартный вывод (и ошибки) происходит на отладочную доску (sysfn 63.1);
- стандартный ввод осуществялется с отладочной доски (sysfn 63.2);
- есть многопоточность (см. первый пункт):
- размер стека 256KB;
- есть в KOS (sysfn 69.4/5), но не реализовано в RTL suspend/resume потока;
- есть threadvar/tls (см. первый пункт);
- EndThread отсутствует, есть только KillThread, который будет приводить к утечкам памяти (вероятно) и
блокировкам конкурирующих потоков (возможно); - EnterCriticalSection есть, но сделан на тупом цикле (не нашёл в системе mutex-ов);
- есть исключения (см. первый пункт);
- стек фиксировнного размера (скорее всего);
- аппаратные прерывания не обрабатываются, например FPU (sysfn 68.1);
- и т.д.
FreePascal
-
Не сделано, сделано на отъебись и другие особенности:
Реализуются через фьютексы.bw wrote:не нашёл в системе mutex-ов
Я нашёл эти futex-ы в sysfn77, но не понял, разве их суть как раз не состоит в том, что бы не обращаться лишний раз к ядру? Если один хрен каждый раз дёргать ядро, то почему было не сделать нормальные примитивы синхронизации.
p.s. Или этот код в user-space выполняется?
p.s. Или этот код в user-space выполняется?
Так и есть. У реализация мутекса поверх футекса удачная блокировка будет делаться без дёргания ядра, например. Тут тебе атомические операции в помощь.bw wrote:разве их суть как раз не состоит в том, что бы не обращаться лишний раз к ядру?
Другие примитивы синхронизации так же эффективно делаются поверх него, поэтому нет смысла делать библеотечные функции в ядре.
Я и сам где-то месяц назад делал мутексы на Обероне для Колибри, ничего сложного. Код, правда, позже выкинул за ненадобностью.
Здравствуйте, можно ли подключить console.obj к порту FreePascal под кос? может это можно как-нибудь через асм вставки сделать.
По компилятору: можно ли использовать вместо ogcoff.pas ogelf.pas или использовать ogbase.pas и owbase.pas напрямую?
По RTL: там представлены не все функции, например нет функций 74, 75, 76, и некоторых подфункций, например подфункции 18, 19 функции 68
По компилятору: можно ли использовать вместо ogcoff.pas ogelf.pas или использовать ogbase.pas и owbase.pas напрямую?
По RTL: там представлены не все функции, например нет функций 74, 75, 76, и некоторых подфункций, например подфункции 18, 19 функции 68
Попытался сделать модуль для работы с сисфункцией 75, насколько это работает не знаю
- Attachments
-
-
test_sockets.pp (3.94 KiB)Downloaded 276 times
-
- Для ELF в FPC нужен внешний линковщик, неоправданный геморой, я считаю, таскать с собой link.kex, который ещё нужно как-то собрать.
- Что бы не использовать ogcoff, нужно разобраться как он работает и переписать реализованную в нём логику, я не буду этим заниматься.
- Да, многие системные функции не были реализованы.
Last edited by bw on Sun Jan 31, 2021 8:08 pm, edited 2 times in total.
а при реализации загрузки длл (сисфункция 68, подфункция 19) можно реализовать модуль консоли(подключить console.obj)?
и было бы неплохо сделать вывод ошибок компиляции
и было бы неплохо сделать вывод ошибок компиляции
Можно всё что угодно, но я не планирую в ближайшее время возвращаться к этому проекту, сорян :-(.
О каком выводе речь? Стандартный вывод в KolibriOS осуществляется на отладочную доску. Если запустить ppc386.kex, то ошибки (и не ошибки) будут выведены туда.
..bw
О каком выводе речь? Стандартный вывод в KolibriOS осуществляется на отладочную доску. Если запустить ppc386.kex, то ошибки (и не ошибки) будут выведены туда.
..bw
Last edited by bw on Sun Jan 31, 2021 8:08 pm, edited 1 time in total.
да я забыл про отладочную доску
У меня где-то была тупенькая реализация Crt, можно попробовать её воскресить. Но она отсасывает, конечно, у современного console.obj и они обе не годятся для fpc-шного toolchain-а. Вроде console.obj как-то приспособили для работы с несколькими приложениями (а нужно именно это, так как make -> fpc -> fpc386 и т.д. и все они изрыгают текст), но что-то мне там не понравилось. А ещё нужны переменные окружения. И ещё овердохрена вещей окажется не сделанным, так что за пару вечеров сделать нормальный toolchain не получится.
..bw
..bw
в ogcoff.pas дофига кокстант которые вообще непонятны, многое в кос даже не пригодится(например читалка длл), может проще посмотреть что возвращают функции ogbase.pas с owbase.pas ,а такие моменты как загрузка .obj бибиотек реализовать в ртл или юнитах, бин код исполняемого файла кос же не очень сложено устроен
а что вообще возвращают функции модулей ogbase и owbase ?
а что вообще возвращают функции модулей ogbase и owbase ?
Вопрос: а в RTL есть функция для работы с буфером?
- Я больше ничего не могу сказать про компилятор, в ЛС я писал, что времени ему было уделено настолько мало насколько это возможно.
- Что за буфер? Если буфер обмена, то нет. Сейчас проще самому посмотреть (kosh.inc), чем меня спрашивать. RTL я делал в 2007 году.
я сейчас пытаюсь реализовать функции работы с сетью, если что-то получится, то скину сюда
Who is online
Users browsing this forum: No registered users and 0 guests