Симулятор МК61 на msp430?

А нельзя ли на msp430 залить имеющуюся "прошивку"-эмулятор, написанную на Си?

Сергей, если разговор идет о работе Феликса Лазарева по вскрытию К145 и его эмуляции то да - можно! Однако в этом случае теряются все преимущества msp430, как то низкое энергопотребление, высокая удельная производительность на МГц. Боюсь что производительность эмулятора в этом случае будет слегка превосходить МК61. Кроме того нельзя будет использовать систему команд ПМК МК-61 для чего то более емкого чем 105 шагов программы.

Хотелось выйти за рамки традиционного использования МК61, так как есть возможность не расширяя системы команд МК61 симулировать большее адресное пространство - через косвенные команды чтения/записи и перехода, через них же получить доступ к периферии и использовать ядро МК61 полноценно, в том числе и для системных целей. Для МК61 msp430 может дать совершенный механизм энергосбережения, но только при условии что большую часть времени ядро будет проводить в режиме "сна". Эмулятор же выжмет из msp430 все соки, а потом поверх ляжет архитектура МК61 последовательного 1 битного типа.

Для симуляции К145 комплекта думаю лучше всего подойдет какой нибудь мощный ARM скажем msp432 или stm32 там тактовая доходит аж до 70МГц.

И не только через косвенную адресацию.

Ячейка памяти программ расширяется до 16 бит. В результате могут быть команды БП 1234 (0051 1234), без нарушения работы советских программ. Здесь уже мелькало это решение.

В этом случае получается рыхлый код. Мало того так как адресация будет идти в смешанном бинарном + BCD пространстве адрес, сразу же плюсом еще потеря части адресного пространства. Расточительно. Тут стоит подумать над необходимостью именно такого расширения.

Согласен с обоими аргументами. Но это смотря как реализовать хранение памяти программ. Память программ считывается только виртуальной машиной ПМК. Можно сделать и рыхлым, если ресурсы позволят.

AtH wrote: Можно сделать и рыхлым, если ресурсы позволят.

Безусловно! С этим трудно не согласиться. Если позволят то почему бы и нет.

В качестве платформы пока использую lanchpad msp430g2553 и lanchpad msp430FR5739, с ОЗУ там не богато 512 байт либо 1К. Но для FRAM понятие между ОЗУ и FRAM сглажены, до минимума, можно сказать 15Кб FRAM это несколько заторможенное SRAM. Однако конечные объемы прошивки МК61 могут оставить крайне мало места в FRAM для данных. Но спорить не буду всегда можно найти платформу с достаточным количеством как RAM так и FRAM.

Рыхлости на низшем уровне можно избежать, если хранить таблицу старшего байта памяти программ отдельно — лишь для тех случаев, когда он отличен от нуля. ReadHByte(adr) будет давать 0, если старший байт не был предварительно сохранён командой WriteHByte(adr,byte) — накладные расходы будут исключительно для команд переходов.

Также и трансляцию bcd-адреса в двоичный можно сделать незаметной для уровня программ пользователя.

Мы пока с Вами шкуру не убитого медведя делим, на повестке дня быстрая BCD арифметика. Да хрен с ним быстрая, хоть какая нибудь - как я говорил сейчас есть только сложение, вычитание и умножение 8-разрядной мантиссы (умножение уже использует порядок, но с этим еще надо работать). Сейчас работаю на делением мантиссы - уже брезжит свет в конце тоннеля, но работы валом. Реализован стек МК61. Форт ядро для отладки VM МК61 через терминал. Однако реализация всего остального, а именно логарифмы, тригонометрия - вызывает пока огромные сомнения в возможности завершении работы.
Адресация и прочие системные вещи на фоне вышеописанных - мелочь.

Здесь не соглашусь с вами.

Система команд и адресация, вопросы совместимости, крайне важны. Из «плавучки» жизненно важными являются четыре арифметических действия — на основе которых реализуется, например, возведение в квадрат.

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

AtH wrote: Система команд и адресация, вопросы совместимости, крайне важны.

Вот скажите, Арви, если у Вас еще нет арифметического стека, так ли уж важно делать хоть какую нибудь адресацию кроме стековой?

AtH wrote: Из «плавучки» жизненно важными являются четыре арифметических действия — на основе которых реализуется, например, возведение в квадрат

Вот именно это я и считаю жизненно важным, а из этого есть пока сложение, вычитание, умножение и 1/8 часть от деления. Я же предлагал Вам помочь мне, предложение до сих пор в силе. Пишу на ассемблере msp430 "плавучку" IEEE 854, от помощи не отказываюсь.

Сейчас мой приоритет — работа над Каллисто. Там придётся реализовывать и то, чем вы занялись (bcd-арифметику). Но, скорее всего, для имеющегося ядра 8051. Придётся повторять велосипед, который Новосибирск не выложил в Интернет — или заимствовать уже выложенные библиотеки.

msp430 у меня нет, даже если бы хотел этим заняться. Но важнее, что меня уже не так привлекает разработка ради самого процесса разработки. Просто создать некое уникальное устройство и гордиться «оно заработало и вот схема, если кто захочет повторить» мне недостаточно.

Подобной конструкторской деятельностью обычно занимаются в рамках более общего проекта по выпуску электроники. Разработанные схемы направляются на производство, другие отделы (или тот же самый коллектив) занимаются финансированием, сбытом, рекламой и поддержкой продукции. Этой структуры (не так даже важно, она работает в прибыль или убыточна, профессия это или хобби) я не вижу. «Невидимые руки рынка» сейчас в России, к счастью или сожалению, пробуксовывают.

Пока что «Электроника МК-161», при всех её ограничениях и особенностях, лучше всего подходит для моих целей. Она производится и выпускается. Желающие могут приобрести себе экземпляр МК-161, чтобы запускать на ней мои программы.

Новосибирская ЭКВМ это пока единственный успешный и полноценный проект в России. За рубежом же есть много интересных и плодотворных проектов: «Пандора», швейцарские калькуляторы, не говоря уже о крупных фирмах TI и HP. Производство, выпускающее готовую продукцию, это только на ¼ разработка железа и ПО.

Да, речь о симуляции на уровне "железа" с использованием уже имеющейся у нас Си-программы.

Соки выжимать он не будет, но скорость счета (по программе и в автомате), конечно, будет ниже, чем у написанного "с нуля" эмулятора. Но вполне вероятно, что и такая скорость будет на порядок выше, чем у оригинала, а значит, более чем достаточной для выполнения всех имеющихся программ для МК61. По сути, это аналог засунутой в HP 35s прошивки HP 35.

Serguei_Tarassov wrote: Соки выжимать он не будет, но скорость счета (по программе и в автомате), конечно, будет ниже, чем у написанного "с нуля" эмулятора.

Чем у симулятора. Это ведь эмулятор, он абсолютно точно повторяет весь путь движения сигналов в цифровом
тракте калькулятора, как то логические вентили, мультиплексоры, дешифраторы. Эмулятор Феликса это схема
описанная на Си.

Serguei_Tarassov wrote: Но вполне вероятно, что и такая скорость будет на порядок выше, чем у оригинала, а значит, более чем достаточной для выполнения всех имеющихся программ для МК61. По сути, это аналог засунутой в HP 35s прошивки HP 35.

Тут вижу одну проблему на пути следования - расширить вероятно мы его никак не сможем. Получится точная копия МК61 на современной микроконтроллерной платформе.

Надо посмотреть на код.

Что меня сильно удивило, но видя там кучу динамической инициализации, думаю что реально это не заработает на 512 байтах ОЗУ :) Тем ни менее в ПЗУ 16К код лег. Я правильно понимаю весь микрокод размещается статически?

1. Убрал виртуальные методы в статическкие, TI C Compiler их не принял.
2. Вырезал функции связанные с загрузкой с файлов и отображением статуса.
const char* MK61Emu::GetFileResultMessage(mk_file_result_t result)
bool MK61Emu::LoadState(const char *name, mk61emu_result_t *result)
bool MK61Emu::SaveState(const char *name, mk61emu_result_t *result)

Сергей под msp430 придется код сильно перепилить, но в принципе шансы есть. Все скомпилилось.

вот такой main, надеюсь весь код заюзался тремя вызовами класса?

MK61Emu *m_emu;

int main(void) {
    WDTCTL = WDTPW | WDTHOLD;	// Stop watchdog timer


    m_emu = new MK61Emu();
    m_emu->ON();
    while(true) m_emu->DoStep();
	return 0;
}

Эмулятор с микрокодом влез в G2553?!!

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

Vitasam wrote: Эмулятор с микрокодом влез в G2553?!!

У меня к проекту подключен только main.cpp, mk61emu.cpp. Все микрокодовые последовательности наблюдаю только в нем. Но, Виталий, тут вот что важно - все классы выделяются динамически, я думаю что компилятор за кучей не следит. Ну "замолотил" модуль указатель и ладно, а по факту сегмент bss никто не посчитал, мы в ж рантайм просим ОЗУ. Думаю что из за системы классов и динамического распределения, весь айсберг внизу, мы его не видим.

насчёт кучи

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

Объявил экземпляр класса, и все g2553 отъехал в сторону по причине нехватке ОЗУ, 512 байт мало. Для проверки поставил g2744 c 1К ОЗУ, все решилось. Таким образом в районе 2К я думаю ОЗУ понадобится.

"В то время, как гигабайты и гигагерцы бороздят просторы Большого театра" (с) :)
512 байт - настоящий хардкор, спасибо Алексею, что напомнил времечко.

Nonpariel Physical (NP) is a standalone calculator microcode emulator. NP-25 executes microcodes for HP-21, HP-25C and HP-33C. A low power MSP430G2553 is used in this project.

:)

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

Биллу Гейтсу приписывается про 640 КБайт, Алексею будем приписывать в легендах про 512 байт :)
Думаю, что пора переходить к бОльшим объемам памяти, чтобы запихнуть эмулятор МК61.

Serguei_Tarassov wrote: Думаю, что пора переходить к бОльшим объемам памяти, чтобы запихнуть эмулятор МК61.

В принципе :) если очень сильно захотеть то g2553 с МК61 можно залезть, но не думаю что с Эмулятором. Там все таки объективные причины мешают - просто в комплекте ИК145 для МК61 действительно порядка 800-1000 байт памяти. А можно косвенно по этому признаку (размер памяти комплекта) определить что МК61 явно круче HP-21, HP-25C and HP-33C приведенного Виталием в пример :)

Надо смотреть соотношение предоставляемых пользователь функций/ресурсов и расходуемой памяти. Например, в HP33 сотни шагов и регистров, функций и команд тоже больше. Например, по показателю быстродействия "пустой цикл" в расчете на тактовую частоту МК56 не лучше, не думаю, что у МК61 оно выше.

Уже не помню, по-моему, статически, там сплошные таблицы-массивы. Если С++ будет реально мешать, можно взять одну из предшествующих версий, когда все было на чистом Си (функционал не менялся). Но и в текущем виде все компилировалось под msp432/Energia.

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

Убрать связь с mk72r.h несложно, там обратная зависимость, оболочка "знает" про эмулятор, а он про неё - нет. Т.е. удаляй все лишнее без опаски потерять функционал.

Виртуальные методы не нужны, если эмуляторов менее двух (это простой адаптер к оболочке для унификации управления). Их надо объявить обычными, а не статическими.

Serguei_Tarassov wrote: Уже не помню, по-моему, статически, там сплошные таблицы-массивы. Если С++ будет реально мешать, можно взять одну из предшествующих версий, когда все было на чистом Си (функционал не менялся). Но и в текущем виде все компилировалось под msp432/Energia.

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

Serguei_Tarassov wrote: Вообще, лучше не бояться "плюсов", компиляторы сейчас очень умные, код на выходе оптимизируется и в итоге будет лучше линейного ассемблерного, написанного без человеческой оптимизации.

Для платформ x86, ARM еще куда не шло. Но вот на Atmel AVR я видел во что превращается код при использовании GCC C++ (да там к стати и ограничения сразу дается - только статические методы), это жуткая картина, такое ощущения что любая оптимизация отключается напрочь при том что включен -O2. Нет, Сергей, я не боюсь С++ :) но микроконтроллеры с объемами памяти до 4К-8К ОЗУ не готовы ко всем его прелестям.

Больше всего опасностей представляет - динамическое выделение памяти. Стек поднимается сверху границы ОЗУ вверх, любая рекурсия или просто большая вложенность и мы побеждаем при скромных размерах ОЗУ наш сегмент данных на раз.

А это значит что любое распределение класса - для нас опасно

Например вот это m_emu = new MK61Emu();

Если получится лучше его распределить статически

MK61Emu m_emu;

с последующим явным вызовом конструктора

m_emu.ON();

Serguei_Tarassov wrote: Убрать связь с mk72r.h несложно, там обратная зависимость, оболочка "знает" про эмулятор, а он про неё - нет. Т.е. удаляй все лишнее без опаски потерять функционал.

Виртуальные методы не нужны, если эмуляторов менее двух (это простой адаптер к оболочке для унификации управления). Их надо объявить обычными, а не статическими.

Да я их уже переобъявил, но не знаю как проверить работоспособность. Как я понял сбоку через оболочку приделан вывод - это первое что меня напрягает, потому что у меня puts/printf и все подобное не существует, их еще надо написать и перенаправить например в UART. Тоже касается и ввода с терминала. Как осуществлять взаимодействие командной строки с mk61emu пока еще не разобрался, да и командной строки тоже нет. Кроме того там malloc, а это напрягает меня еще сильней :) Придется отовсюду вырезать динамическое распределение. Работы валом, помощники нужны не простые а понимающие систему классов mk61emu.

Сергей можно найти место где работает косвенная адресация МК61 в исходнике и написать к этому свою функцию чтения памяти, тогда можно рассчитывать хоть на какую то модернизацию МК61 до обращения во вне и в широкую память данных?

Вполне можно использовать автоматическое (локальное статическое) объявление без new. Конструктор вызывается сам в момент инициализации переменной, остается только "включить" On().

MK61Emu m_emu;

Возвращаясь к вопросу, зачем все эти

memset(&(ROM), 0, sizeof(ROM));

ROM - это внутренняя структура эмулятора, она может инициализироваться "прошивкой" МК61 или МК54, соответственно. Или для реинициализации после сбоя/ошибки. С остальными также.

Идея доработать саму прошивку в том числе для расширения команд уже высказывалась М.Храмовым здесь, теоретически это возможно, практически же придется "хакнуть" её, сделав глубокую трассировку состояний, чтобы понять, откуда и куда ноги растут.

Serguei_Tarassov wrote: Возвращаясь к вопросу, зачем все эти

memset(&(ROM), 0, sizeof(ROM));

ROM - это внутренняя структура эмулятора, она может инициализироваться "прошивкой" МК61 или МК54, соответственно. Или для реинициализации после сбоя/ошибки. С остальными также.

Сергей я правильно понимаю:

1. ROM размещен статически имеет три таблицы микрокода IK1302, IK1303, IK1306 - по сути это микросхемы ROM для разных комплектов К145ИК1302 ИК1303 ИК1306. И это приличная по объему таблица, ее никто не инициализирует.

2. Внутри IK13, класса объявлен указатель на ROM

class IK13
{
............
private:
    const IK13_ROM *ROM;

3. И memset(&(ROM),0,sizeof(ROM)) инициализирует нулем указатель ROM как член класса, при этом sizeof тоже понимает что речь идет об указателе а не от таблице ПЗУ микрокода (имена то у них одинаковые, вот уж по истине веревка достаточной длинны что бы выстрелить себе в ногу).

А почему нельзя было сделать так ROM = NULL;

P.S. Виноват, не разобрался пришлось подредактировать исходное сообщение.

Честно говоря, уже не помню, почему не ROM = NULL, может в Си-коде было иначе, потом это переехало в "плюсы" без изменений.

void MK61Emu::ON(void)
{
        Cleanup();
        m_angle_unit = angle_unit_radian;
        m_IR2_1 = new IR2();
        m_IR2_2 = new IR2();
        m_IK1302 = new IK13();
        m_IK1303 = new IK13();
        if (m_mode == mk61emu_mode_61)
            m_IK1306 = new IK13();
        else
            m_IK1306 = NULL;
        // copy ROMs
        m_IK1302->SetROM(&ROM.IK1302);
        m_IK1303->SetROM(&ROM.IK1303);
        if (m_IK1306 != NULL)
            m_IK1306->SetROM(&ROM.IK1306);
        DoStep();
    m_outputRequired = true;
}

Сергей, вот здесь конкретно можно обойтись без динамического выделения памяти? Я так понимаю что весь доступ с "->" летит на разименовывание "."
Что такое режим mk61emu_mode_61?

Может сразу так m_IK1306->SetROM(&ROM.IK1306);

Если члены m_IRxxx, m_IKxxx объявить автоматическими, то конечно можно и

m_IKxxx.SetROM(&ROM.IKxxx)

mk61emu_mode_61 - режим МК61, иначе - МК54 (статическую m_IK1306 в этом случае можно реинициализировать нулями).

Перевел все в статику ни одного new ни одного malloc/alloc. Что характерно линкер выругался на метод деструктор класса MK61Emu, пришлось его убрать из класса :) Весьма странно - видимо это особенность статического размещения экземпляров класса, деструктор не нужен :) Вышел на потребление ОЗУ в районе 2К. Что конечно неважнецки, хотелось бы 1К.

Сергей, не могу понять как производится ожидание завершение отработки на нажатие комплекта К145. Как я опять же понимаю DoKeyPress выставляет нажатие на матрице клавиатуры

MK72Result MK61Emu::DoKeyPress(const int key1, const int key2)
{
        m_IK1302.key_x = key1;
        m_IK1302.key_y = key2;
        DoStep();
        m_outputRequired = true;
}

Мне казалось что на строках или столбцах идет сканирование сдвигающейся единичкой или нолем, а с другого конца клавиатурной матрицы читается код. Тут устанавливается и X и Y то есть координата нажатой кнопки. Как ведется отсчет кнопок в клавиатурной матрице кто на каком пересечении. Хотя это ладно, но вот как ожидается вывод на индиактор? Постоянным полингом m_outputRequired?

Да, DoKeyPress симулирует нажатие кнопки. Соответствие координат кнопкам можно посмотреть в MK61Commander::ParseInput(). Регулярный опрос m_outputRequired не обязателен, сейчас это сделано через флажок для простоты. Правильнее сделать событие (callback) и вызывать его обработчик из эмулятора в момент завершения (?) вывода на индикатор.

Думаю, в 1К можно уместиться, если разместить все данные прошивки вне ОЗУ. Иначе получается двойное потребление памяти, хотя нужно оно только при инициализации.

Serguei_Tarassov wrote: Правильнее сделать событие (callback) и вызывать его обработчик из эмулятора в момент завершения (?) вывода на индикатор.

А откуда должен следовать callback, я циклического опроса флага m_outputRequred не наше. Сергей не забывайте что я отпилил почти все что можно от МК72 и класс MK61Emu изрядно подрезал. Я правильно понимаю что DoStep() генерирует тактирование по всем микросхемам комплекта, и при этом возвращает результат M_OK опять же всегда. Т.е. достаточно сделать DoStep() и по окончанию снять все что выведено на индикатор? Тут бы поподробней.

Serguei_Tarassov wrote: Думаю, в 1К можно уместиться, если разместить все данные прошивки вне ОЗУ. Иначе получается двойное потребление памяти, хотя нужно оно только при инициализации.

Вот тут не пойму, вроде бы ROM и так вне ОЗУ он же const mk61ROM_t ROM. А почему двойное, не нашел копирование ROM-ов, за копирование там просто смена указателя. То есть для m_IK1302 m_IK1303 m_IK_1306 как
для экземпляров класс IK13 устанавливается значение указателей &ROM.IK1302 &ROM.IK1303 &ROM.IK1306 но они при этом не копируются

void IK13::SetROM(const IK13_ROM *ROM)
{
    this->ROM = ROM;
}

Я не могу понять куда уходит столько памяти, неужели плюсы на кучу забирают какой то объем.

Как выяснилось в переписке, более 500 байт занимают разные таблицы состояний и переходов, т.е "плюсы" и компилятор здесь ни причем.

io_t M[IR2_MTICK_COUNT] - 252 байта
io_t R[IK13_MTICK_COUNT] - 42 байта
io_t M[IK13_MTICK_COUNT] - 42 байта
io_t ST[IK13_MTICK_COUNT] - 42 байта
mk61_register_position_t m_prog_counter[2] - 14*2 = 28 байт
mk61_register_position_t m_returns[5][2] - 14*5*2 = 140 байт
Итого: 540 байт

Из *.map файла по модулю hdlcore.cpp

pages_addresses @ 232bit = 29 байт
pages_addresses_replacements_61 @ 352bit = 44 байта
stack_addresses @ 232bit = 29 байт
stack_addresses_replacements_61 @ 112bit = 14 байт
return_addresses @ 32bit = 4 байта
pages_addresses_replacements_54 @ 328bit = 41 байт
stack_addresses_replacements_54 @ 112bit = 14 байт
J @ 328bit = 41 байт

xxx54 это для MK54 их можно выкинуть.

Serguei_Tarassov wrote:
io_t M[IR2_MTICK_COUNT] - 252 байта
io_t R[IK13_MTICK_COUNT] - 42 байта
io_t M[IK13_MTICK_COUNT] - 42 байта
io_t ST[IK13_MTICK_COUNT] - 42 байта

Вот это вот внутри класса IK13 а он используется как родитель для IK1302, IK1303, IK1306 то есть это все нужно помножить на три! Итого 378 * 3 = 1134 байта!!!

«Вышел на потребление ОЗУ в районе 2К. Что конечно неважнецки, хотелось бы 1К.»

Уже известно, какие ещё ресурсы потребуются? 2 килобайта ОЗУ в МК-161 есть. Влезет ли прошивка в 10000 байт памяти программ? И сколько останется места для кода… мне интересна реализация эмулятора в корпусе с клавиатурой и экраном, идеально заточенными под ПМК.

Ресурсы известны, код программы открыт, вместить эмулятор в 10Кб (10К шагов и 1К регистров) сложности не представит. Однако конечная цель - выполнение эмулятора МК61 на расширенном симуляторе МК61 (оксюморон какой-то) мне не представляется ни востребованной, ни интересной в реализации (эмулятор весьма туполинейно устроен).

Эмулятор по-видимому прямолинейно эмулирует поведение последовательного однобитного микроконтроллера ИК13хх.
Нельзя ли ускорить работу, выполняя часть операций параллельно? Со слов Феликса Лазарева, в качестве АЛУ вообще используется однобитный сумматор.
На МК-161 эмулятор МК-61 будет работать со скоростью одна операция в минуту...

Электромонтёр wrote: Эмулятор по-видимому прямолинейно эмулирует поведение последовательного однобитного микроконтроллера ИК13хх.

это не микроконтроллер, секционный комплект периферийные устройства, память, АЛУ. 1302, 103,1306. У Трохименко об этом все хорошо рассказано.

Электромонтёр wrote: Нельзя ли ускорить работу, выполняя часть операций параллельно? Со слов Феликса Лазарева, в качестве АЛУ вообще используется однобитный сумматор.

Да там все однобитное, а ОЗУ это вообще последовательно расположенные каскады транзистор-конденсатор, которые с каждым тактом выталкивают один бит (один заряд), и только так и могу хранить данные - динамически их перемещая. Феликс по крупицам восстанавливал архитектуру в основном по книгам Трохимемнко, потом вскрывал ПЗУ микрокоманд фотографируя кристалл. Жалко что ему не пришлось переложить схему в Верилог, но и то что он уже сделал предостаточно. Мало того каталог микрофотграфий Феликс выкладывал, так что если есть люди хорошо разбирающиеся в топологии полупроводниковых структур, было бы здорово - оттранслировать это в Verilog. На zx.pk.ru такую бешеную работу проделали над кристаллами К580ВМ80 и К1801ВМ01, теперь у нас есть наследие отцов и дедов в Verilog хоть для синтеза, хоть для симуляции. Точнее некуда! Даже вроде бы работают над полной схемой, хотя кому это надо, если есть синтезируемые HDL.

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

Электромонтёр wrote: На МК-161 эмулятор МК-61 будет работать со скоростью одна операция в минуту...

Если не медленнее!

Программа на C++ несколько сложней, чем требуется. :-) Возможно, труд digitalinvitro по упрощению эмулятора поможет сделать код, который удобней перевести на ЯМК.

Увы, пока делаем на том уровне, который доступен для программирования. Ведь стоит царю Михаилу открыть для нас все вычислительные возможности купленных нами «Электроник» — и, как мы точно теперь знаем, этим тут же воспользуется враг и начнёт подменять значения синусов в каких-то там знаках после запятой. :-)

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

ПЗУ микрокода порядка 7К. ОЗУ в районе 2К должно хватить, пока расход ОЗУ составляет 1865 байт. Остального кода ну вполне может быть и на 3К. Так что влезете. А вот производительности 8051 думаю не хватит, если я ничего не путаю то msp430 на 25МГц на один цикл дает 4 сек. Если конечно я ничего не путаю, пока еще с производительностью есть сомнения.

Интереса ради мной была скомпилирована версия Сергея Вакуленко под AVR. На AVR единичный полный цикл эмулятора занимает 70 миллионов тактов процессора. На тактовой 20МГц каждое нажатие кнопки будет обрабатыватся порядка четырёх секунд. А 8051 примененный в МК-161 в 4 раза медленнее.

Код Феликса сильно не оптимизирован, не оптимизирован для embedded. В ходе оптимизации кода под msp430 выяснилось что один цикл на нем будет идти в районе 1,6 секунды на тактовой частоте микроконтроллера - 25МГц, и это не предел есть еще куда оптимизировать. Сергей заметил что Эмулятор Вакуленко содержит более емкий код, в частности в нем меньше делений например. 8051 примененный в МК-161 не эмулирует железо МК61, это симулятор - отсюда и повышенная скорость работы.

Я в своих контроллерах использую как скриптовый язык расширеный МК-61. Производительность с плавающей точкой IEE754 одинарной точности на тесте 8 ферзей - 3000 оп/с на МГц.

А именно в одинарной точности. Мы уже делали такой симулятор назывался он mk61avr и на нем я заметил что при прогонах тестовых программ - числа иногда не сильно но различаются. Оно и понятно 16 бит для fp маловато. А в МК-161 работает BCD арифметика, очень затратная. И не зря СЕМИКО так гордится своей прошивкой, вот там есть за что похвалить.

но мне для контроллера даже одинарной за глаза. Достаточно даже было бы и 24-х битной. Быстройдействие же моего варианта с двойной точностью в два раза ниже, и там претензий к точности никаких вообще нет осбенно по сравнению с МК-61. Во всяком случае мысль о написании библиотеки операций с плав. точкой в BCD мной была отброшена начисто.

A.L. wrote: Во всяком случае мысль о написании библиотеки операций с плав. точкой в BCD мной была отброшена начисто.

А жаль, я бы с удовольствием с кем нибудь разделил то кол-во работы которую для этого нужно проделать :)

Если требуется быстродействие, зачем на Си писать? Задача идеально ложится именно на ассемблер. Особых преимуществ у 16 и 32-битных архитектур перед 8-битной здесь быть не должно.

На МК-161 проблема лишь в том, что восстановление низкоуровневого ввода-вывода (не документированного Новосибирском) застопорилось. За исключением этого, это идеальный toolkit для эмулятора.

, более того, пишу на нём, когда это реально небходимо (даже на ARM-ах), но быстродействие и Си не взаимоисключающие вещи. Более того, на мой личный взгляд, современные компиляторы дают в общем случае очень хороший код, который может быть сгенерирован в двух вариантах - с упором на быстродействие или на объем кода. А в плане скорости и удобства написания - альтернатив вообще нет.
Опять же, основной тормоз в симуляторе МК-61 отнюдь не Си, а то, что все операции с числами производятся только с плавающей точкой.

С индикатором МК-152 то вроде разобрались для начала? С МК-161 песня особая, схем нет, две аппаратные ревизии, нужно иметь живую девайсину (а то и две с разными ревизиями) на эксперименты. А так там особо ничего особо сложного, кроме наличия свободного времени и железки.

«С индикатором МК-152 то вроде разобрались для начала?»

Увы, нет. Вы опубликовали свою модель. Но кода для W77LE512P пока нет. Будет код — смогу его проверить. Есть и программатор, и сами W77, и МК-152.

Когда заработает BIOS для МК-152, адаптировать его под МК-161 будет проще.

то его можно переписать на ассемблере, но четырехкратного роста скорости скорее всего не будет, а даже этого для МК-161 мало.

A.L. wrote: то его можно переписать на ассемблере, но четырехкратного роста скорости скорее всего не будет, а даже этого для МК-161 мало.

Тут вот какие мысли меня преследуют. Пока мы реализуем автомат как закрытый черный ящик что на Си что на ассемблере особого увеличения быстродействия ждать не приходится. Мы просто не понимаем что творится в нем. Сейчас очень сильно вгрызся в код работы IK13 комплекта. Что тут необходимо учитывать, существует поле переменных довольно большое выражающиеся байтом а именно

io_t R[IK13_MTICK_COUNT];
io_t M[IK13_MTICK_COUNT];
io_t ST[IK13_MTICK_COUNT];

, а это далеко не родная для msp430 разрядность. Я бы перевел бы может все это поле в слова, но 1. это резко поднимет планку ресурсов ОЗУ, 2. я не знаю как на функциональности отразится это перевод, вполне возможны какие то неурядицы с битовыми операциями, которые Феликс мог бы проводить над байтом, да скажем элементарно сравнил с нулем "< 0" и уже получается что мы щупаем бит знака напрямую а для слов и байтов он разный, плюс сдвиги с расширением знака. Вообщем не хотелось бы сразу же нарваться на несовместимость.

Микроинструкция 32 битная, Феликс закладывал с ней операции подозревая что компилятор вырулит на нужную битовую маску. Компилятор msp430 воспринимает указание двигать биты в микроинструкции на прямую, и само собой двигает их в двух словах микроинструкции синхронно. По хорошему нарисовать бы схему этого, хоть в Verilog перекладывай :) Тут нужен подход в крупноплановой оптимизации, так как вся логика IK13 реализована в эмуляторе в лоб. Тот же мультиплексор - это switch и понятно что это не самая удобная конструкция, выгодней было бы разложить через доступ к массиву. Но все это легко может исказить работу микросиквенсера набора, а это можно не сразу заметить. Так что меняю код, воспроизвожу вывод на экран и в тайне надеюсь что ничего больше не поломал, раз единичка вывелась на индикатор правильно. :)

В свете вышесказанного переложить его в ассемблер я думаю даст выигрыш, раза в три-четыре. Но для этого надо все осмыслить - понять схему. Иначе это схоластика и шаманский бубен. Но это действительно крайне мало и дела не решит. Тут надо уходит на платформу родную для 32 бит, например на stm32 или msp432.

Хитрый комплект. Насколько я помню (года два назад книжку смотрел) - там операции с данными производятся нибблами, поэтому если это действительно так, нужно переделать этот автомат из побитового сдвига и побитовой обработки в пониббловый. Вот тут быстродействие подпрыгнет. Только непонятно, насколько это реализуемо и придётся вникать в тонкости работы комплекта.

Там несколько уровней вложенности — синхропрограммы, микропрограммы. Сейчас оборудование эмулируется полностью, с помощью вскрытой прошивки. Если нижний уровень (микропрограммы?) вместо прошивки реализовать командами Си, быстродействие действительно должно повыситься. Конечно, это потребует очень внимательного изучения архитектуры советских ПМК.

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

Ассемблерный код как раз проще оптимизировать, чем сишный — где действуешь вслепую, пытаясь гадать, какой код сгенерирует компилятор. Можно даже такты подсчитывать, в самых критичных местах.

Реализация эмулятора в корпусе МК-161 упирается в то же самое, во что упёрлась Каллисто. Отсутствие информации о том, как считывать клавиатуру и отображать информацию на индикаторе.

AtH wrote: Если требуется быстродействие, зачем на Си писать?

Затык не в Си, а в эмуляции "черного ящика", по 560 эмулируемых тактов на одну команду МК61. Ассемблер здесь ничем не поможет.

иначе получается такая флешка :)
эмулятор

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/