OSDev

У телефона с 4 ядрами с 1.5 Ггц у каждого размер ещё меньше, вполне похвальные изменения в HiTec и дальше просто добавятся ещё ядра, что убивает напроч смысл в реализации многозадачности и это помоему уже знают даже дети, но вы почемуто не в курсе. Если хотите береч такты, то пишите на АСМ а не на бейсике.

Хм. Мой друг один работает в каком-то отделе анализа ПО. Не удосужился как-то в нужный момент подробно поинтересоваться, чем занимается его контора. Так как тогда мне показалось, что он намекает на пересечение с моими интересами.

Попытаюсь сейчас подойти с другой стороны, надеясь, что написанное пройдёт сквозь академическую стену опыта участников форума.

Допустим, на балконе я задумал установить фотоэлемент, подключить его к схеме с двумя светодиодами с надписями "день" и "ночь". Схема должна работать соответствующе.
Опытный радиолюбитель скажет, что это собирается на коленке даже на одной микросхеме дубовой советской номенклатуры - КМОП триггере Шмидта серии К561.
Но я решил поумничать и воспользоваться микропроцессором!

Что я вижу в каталогах? Везде выбор товара не соответствует моему требованию. Есть такие, хоть линейный видеомонтаж ими делай! Серъёзные, производительные, дорогие. Везде требуется наличие ПК для установки пакета программ. И ассемблер, и форт, и си, и бейсик.
А если компьютера нет? Учить машинный код и прожигать дамп в РТ-шки вручную бит за битом, пропекая потом всё в течении четырёх часов в духовом шкафу.

А если я машинный код не могу выучить. Нет времени. Как быть?
Почему в ассортименте нет процессоров с аппаратной поддержкой Си-выражений?
В качестве эксперимента я средствами JavaScript попытался воспроизвести такой симулятор в спартанских условиях. А именно, описать всё крайне просто, практически как аппаратуру в VHDL. Я применил ПЗУ (массив) на 128 байтов с прошивкой сепарации ASCII-кодов. Цифры направляются в один аккумулятор, латинские буквы с цифрами - в другой. Математические знаки - в третий.
И я убедился, что подобное процессорное устройство можно собрать чуть ли ни на коленке на базе советской элементарной базы микросхем серии К155! Набираешь просто пачку регистров. Главное, прошить ПЗУ правильно. Т.е. для аппаратного парсинга листинга не нужны многоядерные сверхтехнологии Hi-Tec'а!

Вопрос: Почему эти технологии не продвигаются ведущими фирмами как альтернативная ветка?
Пускай на одну операцию уходит до сотен (не сотни, а сотен!) тактов. Что будет оправдываться крайне низкой ценой.
Ведь, судя по опыту, парсировать листинг (пусть специфический) достаточно легко. И, думаю, ядро (опционально) x86 могло бы спокойно, наряду с машинным кодом x86, разбирать конвейрером и ASCII-листинги. Охватывая всю формулу за пару тактов.

Ведь особых технологических препятствий нет.

Кто вам мешает запрограмировать такую штуковину но машине с обычным С++ или Ява если АСМ не устраивает и отнести, и воткнуть в дверь или куда подальше?
Зачем замку нужен выход для манитора и флешки? Есть такой человек как инженер контроллеров, который уже наделал всяких процесоров многоядерных всяких, а есть такой человек как программист, который не хочет ни чего для них писать, придумывать программ, я о том, что сейчас спрос больше на ПО.
Проблема в том, что все боятся писать глобальные вещи серьёзно, а занимаются только поддержкой того, что исчерпало свой ресурс и создавалось для других целей, а не для того что из них пытаются сделать.

Если не гнаться за тактами, то это уже сделано, причём более гибко и качественно. Называется "программный интерпретатор скриптового языка".
А если гнаться за тактами, то аппаратный интерпретатор лишён смысла из-за неэффективности.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

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

Кстати, я не случайно решил отписаться в этой теме про ОСь совершенно, на первый взгляд, не вписывающуюся тему про процессор. Однако, EBML-язык с одной стороны какбы кроссплатформенный. С другой стороны, имеет некоторые недочёты.
Так как UTF-8 появилась вместе с Plan_9, у меня при моделировании своей ОС появилась необходимость в некоей стандартизации. В следствии чего теоритическая модель вышла за рамки ОС и сформировалась в самостоятельную ветку.

Да, согласен, Java кроссплатформенен и идеален в ряде случаев. То же самое и CIL. Но, например, для меня это всё не подходит.
Почему?

Это, конечно, смешно. Но меня двигают мотивации, основанные на апокалипсисе. Я прочитал одну статью, где человек в домашних условиях пытался выращивать транзисторы на кремнии. Чтобы, в случае краха цивилизации, не скатиться в каменный век.

Я и подумал, если вручную снова по-старинке придётся вырезать процессоры, то уж не Java-процессор, с которым до сих пор монстры индустрии справиться не могут. И не древний i4004! Нужно нечто простое, но не примитивно-устаревшее.

И в голову пришло попытаться разработать реальный парсер текста.
С одной стороны, он предельно примитивен и собирается "на коленке". С другой стороны, его байт-код элементарен для освоения любому знатоку математики.
А главное, я на претендую на победу в конкурсе "апокалиптические технологии в быту", а просто проверяю сам и оповещаю других (Вас) о том, что это - реально.
Ведь можно заставить пару десятков тысяч транзисторов разбирать читабильный листинг! Пускай даже на операции уходит сотня-другая тактов, но к нему не нужен ни интерпретатор Бейсика, ни Java, ни Phyton. Сам процессор по своей природе является интерпретатором абстрактного байт-кода. Тогда как меня интересует именно интерпретация не абстрактного байт-кода, а читабильного ascii-листинга.

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

P.S.: Вообще-то моя задумка напоминает некий клеточный автомат. А они, как известно, используются для исследования.
Наряду с эзотерическими языками программирования, а также XC9536 процессора из четырёх команд, у меня для выполнения вычислений не нужно нагромождаться сотнями эзот-кодов. В то же время, автомат полноценен по Тьюрингу.

Jazelle


Motorola MC14500


Очень сильно сомневаюсь.


Да вообще-то любой процессор можно представить как интерпретатор любого байт-кода.


Из-за неэффективности.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Не имеет отношение к Java процессору.
Jazelle - это всего лишь пару арм инструкций. Одна из которых предназначено для ускорения работы с классами. (Что то там с двойным разъминовыванием указателя).

Я не спец по АРМам, но в википедии про Jazelle DBX написано следующее:

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Jazelle, в отличие от собственно АРМа, "засекречена", и документация на неё просто так не выложена. Может быть, её можно скачать где-то "слева", но лично я не интересовался: мне Жаба без надобности. Но суть сей технологии действительно заключается в ускорении (понятное дело, что аппаратном) декодирования и выполнения жабовского байт-кода.