OSDev http://osdev.su/ |
|
PlutOS http://osdev.su/viewtopic.php?f=8&t=533 |
Страница 5 из 9 |
Автор: | AlikberOFF [ 15 июл 2012, 07:00 ] |
Заголовок сообщения: | PlutOS |
Yoda писал(а): AlikberOFF писал(а): С одной стороны, он предельно примитивен и собирается "на коленке". Очень сильно сомневаюсь. Вот набросок схемы (таблица - прошивка ПЗУ) На адрес ПЗУ подаём поток ASCII-кодов символов листинга. Регистры наклапливают данные: V00..V29 - Vector (имя переменной), F00..F23 - Factor (Окты, Хексы, Дексы). Конечно, это фрагмент. Там ещё селекторы нужны, мультиплексоры, сумматоры (для десятичного накопления) и пр. муть. А так, на коленке - реально. Причём, вдохновляет это |
Автор: | Yoda [ 15 июл 2012, 17:56 ] |
Заголовок сообщения: | Re: PlutOS |
Ну-ну . Мой совет. Если рискнёшь разрабатывать свою идею, не кидайся паять такие стойки. Сделай для начала программный эмулятор своего CPU. Если всё заработает и всё понравится, пиши HDL описание. Его можно прогнать на симуляторах. Если и тогда всё заработает, делай макет на FPGA. Но мне почему-то кажется, что всё заглохнет на этапе программного эмулятора. |
Автор: | AlikberOFF [ 16 июл 2012, 00:03 ] |
Заголовок сообщения: | PlutOS |
Yoda писал(а): Ну-ну . Я извиняюсь, но именно об этом я писал постами выше:Мой совет. Если рискнёшь разрабатывать свою идею, не кидайся паять такие стойки. Сделай для начала программный эмулятор своего CPU. Если всё заработает и всё понравится, пиши HDL описание. Его можно прогнать на симуляторах. Если и тогда всё заработает, делай макет на FPGA. Но мне почему-то кажется, что всё заглохнет на этапе программного эмулятора. AlikberOFF писал(а): Иными словами, процессор сам является парсером текстового листинга. Причём даже без польской записи языка Форт. Экспериментально написал JavaScript так, будто это - заготовка vhdl. Т.е. каждый вызов функции является одиночным фронтом тактового генератора. Имеются переменные, симулирующие шины адреса и данных, а также управления. На чтение одного байта уходит три такта (вызова функции). Т.е. в JavaScript'е я написал симулятор процессор по всем правилам цифровой электронники:При этом, симулятор написан предельно просто и без лишних ухищрений, чтобы с лёгкостью мог быть портирован в аппаратуру. ... В качестве эксперимента я средствами JavaScript попытался воспроизвести такой симулятор в спартанских условиях. А именно, описать всё крайне просто, практически как аппаратуру в VHDL. Я применил ПЗУ (массив) на 128 байтов с прошивкой сепарации ASCII-кодов. Цифры направляются в один аккумулятор, латинские буквы с цифрами - в другой. Математические знаки - в третий.
В общем, никакого прямого обращения к массиву с текстом программы. Говорю же, хоть мизерный, но опыт построения узлов цифровых имею. Обижаете Опыт показал, что всё чертовски тормозит! Как уже сказал, на чтение байта уходит четыре такта. Следовательно, слово из четырёх байт требует 16 тактов. Симулятор таки отображает состояние всех шин в реальном времени со скоростью 4 такта в секунду! Пока дождусь результата - спать хочу. Вопрос: Зачем так медленно? Отлаживаю же! Должен видеть, на каком такте сбой произошёл. Так как в сотнях строк лога теряюсь. К сожалению, продемонстрировать симулятор не могу из-за стыда: Написан хоть и аккуратно (избегал все специфические конструкции JS: Уйма явных скобок и инструкционных блоков, дабы избежать двусмысленности компиляции в VHDL), но не так красиво, как у профессионалов. P.S.: Симулятор работает, но с кучей багов. Будь всё в Си, отлаживать было бы в сто раз легче. В JS же это жутко сложно. Почему же JS, а не Си? Проект с открытым кодом. Чтобы онлайн одним кликом видеть работу. P.P.S.: Из-за проблем с прямым парсингом текста, решил, как и писал выше, UTF-8 использовать в качестве внутреннего байт-кода (ASCII считываются и сцепляются в цепочки внешним контроллером, переводятся в UTF для внутреннего процессора, который выполняет из за такт!) Но тут возник конфликт: Блоки составных операций в листинге создаются явным отступом TAB-символа, без {...} конструкций. Так процессор явно знает уровень вложенности путём тупого подсчёта табуляции. Но это вызывает тормоза жутчайщие! Тогда как UTF вариант имеет опцию прямого указания размера блока. Конфликт: Чтобы на-лету конвертировать ASCII-цепочки в UTF-слова, нужно точно определить размер блоков... А их нельзя точно указать из-за различной гранулярности листинга: ASCII - 1 байт, UTF - от 2 до 6 байтов, внутренний байт-код - 4 байта. Появляется сильнейщая рассинхронизация указателей адресов на символ в листинге. Короче, идея живёт. Но имеет непродумки. Сильные недоделки концептуального масштаба. Как видите... Код: 41 3D 30 ... A=0 // ASCII-запись листинга Нету идей у меня по корректировке указателя...
--- // UTF-8 вариант листинга FC 80 80 80 80 8A // Символ A FC A0 B0 80 80 8D // Оператор = FC 84 80 80 80 80 // Децимальная величина (0) ... // Внутренний байт-код 80 00 00 0A // Символ A A0 E0 00 0D // Оператор = 84 00 00 00 // Децимальное (0) |
Автор: | iz56 [ 16 июл 2012, 00:57 ] |
Заголовок сообщения: | Re: PlutOS |
Если всё предельно упрощать и оптимизировать - то лучше всё же готовить текст предварительно (можно аппаратно) в более удобную форму. Но тогда получается многопроходность нужна - в случае с хоть немного сложным и удобным языком. Я вообще не понимаю как обрабатывать адреса - если на вход процессору давать исходные тексты. а как же макросы. Компилятор решил бы массу проблем. |
Автор: | AlikberOFF [ 16 июл 2012, 02:13 ] |
Заголовок сообщения: | PlutOS |
iz56 писал(а): Если всё предельно упрощать и оптимизировать - то лучше всё же готовить текст предварительно (можно аппаратно) в более удобную форму. Я уже писал про механизмы.Но тогда получается многопроходность нужна - в случае с хоть немного сложным и удобным языком. Я вообще не понимаю как обрабатывать адреса - если на вход процессору давать исходные тексты. а как же макросы. Компилятор решил бы массу проблем. Имя переменной (до пяти букв) - шифрованный вектор. Буквы имени - "0123456789ABCDEFPQRSTUVWXYZKLMNO@abcdefghijklmnopqrstuvwxyzGHIJ_". Т.е. переменная XY имеет адрес ((code("X") << 6) | code("Y") равный (0x18 << 6) | 0x19, т.е. 0x0619. Тем самым, если в листинге встречается метка "XY:", то текущий указатель листинга помещается в ячейку 0x0619*4 т.е. в [0x1864]. Тем самым, вызов функции XY(...) извлечёт тот адрес и перейдёт. Фокус в том, что если адрес - нулевой, процессор переключается в холостой режим и бежит вперёд. Все записи при этом парсируются, но не исполняются. Отдыхает АЛУ и т.д. Пока не заполнится ячейка [0x1864]! Из-за этого возможны сильные тормоза в самом начале! Потому следует соблюдать правила любого нормального языка (как Паскаль или Си): сначала описываются функции (вхолостую, лишь устанавливаются метки), а потом уж и основная процедура ими оперирует. В этом случае сам процессор выполняет роль компилятора! Но я эти механизмы ещё не трогал. Нет слаженной концепции и принципов описания логики. Короче, у этого процессора все программы будут иметь режим холодного старта. P.S.: Сегодня начал писать новую версию эмулятора ascii-процессора. Специально для публичной демонстрации. Пока результаты не очень из-за copy-paste из тех опытных версий. Пытаюсь смоделировать работу по posedge/negedge, чтобы экономить такты. Но, так как всё описываю средствами JavaScript в рамках одного HTML документа, тяжело применять принципы VHDL к Web-скриптам. Напрямую в VHDL открыть проект не могу: Установлен OrCAD 10, где неизвестно как с ПЛИС работать. А всякие новые WebPack'и не стоят: Скачал с оффициального сайта гиговый архив, а он - битый (несколько важных файлов не извлекаются). Да ещё человек, что обещал купить мне Terasic демо-плату, что-то молчит. Это как пытаться отвёрткой гаечные ключи затягивать: можно, но кучу сил и давления надо прикладывать, да руки беречь! Вот так я собственно и воспринимаю разработку этого симулятора. Да, кстати, этот форум посвящён разработкам операционнок. А есть ли подобные по разработкам процессоров А то у меня, кажется, оффтоп пошёл. За что извиняюсь! |
Автор: | iz56 [ 18 июл 2012, 16:55 ] |
Заголовок сообщения: | Re: PlutOS |
Форум всё стерпит. А если сделаешь хоть половину из того что заявлено. Предметная область форума - не столько инструкции процессора - любого, а процессы, управление памятью,ФС, и другие общие для большинства ос вещи. Если развить эту идею - то получается офффорум. Первое что напрашивается - выделить подфорум для других вещей - таких как эта ветка и моя виртуальная машина то же туда пойдёт. С другой стороны слишком мало сделано что б что-то выделять. А вообще раскладывать всё по категориям - значит самовольно загонять себя в рамки, которые будут заставлять принимать решения. |
Автор: | Yoda [ 18 июл 2012, 17:50 ] |
Заголовок сообщения: | Re: PlutOS |
AlikberOFF писал(а): Да, кстати, этот форум посвящён разработкам операционнок. А есть ли подобные по разработкам процессоров Таковых, по-видимому, нет, в связи с тем, что это занятие не очень-то доступно каждому желающему. Тем не менее, думаю, что разработка ОС весьма тесно связана с процессорами, так что думаю, полезно здесь обсуждать и архитектуры процессоров. На международном форуме есть интересная тема, посвящённая разработке архитектур: OSDev's dream CPU (в вольном переводе: Процессор - предел мечтаний разработчика ОС). Я там описал и свои взгляды/идеи на эту тему. Предлагаю выделить ЦПУшные сообщения и завести аналогичную тему на этом форуме. |
Автор: | SII [ 18 июл 2012, 18:20 ] |
Заголовок сообщения: | Re: PlutOS |
Это уже не тема, а цельный раздел. Только как его обозвать получше? |
Автор: | pavia [ 18 июл 2012, 18:58 ] |
Заголовок сообщения: | Re: PlutOS |
Так и обозвать "Процессор - предел мечтаний разработчика ОС" |
Автор: | Yoda [ 19 июл 2012, 10:26 ] |
Заголовок сообщения: | Re: PlutOS |
Да не надо раздел! Я сомневаюсь, что даже одна тема долго жить будет. Всё ж для раздела требуются глубокие знания участников и большая работа. |
Страница 5 из 9 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |