RT-11 это ОС реального времени, разработчик DEC, да вот ниже про нее уже написали. Сейчас популярной некогда на постсоветском пространстве DEC с нами уже нетПод "самураем" я подразумевал ZX как платформу. Т.е. видение платформы у каждого свое и консолидировать усилия в этом направлении не удалось? Конечно здоровая конкуренция это хорошо, но... в разумных пределах. Так обстоят дела только в России или Европа и Запад не исключения? Про клоны я понял. Я не имел ввиду, да и не думал, что "самурай" у каждого свой настолько - что общих точек соприкосновения никто ни нашел. Плачевно...
---------- Post added at 10:44 ---------- Previous post was at 09:21 ----------
Необходимость в таких режимах есть? Как я понимаю беспокоит в таких случаях скорость перерисовки? И требования в этом случае - отрисовка полного экрана за 1 кадр или не такие жесткие? А не будет ли в таком случае ограничением не ядро для обработки операций на содержимым, а возможности ЗУ по доступу? Фактически решить задачу не увеличивая производительности могут специализированные блоки ядер такие как например SIMD, но они требуют в итоге наличие очень быстрой памяти так операции загрузки/выгрузки имеют небольшие временные окна при схеме доступа к ЗУ экрана как 1 ядро - 1 растр. Адресное поле команд в Z80 имеют свободные участки оп-кодов? В реализация Z80 на базе ПЛИС были ли кем нибудь предприняты шаги к расширению архитектуры CPU например за счет блоков SIMD?
Честно говоря когда в начале поста я завел речь о транспьютерной архитектуре, то в первую очередь подразумевал именно возможность формирования любого сложного растра - в каждой ячейке присутствует собственная локальная память и она отождествлять N-ый элемент растра. Задача формирования растра, так же как и задача его обработки - на 100% параллельная задача. Конечно будет временной лаг на межкоммуникацию, но он должен быть незначительным.
Да это возможно. Но если говорить например о звуке то видимо Вы предлагаете использовать для таких целей DSP, однако DSP это не универсальный процессор, конечно наверняка такие монстры как AD предлагают к своим DSP и appnote и библиотеки на реализацию MP3. Но MP3 требует лицензионных отчислений, да и не соответствует духу GPL/GNU. И ,кстати, в этом случае пользователь платформы ZX будет поставлен перед необходимостью знать нескольких архитектур ЦПУ и DSP. Считаете что это приемлемо?
Если говорить о декодерах таких как например VS1011b, то платформа ограничивается только стандартом MP3, как быть с другими стандартами например с открытым OGG? Конвертировать в MP3? Сужается круг возможностей для пользователей платформы.
Шина I2C конечно решение правильное, в связи с чем вопрос шина до периферийных устройств в Спектруме так и осталась параллельной? Последовательную шину на PCB развести легче и частоты совсем другие. I2C все таки низкоскоростная шина и на роль магистрали, думаю, что не подходит.
Как промежуточный шаг - вполне!
Однако вопрос что значит "принципиально новая операционка" не совсем ясен, что бы вы назвали новой?
1. *nix (без страничной/виртуальной памяти)
2. микроядерные ОС
3. ОС реального времени (в том числе и 2.)
4. CP/M (тем более что CP/M уже существует на ZX)
5. Free DOS
Многозадачные/однозадачные? Динамическое связывание?
GUI Вы имеете ввиду графическое API? Или подсистему BIOS видео-режимов (как скажем расширение VBE под x86)? Расширения 3D (opengl)? Если API то для ZX Вы его видите вне ЯВУ? Каким образом?
т.е. вот этот тулчейн http://sourceforge.net/projects/z80gcc/ или вот этот компилятор http://sourceforge.net/projects/sdcc/files/ не оптимизирует под 8080 или Z80?
ADC-Z80? Кроме того у самого Zillog должен быть KIT да и Hi-Tech вроде бы выпускала компилятор под Z80. Hi-tech C как я понял умеет работать на CP/M. Кстати Z88dk это Zilog-овский SDK?
Вы говорите про компилятор под "хост" или под "таргет"?
Если уж о Виртовских языках, то куда более быстрым в реализации будет Oberon но увы писать на нем будет очень не привычно. Простой компилятор написать дело времени (кстати именно такого, о котором Вы говорили выше - человеко-месяц), но оптимизирующий компилятор для регистровой архитектуры это годы работы. Если уж и говорить о некой оптимизации то уж лучше C-- где вся оптимизация дело рук исключительно программиста и язык Си.
Jazzel как технология динамического исполнения у многих вызывает нарекания, отчасти потом что умный JIT способен с небольшими потерями дать те же возможности. А интерфейс к ядру JVM только все испортит фактически периферийному ядру придется стать ЦПУ в случае запуска на нем байт-кода. ИМХО , но реализовывать JVM надо на ЦПУ, коль скоро архитектура предусматривает центральное ядро. Не хватает производительности - расширять ядро частотно и архитектурно или не меняя ничего писать под JVM более оптимальный код.
---------- Post added at 10:46 ---------- Previous post was at 10:44 ----------
Можно url? А лучше в рамках дискуссии описать что за проект и какие цели преследует? Или проект проприетарный?





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