Yoda писал(а):
Ну-ну
.
Мой совет. Если рискнёшь разрабатывать свою идею, не кидайся паять такие стойки. Сделай для начала программный эмулятор своего CPU. Если всё заработает и всё понравится, пиши HDL описание. Его можно прогнать на симуляторах. Если и тогда всё заработает, делай макет на FPGA.
Но мне почему-то кажется, что всё заглохнет на этапе программного эмулятора.
Я извиняюсь, но именно об этом я писал постами выше:
AlikberOFF писал(а):
Иными словами, процессор сам является парсером текстового листинга. Причём даже без польской записи языка Форт. Экспериментально написал JavaScript так, будто это - заготовка vhdl. Т.е. каждый вызов функции является одиночным фронтом тактового генератора. Имеются переменные, симулирующие шины адреса и данных, а также управления. На чтение одного байта уходит три такта (вызова функции).
При этом, симулятор написан предельно просто и без лишних ухищрений, чтобы с лёгкостью мог быть портирован в аппаратуру.
...
В качестве эксперимента я средствами JavaScript попытался воспроизвести такой симулятор в спартанских условиях. А именно, описать всё крайне просто, практически как аппаратуру в VHDL. Я применил ПЗУ (массив) на 128 байтов с прошивкой сепарации ASCII-кодов. Цифры направляются в один аккумулятор, латинские буквы с цифрами - в другой. Математические знаки - в третий.
Т.е. в JavaScript'е я написал симулятор процессор по всем правилам цифровой электронники:
- Есть шина адреса (переменная busAddr)
- Есть шина данных (переменная busData)
- Есть шина контролля (busCtrl) и т.д.
И работает всё подобно электронному узлу: При чтении данных выставляется адрес и отчищаются биты контроля; На втором такте (вызове функции эмуляции ядра) выставляется бит RD контроля. На третьем такте копируется busData во внутреннюю переменную. На четвёртом - отчищаются биты контроля и начинается анализ считанного байта...
В общем, никакого прямого обращения к массиву с текстом программы. Говорю же, хоть мизерный, но опыт построения узлов цифровых имею. Обижаете
Опыт показал, что всё чертовски тормозит! Как уже сказал, на чтение байта уходит четыре такта. Следовательно, слово из четырёх байт требует 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)
Нету идей у меня по корректировке указателя...
Вход
Регистрация
FAQ
Поиск
