Алан Кокс представил Unix-подобную ОС Fuzix, ядро которой потребляет около 40 Кб ОЗУ

Алан Кокс представил Unix-подобную ОС Fuzix, ядро которой потребляет около 40 Кб ОЗУ

Алан Кокс (Alan Cox), известный разработчик ядра Linux, удостоенный в 2003 году престижной премии Free Software Awards за вклад в разработку ядра, в свое время основавший компанию Etched Pixels Digital Design, занимающуюся выпуском моделей поездов, представил проект Fuzix по созданию новой Unix-подобной минималистичной операционной системы. Целевой аудиторией нового проекта являются разработчики, которые устали от обилия усложнений, неуклонного роста размеров и требований современного ПО, и с тоской вспоминают о старых былых временах, когда каждый по имени знал коллег по сообществу, вся работа могла уместиться на дискету и главным мотивом было получение удовольствия от создания чего-то нового.

Целью Fuzix OS является возрождение принципа "just for fun" и создание достаточно полной реализации System 5 Unix, потребляющей минимальный объём ресурсов. В текущем виде ядро новой ОС потребляет всего 40 Кб ОЗУ и поддерживает работу на процессорах на базе архитектуры Zilog Z80. Система может быть запущена на широком спектре систем, основанных на клонах и вариантах Z80, в том числе на платах с T80 FPGA. При этом система изначально рассчитана на обеспечение переносимости, например, в коде уже обеспечена базовая поддержка 8-разрядных процессоров Motorola 6809 и MOS 6502, что теоретически позволяет запустить ОС и для этих систем.

Порт для процессоров Intel 8086 пока отсутствует, но его создание является делом времени, так как основная проблема заключается в отсутствии пригодного к использованию открытого ANSI C компилятора для CPU 8086 (предприняты попытки задействовать pcc). Процессор Z80 выбран в качестве начальной основы их-за того, что несмотря на обилие для данного CPU различных операционных систем, среди них до сих пор отсутствует полноценно переносимая ОС, способная работать на других типах процессоров. Как и ядро Linux, код новой ОС распространяется под лицензией GPLv2.

Код Fuzix скомпонован из элементов, собранных из разных форков операционной системы UZI и объединённых в единую платфору, расширенную поддержкой Unix-технологий и POSIX. По сравнению с UZI добавлена расширенная поддержка мультипроцессности, появилась возможность использования раздела подкачки, переработан код управления памятью, расширен допустимый размер имён файлов, добавлена поддержка сигналов System 5, Posix termios, архитектура переработана для простого переноса на новые типы процессоров без создания отдельных форков, API расширен вызовами open с 3 аргументами, mkdir, rmdir, rename, chroot, fchdir, fchmod, fchown, fstat, fcntl, setpgrp, sighold and friends, waitpid, setpgrp, nice O_NDELAY, O_CLOEXEC, F_SETFL, F_DUPFD.

Из планов на будущее отмечается поддержка TCP/IP-стека, ptrace, core-дампов, ulimit, uptime, резервирования блоков на диске для пользователя root, вызовов select/poll(), /dev/tty, файловых систем размером более 32 Мб, нового планировщика задач, символических ссылок, загружаемых драйверов, оптимизации подсистемы работы с блочными устройствами, портирование эмулятора CP/M.

Источник

Вау. sdcc, makefiles и платформо-зависимый код, отделенный от основного. За одно это уже можно памятник ставить, учитывая, что из себя представляли исходники UZI.

Дождались таки нормальной ОС, а не командер. :)

Цитата:

---

Сообщение от BlastOff

Дождались таки нормальной ОС, а не командер. :)

---

К сожалению, на стандартной архитектуре не взлетит:

Код:

---

                  First 64k              Subsequent 64k banks
        FFFF        +------------+                +------------+
    Common        |  Common  |                | Task Store |+
        F000        +------------+                +------------+|+
                |            |                |            |+|+
                |  Kernel  |                |  Process  ||+|
    Banked        |    Code    |                |    Code    |||+
                |            |                |  & Data  ||||
                |            |                |            ||||
        0100        +------------+                +------------+|||
                |  Reserved  |                |  Reserved  |+||
        0000        +------------+                +------------+|+|
                                        +------------+|+
                                          +------------+|

---

Цитата:

---

Сообщение от CityAceE

К сожалению, на стандартной архитектуре не взлетит

---

На стандартной архитектуре и смысла нет. А вот на эве/спекки2010... Сам Алан разрабатывает под 128-мегагерцовый комп на T80, так что мало надежд на комфортную работу на 3.5.

На чем это работает? x86, arm? как же 68к :)

в редми вижу 6502 :)

Цитата:

---

Сообщение от DJs3000

На чем это работает?

---

Разрабатывалось для Z80, но с учётом переносимости на другие архитектуры.

Проблемы адаптации судя по z80pack те же что и у CP/M. Значит это можно как-нибудь через попу адаптировать к какому-нибудь ATM и сказать: вот вам - спектрум.

Как прекрасен мир, когда из всего написанного понимаешь только связующие слова )))

Клево конечно... Через пару лет Алан допишет FUZIX до уровня UZIX если раньше не потеряет интерес. :) И опять этот ужасный SDCC.

CityAceE, откуда схема мапера ОЗУ? Я по ссылкам походил, не нашел.

BlastOff, там работающего экземпляра нет даже у автора, т.к. он разобрал на своей девборде маппер, под который написано.

В-общем, через пару лет станет ясно, уже можно это портировать к себе на Орион, или нет.

Цитата:

---

Сообщение от MVV

Может и мне попробовать также с ReVerSE-U16?

---

Я вот тоже присматриваюсь к этой теме - думаю когда-нибудь вернуться к проекту Ultimate на u8. Вот только со временем сейчас сплошной аврал.

Скомпилял ради интереса под org #5CCB. Даже выкинув все устройства не влезло :( Так что классические ZX48/ZX128 в пролёте. А вот клоны с теневым ОЗУ с fuzix подружить теоретически можно, надо только научить линкер обходить нашу дыру в памяти (экран). Места под юзерспейс останется порядка 10 килобайт. Ну хоть что-то.

Цитата:

---

Сообщение от Error404

откуда схема мапера ОЗУ? Я по ссылкам походил, не нашел.

---

Вот отсюда.

Цитата:

---

Сообщение от CityAceE

Вот отсюда.

---

Это для z180, который в fuzix даже пока не поддержан. Для z80pack (единственной архитектуры, для которой проходит сборка из коробки) распределение сейчас такое:

F000-FFFF common - список процессов, их аттрибуты, стек ядра
A81A-F000 свободно (18406 байт)
0088-A819 ядро fuzix
0000-0088 вектора прерываний и код инициализации

глупости это всё. или вы ради просто пофантазировать? :)

Цитата:

---

Сообщение от jemmini

глупости это всё. или вы ради просто пофантазировать? :)

---

Я например давно хожу вокруг UZIX (примерно c 2008 года) - задачка то очень интересная, но все подходы разбивались о весьма капризный компилятор Hitech C. Точнее, вообще о проблему отсутствия надежного ANSI С-компилера под Z80, хоть нативного, хоть с PC.

C fuzix все не намного проще будет, т.к. SDCC глючен. Да, допустим что-то там им собирается. SDCC и у меня собирал тот же код, что и Hitech C, причем делал бинарь в полтора раза больше чем Hitech (уже после всех танцев с бубном с оптимизацией) и собранный им код непредсказуемо глючил. Демотивирует ожидание того, что угробишь время на выяснения глюков компилятора.
Кстати, автор пишет какой версией SDCC у него гарантировано собирался работоспособный код fuzix?

---------- Post added at 17:41 ---------- Previous post was at 17:09 ----------

Цитата:

---

Сообщение от CityAceE

Вот отсюда.

---

Маппер от Z180. Т.е. это не тот маппер, под который текущие искодники fuzix? Как понять?

Error404, какие компиляторы, люди, вы о чём вообще?? под спектрум на можно писать только на чистом асме, да и то возможности на уровне плинтуса.

чем вас не устраивает встроенный в ПЗУ родной интерпретатор бэйсика? :)

или очень охота вывернуться, чтобы в итоге получить то же консольное окно с теми же функциями? :)

это не для тех компьютеров.

Цитата:

---

Сообщение от jemmini

или очень охота вывернуться, чтобы в итоге получить то же консольное окно с теми же функциями? :)

---

так да, об этом и речь.

Цитата:

---

Сообщение от jemmini

или очень охота вывернуться, чтобы в итоге получить то же консольное окно с теми же функциями? :)

это не для тех компьютеров.

---

Юникс может дать
1) Совместимость всех существующих дискетных форматов. TR-DOS <-> CP/M <-> IS-DOS <-> whatever. Причем универсальным образом, а не в виде очередного коммандера. mount то, mount сё, cp, готово.
2) Совместимость с POSIX-ным софтом, которого тьма.
3) Эмуляция CP/M (не шутка, она в верхних строчках TODO листа Алана) - это тоже тьма софта.
4) Совместимость на уровне исходников с другими z80-based компьютерами, поддерживающими fuzix.

На реальном zx это всё без толку, слишком медленно и слишком мало памяти. Но на FPGA-клонах это же безграничные возможности открываются.

К тому же это ж, блин, Алан Кокс. Я уже два дня проснувшись сразу иду в эту тему, чтоб проверить, не приснилось ли мне. Торвалдс, Кокс и Столлмен в мире Linux - это как Синклер, Альтвассер и Викерс мира ZX. В голове до сих пор не укладывается. Если у него в голове есть замысел архитектуры ОС, значит можно заранее быть уверенным, что это не туфта, а что-то продуманное. А раз он уже занимается этим полгода и всё ещё не бросил - значит велика вероятность, что доведет до конца.

---------- Post added at 00:42 ---------- Previous post was at 00:41 ----------

Цитата:

---

Сообщение от Error404

Кстати, автор пишет какой версией SDCC у него гарантировано собирался работоспособный код fuzix?[COLOR="Silver"]

---

Ниже 3.4 вообще никакой не собирает, валится.

Цитата:

---

Сообщение от Error404

Да, допустим что-то там им собирается. SDCC и у меня собирал тот же код, что и Hitech C, причем делал бинарь в полтора раза больше чем Hitech (уже после всех танцев с бубном с оптимизацией) и собранный им код непредсказуемо глючил.

---

Интересный поворот, а можно одним глазком на такой исходник посмотреть?

Цитата:

---

Сообщение от Error404

Маппер от Z180. Т.е. это не тот маппер, под который текущие искодники fuzix? Как понять?

---

Этот README - это сборник README всех проектов, части которых использованы в fuzix. z180 не поддержан вообще, потому что под него нет свободного компилятора, как я понимаю.

Цитата:

---

Сообщение от Eltaron

Юникс может дать
1) Совместимость всех существующих дискетных форматов. TR-DOS <-> CP/M <-> IS-DOS <-> whatever. Причем универсальным образом, а не в виде очередного коммандера. mount то, mount сё, cp, готово.

---

Неа. Слишком разные ФС. А Hobeta - это нифига не универсально и не прозрачно.

Цитата:

---

Сообщение от Eltaron

2) Совместимость с POSIX-ным софтом, которого тьма.

---

В 64к адресном пространстве даже coreutils не заработает =)

Цитата:

---

Сообщение от Eltaron

На реальном zx это всё без толку, слишком медленно и слишком мало памяти.

---

Если делать posix систему - да, но если обгрызть и оставить только минимум, а писать на асме, я верю, что-то сделать можно и на 128к. Есть же RTOS на 8мибитках по 20к.

Цитата:

---

Сообщение от Eltaron

Но на FPGA-клонах это же безграничные возможности открываются.

---

Ага, например прошить что-то помощнее z80. А если мы уж в него рогом упёрлись, то гораздо проще(а может и эффективнее) будет сгородить поверх него мааасенькую вм с виртуальной памятью с адресом в 32 бита шириной.

Цитата:

---

Сообщение от NovaStorm

Неа. Слишком разные ФС. А Hobeta - это нифига не универсально и не прозрачно.

---

А jffs и ntfs - это очень похожие ФС? Но mount-mount-cp почему-то работает.

Цитата:

---

Ага, например прошить что-то помощнее z80. А если мы уж в него рогом упёрлись, то гораздо проще(а может и эффективнее) будет сгородить поверх него мааасенькую вм с виртуальной памятью с адресом в 32 бита шириной.

---

А компилятор под это дело кто писать будет?

Цитата:

---

Сообщение от Eltaron

А jffs и ntfs - это очень похожие ФС?

---

Гораздо более похожие чем TRDOS и CP/M, даже NTFS'ные ACL в линуксе можно использовать.

Цитата:

---

Сообщение от Eltaron

А компилятор под это дело кто писать будет?

---

Если оно будет нужно, то компилятор для плоской модели памяти написать будет всё-таки проще. Для AVR'ки вообще ARM сэмулировали полностью. Хотя вот думаю - 32 бит адрес, 32 бит арифметика, щёлканье страницами... Это будет конечно быстрее эмуляции полной системы, но тоже не особо хорошо. Остаётся только ручками =\

Может кому будет интересно
ммu от z180 есть,
http://opencores.org/project,mmu180
но вот толку от него не много, переключаем банки с грэйдом 4k,
есть компилятор С, который может использовать более 64к,

Скрытый текст

https://www.google.ru/url?sa=t&rct=j...78677474,d.ZWU

[свернуть]

платный вроде, таблетки не искал, к нему.
HD64180Z и Z180, вполне доступны и сейчас, у меня пара штук есть :),
в планах борда, под z80 и z180, пока в процессе "причесывания"

Скрытый текст

http://s020.radikal.ru/i709/1411/d6/39a90e23f42f.jpg
http://i079.radikal.ru/1411/3e/f7ae89c94806.jpg

[свернуть]

для z180
есть бесплатный
Zilog ZDS
и не совсем
IAR
калькулятор ММU
http://z80cpu.eu/mirrors/www.vegenee...mmucalcv12.zip
Требует VB.

Цитата:

---

Сообщение от s_kosorev

Интересный поворот, а можно одним глазком на такой исходник посмотреть?

---

В данном случае я описывал мой реальный опыт по портированию uIP (микро стек TCP/IP) на Орион. Сил хватило на сам стек и 2 приложения (httpd, telnet). Код который комипилировался Hitech C и работал, компилировался и SDCC, но не работал, точнее делал вид что работал (что надо выводить на экран - выводил), но где-то внутри движка сам TCP/IP в версии от SDCC не работал. Я не разбирался отчего так. Ну и размер бинаря был не в пользу SDCC примерно на 40-50%%.

---------- Post added at 14:19 ---------- Previous post was at 14:16 ----------

Цитата:

---

Сообщение от Eltaron

К тому же это ж, блин, Алан Кокс. Я уже два дня проснувшись сразу иду в эту тему, чтоб проверить, не приснилось ли мне. Торвалдс, Кокс и Столлмен в мире Linux - это как Синклер, Альтвассер и Викерс мира ZX. В голове до сих пор не укладывается. Если у него в голове есть замысел архитектуры ОС, значит можно заранее быть уверенным, что это не туфта, а что-то продуманное.

---

Собственно это пока главный и основной (чуть не написал - единственнный) плюс. Ибо это человек вокруг которого может сформироваться хотя и тощее и гиковатое, но коммунити. Как показывает тот же ZX-PK, без коммунити, на одиночках - ничего не развивается.

---------- Post added at 14:24 ---------- Previous post was at 14:19 ----------

Цитата:

---

Сообщение от Eltaron

Этот README - это сборник README всех проектов, части которых использованы в fuzix. z180 не поддержан вообще, потому что под него нет свободного компилятора, как я понимаю.

---

Просто, страничная адресация целыми страницами по 64к, и размещение в одной странице ядра, а в остальных - процессов, это как раз та архитектура, на которую я планировал переделывать UZIX, и которая хорошо аппаратно "ложится" но Орион. Но руки не дошли.

Зато у меня есть собранный мной из исходников UZIX приклад для формирования образов дисков (mkfs, ucp, fcsk) в виде Win32-ехешников. У них с UZI как я понимаю одна и таже ФС. Вот тот же Алан ХЗ как формирует диски. Он ядро выложил, а с чего это ядро запускать?, с какой ФС? Скомпилировать то его скомпилируем, а дальше крутитесь как хотите. :)

Цитата:

---

Сообщение от Error404

это как раз та архитектура, на которую я планировал переделывать UZIX

---

Кстати, народ, никто не подскажет, есть еще где-нибудь в сети хоть какая-то инфа по UZIX (скриншоты, описалово, видео - наподобие того, что существует по OS SymbOS), кроме официального давно не обновлявшегося сайта http://uzix.sourceforge.net ??? А то даже статьи на Вики по сабжу нет...

Цитата:

---

Сообщение от Максагор

Кстати, народ, никто не подскажет, есть еще где-нибудь в сети хоть какая-то инфа по UZIX (скриншоты, описалово, видео - наподобие того, что существует по OS SymbOS), кроме официального давно не обновлявшегося сайта http://uzix.sourceforge.net ??? А то даже статьи на Вики по сабжу нет...

---

Есть такая вещь

SUZI - Spectrum UNIX Z-80 Implementation

Скрытый текст

Проект портирования OS UZI(X) на платформу ZX-SPECTRUM.

На данный момент на основе ядра UZIX1.0 сделан программа-эмулятор (для системы DNA).
Для её запуска нужен ZX-Spectrum-256k (Пентагон)+CASH 32k+Nemo-IDE+небольшой lba-винт
(подключенный, как мастер и на нем должены быть записаны с самого начала(с сектора 0)
данные из файла-образа UZIX.hdd).
В архиве suzi.zip в образе дискеты DNA0459S.TRD версия эмулятора от января 2010 г. -
при работе ядра UZIX,обращения от ядра к дискете эмулятор перенаправляет на hdd(на нем
rootfs uzix) с помощью вызовов системы DNA.
Соответственно запускается ядро, загружается процес INIT,инициализируется, далее
загружается процесс LOGIN.
Можно залогиниться без пароля(набирать имя root,user или guest), и работать в стандартной
юниксовой консоли.При запуске программы top для обновления экрана нажимать пробел (потому
что таймер не работает), и монтировать другие диски нельзя.
Можно посмотреть в эмуляторе Unreal с настройками Пентагон-256 или выше,
cash=32K,в качестве образа hdd подключить файл UZIX.hdd , в качестве диска
для дисковода для А подключить DNA0459S.TRD.
В образе дискеты unix_emu.TRD - скриншоты при запуске разных программ UZIX
В каталоге 0_scr можно посмотреть скриншоты от более старой версии от августа 2009
(в формате стандартного спектрумовского экрана).Ошибки возникали в результате ручного
вмешательства)
Так же вместо LOGIN вручную (через отладчик) загружался процесс BOGOMIPS, но он
скорость он не показывает, точнее показывает 0.000, возможно потому, что таймер не
срабатывает, либо округление при печати только до 4-х знаков.

[свернуть]

http://zx-matrix.nm.ru/SUZI/suzi.txt

http://zx-matrix.nm.ru/SUZI/suzi.zip

http://dl.dropboxusercontent.com/u/2...x/fuzix1_t.png

Eltaron, круто! Как удалось?

Цитата:

---

Сообщение от CityAceE

Eltaron, круто! Как удалось?

---

Реализовал примитивы, через которые работает виртуальный терминал, плюс раскидал код вокруг экрана. Нижние 16 кб сидят в ПЗУ вместо BASIC128, верхняя часть грузится откуда-нибудь (пока что грузится из ниоткуда через хак эмулятора)
Свободной памяти осталось 6 килобайт, так что 48к-совместимость отметается. А в 128 можно класть пользовательский софт в верхнюю страницу памяти, так что 5 программ по 16 килобайт сделать можно.

гы. а процедуру вывода на печать на экране спектрума ты сам писал? :)

Цитата:

---

Сообщение от Sergey

Или 10 по 8! ;)

---

Это сложнее, придётся таблицу релокейшенов хранить. Да и куда нам 10, всю жизнь 1 процесса хватало :)

---------- Post added at 12:03 ---------- Previous post was at 12:01 ----------

Цитата:

---

Сообщение от jemmini

гы. а процедуру вывода на печать на экране спектрума ты сам писал? :)

---

Ну да. А шрифт 8x8 в fuzix уже был.

Цитата:

---

Сообщение от Eltaron

Реализовал примитивы, через которые работает виртуальный терминал...

---

Дружищще, а не научишь как это всё в SDCC скомпилить, и куда драйвер экрана прикручивать?

Цитата:

---

Сообщение от Sergey

Дружищще, а не научишь как это всё в SDCC скомпилить, и куда драйвер экрана прикручивать?

---

Вот сорцы https://github.com/atsidaev/FUZIX/tree/zx128-clean

Со сборкой беда, под линуксом собирается, вот виндой под cygwin не хочет. Не разбирался, в чём дело, может быть, что это просто лечится.
Для сборки нужен sdcc 3.4. В Makefile меняешь платформу на zx128, make, готово.

---------- Post added at 16:27 ---------- Previous post was at 15:09 ----------

Алан принял pull request, так что теперь сорцы есть и в апстриме
http://github.com/EtchedPixels/FUZIX/

Часто вижу у автора такой код:

Код:

---

int lpr_open(uint8_t minor, uint16_t flag)
{
minor; flag; // shut up compiler
udata.u_error = ENODEV;
return (-1);
}

---

Не понятно что это за шиза? ANSI такое позволяет?

Цитата:

---

Сообщение от Error404

Не понятно что это за шиза? ANSI такое позволяет?

---

minor; flag; // shut up compiler

Это для того, чтобы sdcc не выдавал "Warning : var not used".

Цитата:

---

Сообщение от Valen

minor; flag; // shut up compiler

Это для того, чтобы sdcc не выдавал "Warning : var not used".

---

Ну, я как-то так и предполагал.
Интересно во что это компилируется. :)
Конечно, не настолько интересно, чтобы ставить SDCC.

По теме, портирование автором описано, но как-то странно: очевидные вещи, типа нижнего уровня доступа к блочным девайсам (примитивные подпрограммы, которые можно взять от Uzix практически один в один, благо в Uzix вся аппаратнозависимая часть изолирована, более скоромная по количеству кода кстати) - разжеваны, а то что уникальное он сам там насочинял, типа менеджеров памяти (коих там распланировано аж 5 штук, видимо чтобы нескучно было разбираться) - с пятого на десятое, надо лезть в код. За это ему жирный минус. Будем ждать имплементацию TCP/IP, только это перевесит. Делать еще один "хело ворлд" в виде ядра, нет сил. :)

Цитата:

---

Сообщение от Valen

minor; flag; // shut up compiler
Это для того, чтобы sdcc не выдавал "Warning : var not used".

---

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

---------- Post added at 10:18 ---------- Previous post was at 10:11 ----------

Цитата:

---

Сообщение от Error404

Ну, я как-то так и предполагал.
Интересно во что это компилируется. :)

---

Ни во что не компилируется.

Цитата:

---

Сообщение от Sergey

А здесь же он умышленно написал функцию, не использующую ни один своих аргументов.

---

Да,
просто реализацию функции он ещё не написал.

Другое дело, что вероятно было-бы более разумно в sdcc,
чтобы можно было выключить этот Warning, как-то через pragma.
И не добавлять в код, "пустые" по смыслу строки, но пока - вот так только.

Цитата:

---

Сообщение от Sergey

Ни во что не компилируется.

---

Подтверждаю.