Board.KolibriOS.org

Я добавил в бранч kolibri-acpi определение числа процессоров - переменная [cpu_count] и запуск одного ядра - функция start_ap. Каждому процессору присваивается номер начиная с нуля для загрузочного. В таблице smpt сохраняется apic id процессора под номером N. Всего таблица рассчитана на 16 процессоров.
start_ap запускает процессор N и переводит в режим ядра. После чего процессор в цикле рисует квадрат размером 32х32 пикселя с координатами х= cpu_apic_id*64, y=0. Теперь пытливые Самоделкины могут использовать эти ядра по своему усмотрению.

Поддерживается:
ASUS M3N78-VM (Athlon 64 X2, 2 ядра) - система стартует и показывает серый квадрат в левом верхнем углу, не зависает.
Dell Inspiron (Intel i5, 2 ядра + хипертридинг итого 4 виртуальных) - система стартует и показывает серый квадрат в левом верхнем углу, не зависает.
ASRock M3A770DE (Athlon-II 64 X2, 2 ядра) - система стартует и показывает серый квадрат в левом верхнем углу, не зависает.

Не поддерживается.
Roverbook U800 (AMD Geode LX800) - система стартует, но естественно никакого квадрата, т.к. ядро одно, не зависает.
eBox-3300MX (Vortex86MX) - система стартует, но естественно никакого квадрата, т.к. ядро одно, не зависает.

В качестве предложения - кроме серого квадрата писать хотя бы одну цифру, сколько ядер обнаружено.

Добавил вывод числа CPU на доску отладки.
Перенесу код с определением числа CPU в транк.

А как он будет работать? При загрузке будет рисование пингвинов выводиться в лог на черном фоне?

Перенёс в транк. Данные выводятся на доску отладки.
Число процессоров определяется по таблицам ACPI. Если ACPI нет, то cpu_count равно 0, но на доске будет "1 CPU detected", чтобы не смущать народ.

Вау, круто. А можно как-нибудь эти ядра нагрузить из клиентских приложений? Или планировщику поручить на них часть задач скидывать?

Боюсь, что придется все собственными ручками в ядре делать.

З.Ы. CPU not found - это старая хохма.

Все нормально: на i5 определилось 4 ядра, на Athlon 64 x2 определилось 2 ядра.

Сделаю ещё определение топологии, чтобы различать логические ядра и физические.

Можно выводить ещё на чёрном фоне во время загрузки... вместе с частотой процессора.

Загрузочный лог на черном фоне полезен лишь при зависании, а там знать сколько у тебя ядер не очень важно.

Проц i3-330m определяет 4 ядра, на самом деле 2 физических, 4 потока.

Serge
Однако теперь надо начинать серьезно продумывать формат исполняемых файлов для Колибри-64,
адресную модель для второго ядра,
API-64,
и еще протокол межпроцессорных сообщений.

Кстати, свет ведь клином на 64 битах не сошелся. Кто-то может захотеть использовать "вторые" ядра как API-ускорители, а кому-то надо будет засунуть туда одно монопольное RT-приложение.

art_zh
Я могу набросать общий код инициализации, но особенно сильно лезть в это дело пока не буду. Смысла в приложениях без полноценного доступа к сервисам системы не много. Как и писал раньше все это больше "Сделай Сам".

Хотя никаких неразрешимых проблем с исполнением 64-х битных программ в Колибри нет. Главное чтобы все указатели передаваемые ядру лежали ниже 2Gb. Каждый процесс создаётся как обычная программа Колибри. У процесса есть триггер kernеl-mode/user-mode. В user-mode процесс помечен как спящий и не планируется на 32-х битном ядре. В режиме ядра наоборот. Соответственно при смене режимов происходит миграция процесса с одного ядра на другое. Фактически это работает как IPC в микроядерной системе, только передаётся не сообщение, а весь процесс.

Похожим образом и smp организуется. Глобальная блокировка на входе в ядро, так что только один процессор в режиме ядра. Так FreeBSD работала.

Nice work,
I can debug on a quad-core i7 (8 threads) and an old dual Pentium III server, if it is of any use?