Board.KolibriOS.org

. Приветствую всех, решил попробовать поучаствовать в жизни этого форума.
. Начну со своего личного вычислителя (персонального компьютера). Это "Pentium-3 Katmai 500" на плате "ASUS P3B" "Slot 1", жёсткий диск около 40 ГиБ (Гибибайт, 1 ГиБ равен 1024^3 байт). ОС "Windows 95 OSR2.5" и "Linux debian 6.0.10 squeeze".
. Уже пробовал выступать на других форумах, но скатывался в дно. Приведу пример (О - оппонент):
Я: фирма intel решила пустить прерывания от времямера (таймера) с частотой около 18,2 Гц. Что вообще непонятно, так как для счёта времени приходится городить дробную арифметику. И это лишь верхушка айсберга искусственных проблем "wintel".
О: на материнской плате стоит кварц 32768 Гц. Интересно, зачем он там?
Я: автономная система часов от батарейки используется только при выключенном вычислителе (компьютере). При включении "BIOS" считывает начальное время из медленной памяти автономных часов в быстрое ОЗУ и дальнейший счёт ведёт обработчик прерывания, не занимая системную шину.
О: нет, процессор не используется для счёта времени.
Я: на всякий случай написал программку для изменения частоты "IRQ0" в "DOS" - время взбесилось. В "Win95" пока не разобрался как войти в "Ring0", "Ring3" запрещает менять настройки гаваней (портов).
О: Ещё раз - часы идут не от этого таймера.
Я: в первых XT вообще не было автономных часов и пользователь сам вводил начальное время. Потом в "AT" ввели эти часы от батарейки и добавили функции "BIOS" для работы с часами. К слову, чтение занимало довольно внушительное время.
О: я не смог прочитать то, что вы написали. Да и всё равно.
. Посмотрим, что напишут здесь. Если жёсткой ругани не будет, может что и получится. Написать хочется ещё много чего, в том числе и программ.
. Просмотр СОЗУ (регистра) счётчика времямера "Win95" показал, что счёт идёт от 0 до 65.535 (сброс и прерывание по достижению), то есть те же примерно 18,2 Гц. На чтение уходит около 14 мкс - вероятно из-за вызова обработчика прерываний защищённого режима, который разрешает прочитать, но не записать СОЗУ счётчика.
.
. * * *
. Всегда не понимал, почему "Win95" занимает 70 МБ, "Win98" - от 190 МБ и так далее. Для чего нужны такие монстры, и чем они принципиально отличаются от 95? Потихоньку писал своё подобие ОС, но дальше загрузчика не продвинулся (BIOS устанавливает ЕМНИП "CS=0x0000 IP=0x7C00 SS=0x0000 SP=0x0400"). Сейчас думаю, что хорошая ОС начинается с хорошего компилятора, к сборщикам (ассемблерам) и "Си" у меня много претензий. Под "Си++" пишу вообще из-под палки (денежной). В "Си" хочу виды переменных не "char", "short int", "int", ... а "byte", "word", "dword" и другие. Ну и "int" как основной вид закладываемых в стопку (стек) данных.
. Да и англосицизм не жалую. "Реентеррабильная" фунция? А что, повторновходимая не звучит? "Кэш"? Тайник?
. По вид "int" немного ошарашен: в 64 бит системе "gcc" он 32 б ! И соглашение о передаче первых аргументов функции через СОЗУ не признаю. Не то место, где ловить быстродействие.
. "fasm" ещё не видел, собираюсь скачать, посмотреть. "TASM5": не нравится запись шестнадцатеричных чисел типа "0FFFFh", "0xFFFF" красивее, длинные вообще должны разделяться запятой, например "MOV EDX, 0x45EF,3206". Сборщик из "gcc" вообще заумный: " MOVl 8(%EBP), %EAX -> MOV EAX, [EBP+8]".
.
. * * *
. Про выполнители (процессоры). 386 (около 300 транзисторов) - шина адреса 32 или 24 бита, защищённый режим. 486 (около 1 млн транз.) - конвейер целочисленных команд, встроенный математический выполнитель. Из-за конвейера можно говорить о примитивном "CISC-RISC" преобразовании, так как для команд типа "ADD EAX, [EBX]" второй операнд загружается во временное СОЗУ перед исполнением. "Pentium P54" (3,3 млн. транзисторов) - два целочисленных конвейера, один дробночисленный. "Pentium-MMX" (4,5 млн транз.) - дополнительный блок "MMX" целочисленной арифметики в том числе с насыщением (сатурацией). [ 386 около 300 тыс. транз. - опечатка ] "Pentium-2" (7,5 млн транз.) - переделка из "Pentium-Pro" с полным RISC-ядром, переименованием СОЗУ (в книгах пишут, что 16 СОЗУ - 8 целочисленных и 8 дробночисленных отображается на 40 универсальных), внеочередным исполнением и так далее. По "википедии" требовал загрузку микрокода и содержал около 100 ошибок. Часть ошибок обходилась микросборками системной платы, часть - водителями устройств и ОС, оставшаяся часть не проявлялась в большинстве программ. Быстродействие на оптимизированных программах практически не выросло, если не считать быстрого тайника 2 уровня на отдельной высокоскоростной шине. Матем. выполнитель так и остался стопочной архитектуры с ущербным распараллеливанием команд. Пример: "Pentium-2" 450 МГц 490 "MFLOPS", "Sony PlayStation2" (10 мнл. транз.), 300 МГц: 6400 "MFLOPS". Далее вышел "Pentium-3" "SSE" (9 млн транз.) с повышением быстродействия по 32 бит дробным числам на 60% и с новыми ошибками. Про "Pentium 4" вообще лучше промолчать... И верить в легенду, что когда-нибудь выйдет "P55C" по современному "techprocess" с тактовой 1 ГГц, "DDR"-шиной и дробночисленными "SIMD". Для него разработают набор микросборок "440BX2" с поддержкой "ISA"-шины, "Serial ATA", "PCI-express", "USB2.0' и т. д.
. Я использую "Pentium-3" потому, что 233 МГц "Pentium-MMX" на шине 66 МГц не успевает на лету сжимать кино с магнитофона в "704x576" "MJPEG". На "MMX" бывает играю изредка. За 20 лет на нём сгорел линейный стабилизатор напряжения 2,8 В на плате - пришлось поставить в режим 3,3 В и поменять выполнитель на "P54C" 133 МГц.
.
. Вопрос разработчикам
. Считаю, что для ОС нужен "Си"-подобный компилятор. На сборщике (ассемблере) писать большие программы затруднительно. На "Си" программы будут занимать ненамного больше места. Мне на текущий момент больше нравиться пара "Си"-сборщик. По "Си"-подобному компилятору несколько предложений: виды переменных "byte" (8 бит), "word" (16 бит), "dword" (32 бит), "qword" - относительно знаменитого 8086 , "int" - равен размеру слова в стопке. Никаких автооптимизаций - только с приставкой "register" переменные попадают в СОЗУ. Если не попадают - пишем что-то вроде "Warning: variable declared as register placement in RAM". Передача аргументов - только через стопку. Поддержка встраиваемых функций.
. Готов поучаствовать в разработке компилятора. Начать нужно со списка ключевых слов:
void
byte, word, dword, qword
signed, unsigned
float, dfloat
for, while, do, switch, case
break, continue, default
if, else
register, inline
public - вместо static
typedef
volatile
sizeof
assembler
. При компиляции должна создаваться таблица с именами и смещениями переменных и функций. Смещения переменным назначаются в порядке прохода - как в объединении (структуре). Если выравнивание неправильное - пишем предупреждение.
. Компиляция должна переводить "Си"-код в код сборщика. Всё, что в фигурных скобках после слова "assembler" должно проходить в выходной файл без изменений. Символ подчёркивания в имена общих функций и переменных добавлять не нужно.
. Собственно вопрос: использование "Си"-компилятора не противоречит вашей идее?

Я не понял часть вопросов и рассуждений, а касательно С с ассемблер подобным отношением к памяти у нас есть С--. Использование С и других похожих языков в место ассемблера в разработке ЯДРА не соответствует проекту. Ведь на Ассемблер завязано множество ключевых особенностей проекта как минимальные расходы максимум эффективности которые на других языках получить ещё сложнее.

Vaicheslav97 wrote:Ведь на Ассемблер завязано множество ключевых особенностей проекта как минимальные расходы максимум эффективности которые на других языках получить ещё сложнее.

Неиспользование нормального аллокатора во многих (как правило асмовых) приложениях- максимум эффективности)) ну я про 68.12 в качестве malloc. На каждый чих минимум 4кб дает.

rgimad wrote:

Vaicheslav97 wrote:Ведь на Ассемблер завязано множество ключевых особенностей проекта как минимальные расходы максимум эффективности которые на других языках получить ещё сложнее.

Неиспользование нормального аллокатора во многих (как правило асмовых) приложениях- максимум эффективности)) ну я про 68.12 в качестве malloc. На каждый чих минимум 4кб дает.

это ещё не самая большая проблема, некоторые программы даже не используют этот аллокатор, а работают через 64 сисфункцию или вообще память не выделяют динамически, а статически задают область памяти на мегабайт например

Vaicheslav97 wrote:Я не понял часть вопросов и рассуждений.

. Это очень хорошо. Я их и сам не понял. Прошу прощения, что влез на ресурс профессионалов со своими дилетантскими проблемами.

могу ответить только по нумеруемым и то не уверен что полностью
1)Разделение на кольца у нас есть но ограничения по портам ввода вывода слабые
2)Ограничения портов ввода вывода у нас такие чтобы в случае если надо приложение могло само могло быть как драйвер в случае если оно работает ну с очень специфичным железом
3)Обработка прерываний есть, когда программы выходит за рамки разрешенной памяти ОС её принудительно закрывает, общие области памяти есть, разделения есть но код не разделяется на модифицируемый или нет.
4)Наша ОС много задачная и поддерживает это распределяя нагрузку между приложениями даже если одно повиснет то это не повесит остальные приложения
5)Я не знаю где находится видеобуфер но поддерживаем стандарты (S)VGA
6)Переключение контекста у нас есть и реализована в рамках многозадачности
7)Файл подкачки отсутствует, по причине что он приводит к общему замедлению системы даже без нагрузки и даёт призрачный шанс пользоваться приложениями на которые не хватает памяти, у нас пока в обозримом будущем нет приложений которым могло бы понадобится 128Мб и выше кроме разве что виртуального диска когда Оперативка выделяется как раздел жесткого диска
8)Не знаю точно но вроде есть.
9)Пока что оконный менеджер вшит в ядро но вроде идут попытки его отделить

rgimad wrote:

Vaicheslav97 wrote:Ведь на Ассемблер завязано множество ключевых особенностей проекта как минимальные расходы максимум эффективности которые на других языках получить ещё сложнее.

Неиспользование нормального аллокатора во многих (как правило асмовых) приложениях- максимум эффективности)) ну я про 68.12 в качестве malloc. На каждый чих минимум 4кб дает.

1) приличные асмовые приложения должны это знать и учитывать.
во избежание неэффективности.

2) в Линуксе kalloc() тоже нарезает драйверам дин.память целыми страницами.
даже если нужно меньше.

3) ядро вообще не обязано заниматься динамической кучей приложений.
в ЯВУ это забота компиляторов.

Проще сказать, что на системном уровне память всегда выделяется страницами по 4 кб, и все ОС её так выдают. Более мелкая нарезка происходит на пользовательском уровне; а в библиотеке или в самом приложении — это уже не принципиально. Может даже лучше чтоб программист понимал, что при не правильном обращении к памяти в пределах 4 кб системной ошибки не будет.

* * *

Но крутые как считали лошарой, так и будут считать, поэтому умолкаю.

5)Я не знаю где находится видеобуфер но поддерживаем стандарты (S)VGA

В документации ( http://wiki.kolibrios.org/wiki/SysFn61/ru ) написано:
Программе доступны данные графического экрана (область памяти, которая собственно и отображает содержимое экрана) напрямую без вызовов системных функций через селектор gs: В файле исходников ядра core/mtrr.inc написано (строка 898): В файле const.inc определено (строка 279): Насколько понимаю , физический адрес получается от BIOS (с некоторой настройкой)
, возможно его изменяет специализированный драйвер видео карты (таковые имеются ...)
а затем отображается на виртуальный LFB_BASE = 0xFE000000 , который доступен для записи в том числе и
в ring3 - пользовательском режиме (лично мне такая беспечность непонятна : нормальный пользователь при "невменяемом" экране решить проблему может только кнопкой RESET)

Номера строк, естественно, примерные, ибо файл может быть изменён в процессе разработки

P.S.
Вы собираетесь разрабатывать что-то новое для 8086, 80386 real mode. 80386 protected mode .
А вас в стране наверное налажено производство аналогов этих процессоров по цене чуть большей avr для Arduino ...
А вот с процессорами amd64 напряжёнка ... Тогда всё встаёт на свои места ...
В моей стране : avr - нет проблем. arm - тоже нет проблем, amd64 - тем более нет проблем, mips вроде как можно найти под вывеской avr32, но на чипсете с возможностями Arduino (а хотелось бы - с чипсетом Raspberri Pi). Насчёт ia32 без amd64, как раз наблюдая
за Kolibri OS , понял, что вроде как в Китае можно заказать (но по цене, за которую я могу подержанный системный блок amd64 приобрести).
Боюсь, что следующий логичный шаг после введения UEFI будет новая линейка процессоров, у которых ничего, кроме amd64 long mode , просто нет - на таких компьютерах Kolibri OS уже не запустишь в принципе (даже если оставят amd64 compatability mode)

* * *

user123 wrote: ↑Sun Jul 31, 2022 11:51 am На "ATmega328/ATtiny4313" пишу ради денег в громоздкой "AVR Studio" под "Windows XP/7/10". "С++" туда же. Компилятор попытаюсь начать на своём оборудовании и под него.

Не думали рассмотреть разработку ПО для МК (разных и AVR) на Форт (Forth) языке?
Для AVR, к примеру,
1. amForth
2. Форт-ассемблер для AVR
3. AVRForth
4. FlashForth
...
P.S. Для других/разных МК/ тоже достаточно сделано инструментария для разработки ПО в рамках Форт системы.

Форт также легко расширить до понимания других языков
uBasic for 4th
CC64 is a small-C compiler, written in Forth (here's why), targeting the 6502 CPU.
...
Разместить FORTH в 512 байтах

Ин дзис пост были рекордсы о плаг-энд-плэй. Но кому интересны проблемы Plug and Play ин тзис тайм? В наше время есть более модерные технологии от крутейших корпораций.

user123 wrote: ↑Tue Aug 02, 2022 12:21 pm . Изучаю, разбираюсь, материал про язык-4 незнакомый, даже не знаю полезно ли... оценить пока не могу.

Начать можно с прочтения таких книг.
С.Н.БАРАНОВ Н.Р. НОЗДРУНОВ ЯЗЫК ФОРТ И ЕГО РЕАЛИЗАЦИИ
Л.Броуди "Начальный курс программирования на языке Форт"
ЛЕО БРОУДИ СПОСОБ МЫШЛЕНИЯ - ФОРТ ЯЗЫК И ФИЛОСОФИЯ ДЛЯ РЕШЕНИЯ ЗАДАЧ
...
FORTH (Computer+program+language)

Сейчас популярен в реализации база стандарта Forth-94.


P.S. http://fforum.winglion.ru/ рускоязычная площадка пользователей Форт языка.

На Github много проектов отображается при вводе слова Forth в поисковом запросе.