| Характеристика | MK61 | MK161 /152 | Z80 | AVR | MSC51 | ARM7 |
| Базовая разрядность данных | 48 | 64 | 8 | 8 | 8 | 32 |
| Кол-во РОН | 5/15 | 5/15 | 18/3 | 32 | 9 | 31 |
| Регистровые фреймы | Нет | Нет | Да | Нет | Нет | Да |
| Битовые операции | Нет | Нет | Да | Да | Да | Да |
| Логические операции | Да | Да | Да | Да | Да | Да |
| Арифметика с целыми числами | Нет | Нет | Да | Да | Да | Да |
| Арифметика с вещественными числами | Да | Да | Нет | Нет | Нет | Нет |
| Адресное пространство данных | Нет | Да | Да | Да | Да | Да |
| Прямая адресация | Да | Да | Да | Да | Да | Да |
| Абсолютная адресация | Нет | Да | Да | Да | Да | Да |
| Косвенная адресация | Да | Да | Да | Да | Да | Да |
| Кол-во условий ветвления | 4 | 4 | 8 | 20 | 8 | 15 |
| PIC (перемещаемость кода) | Нет | Нет* | Да | Да | Да | Да |
| Самомодификация кода | Нет | Нет | Да | Да** | Нет | Да |
| Косвенный переход | Да | Да | Да | Да | Да | Да |
| Цикловые конструкции | Да | Да | Да | Нет | Нет | Да*** |
| Авто инкременты (++)/ декременты (--) регистров РОН (SP и PC не входит) | ++ -- | ++ -- | ++ -- | ++ -- | Нет | ++ -- |
| Стековые структуры | 2 AS = 5 RS = 5 | 3 AS = 5 RS = 64 TS = 2 | 1 64K | 1 64K | 1 64K | 1 4Г |
| Обслуживание прерываний | Нет | Да | Да | Да | Да | Да |
| Формат инструкции 0, 2, 3 - адресный | 0/1 | 0/1 | 2/1 | 2/1 | 2/1 | 3/1 |
| Гибкий формат машинной инструкции | Да**** | Да | Да | Нет | Нет | Нет |
* - Перемещение кода между страницами возможно
** - Самомодификация кода для AVR осуществима только в старшем семействе AVR и связанна с необходимостью записи данных в EEPROM программ, а значит ограничено предельным кол-вом циклов записи и длительностью записи в EEPROM.
*** - Циклической конструкцией для ARM подразумевается блочная загрузка/выгрузка регистров в память, поскольку она является параметризированной командой то с некоторым приближением ее можно назвать итеративным процессом с задаваемым количеством итераций.
**** - В том виде в котором МК61 существует с прошлого века формат инструкции задан двумя типами с однобайтным операндом (адресом перехода) и без оного. Но это не помеха и формат может быть легко изменен например увеличением разрядности второго операнда, отчасти благодаря наличию "расшиваемого" декодера команд (микропрограммное управление). В отличии от MISC (чем МК61 скорее всего и является) и CISC - практика построения RISC зачастую подразумевает дешифрацию определенных полей команды на лету (в такте выборки инструкции) и смена формата инструкции даже в части операнда - прямое изменение аппаратуры дешифрации.
Так как видимо ядро МК61 не предполагалось использовать вне ветки калькуляторов разработчики пошли на многочисленные упрощения платформы MISC. Например стараясь сделать систему команд понятной для ввода программ не специалистом, заменили непосредственный набор константы на ввод ее по разрядно или осуществили ввод и хранение адресов перехода в двоично-десятичном, а не полностью двоичном виде (МК61 может "переваривать" в качестве адресов и полные бинарные данные строя адрес по тому же BCD принципу). Использование медленной элементной базы (и принципа передачи и хранения данных в ЗУ комплекса - последовательное кольцо с 4 фазным методом передачи) скорее всего и привело к отказу от ввода событийного управления вычислительным ядром, лишив таким образом ядро МК61 подсистемы обработки прерываний. Ориентация на скромный объем программ, диктуемых калькуляторными задачами, внес в схемотехнику МК61 отказ от вместительных ЗУ и исключение инструкций доступа к адресному пространству через абсолютную адресацию (да и не в писывалось это в модель передачи индиректных констант). Однако наличие в системе команд косвенных операций решают проблему доступа к ЗУ, как к памяти данных (К(И)ПМ) так и к памяти программ (КБПМ, КППМ). Плата за такой переход - необходимость постоянно держать свободным регистр указатель на адрес в ЗУ или сохранять значение регистра используемого для доступа на арифметическом стеке. Увеличение кол-во уровней стека возвратов так же возможны без особых изменений платформы.
Одна из особенностей МК61 заслуживает особого внимания, поскольку благодаря этому платформа находится на ранг ближе к ЯВУ чем любая из рассмотренных. Эта особенность - возможность реализации циклических структур командой FLМ XX, где М это четыре возможных итератора в регистрах РОН R0...R3, а XX адрес перехода в случае неравенства результата итерации нолю. Структуры FLM дают возможность организовать автоматичеcкий декремент итератора (надо заметить - только декремент) с последующим сравнением на достижения ноля и переходом по результатам сравнения. При этом не происходит изменения в арифметическом стеке ядра - что не маловажно. Инструкция FLM в МК61 выражает сходную конструкцию do-while-for на языке Си:
| do{ } while (i-- > 0); | while(i-- > 0){ }; | for(i=N;i<0;i--){ }; |
с одной не очень приятной особенностью итератор i никогда не достигнет ноля, так как его изменение в МК61 происходит в момент исполнения адреса перехода. И выход из цикла FLM всегда знаменуется равенством итератора 1, при этом количество циклов соответствует значению итератора на входе в цикл.
Хотелось бы заметить так же, что МК61 обладает такой интересной особенностью не свойственной стековым машинам как регистр предыдущего результата Х1 (попросту "откат" регистра Х), в некотором смысле это пятый по счету уровень стека. Для стековых машин, по мнению Каупмана, наличие уровневости арифметического стека менее определенного числа (точно не помню скорее всего это 16) приводит к снижению эффективности производимых на базе стека вычислений. В принципе стек как безадресное ЗУ действительно быстрее любого адресного ЗУ, если он реализуется на основе регистров, так как при этом как минимум отсутствуют дешифраторы столбца/колонки. Мало того что стек как физический объект быстрее чем ЗУ с произвольным доступом, но он еще и приближает ядро к ЯВУ в виду того, что при разборе арифметических высокоуровневых скобочных выражений они легко (см. Дикстра - "лекции по компиляторам") сводятся к стековому порядку вычисления. Кроме того стек как капсула с параметрами отправляемыми в процедуру, мало того что очень выгоден (ибо быстр) и может являться удобным возвращаемым из процедуры контейнером результатов (для стековых машин), еще и исполняет роль фрейма локальных переменных. Почти всегда скорость работы стека организуемого в ОЗУ разработчиков компиляторов ЯВУ не устраивает, заставляя плодить сущности вида fast call для передачи параметров в регистрах :). Но и регистры в МК61 точно так же присутствуют как и в сравниваемых платформах.
В остальном, как показывает таблица сравнения ядер, МК61 вполне самостоятельное, специализированное на вещественной арифметики вычислительное ядро. Тот факт что скорость вычисления для вещественных чисел ниже чем для целочисленных может быть восполнено наличием аппаратного блока вычислений с вещественными числами. Правда есть тут и своя "ложка дегтя" - в МК61 вещественная арифметика осуществляется в BCD формате, а адресация по BCD весьма и весьма расточительна :) так как использует не всю информационную емкость двоичных чисел. Емкость тетрады (4 бит) 2^4 = 16, из которых BCD использует 10 позиций (от 0000B до 1001B), оставляя за бортом 6, которые составляет 37.5% - треть общей емкости. А значит и приведенное к целому BCD, вещественное BCD число так же будет адресовать меньше ЗУ, чем бинарное целое. Эта "неприятность" может быть разрешена внесением в платформу бинарного формата целого числа или возможным переходом с BCD представления вещественных чисел (IEEE-854) в бинарное представление FP чисел (IEEE-754). Это было бы целесообразно еще и потому что BCD представление ощутимо увеличивает размеры аппаратных сумматоров из за необходимости контроля десятичного, а не бинарного переноса (суммирование младших разрядов для BCD чисел зависит от получаемого результата). Существует мнение что работа с BCD числами быстрее отчасти из за того что не требует перевода в десятичное представление при выводе :), от части из за того что работать с вещественным представлением в BCD намного проще, нежели в бинарном. Кроме того из за того что BCD представление напрямую отображает ряд чисел точность вычислений по сравнению с IEE-754 напрямую зависит от количества представленных разрядов. В принципе осуществить качественное и количественое сравнение сумматоров соответствующих друг-другу разрядностей на базе LUT не составит особого труда.
P.S. Как частенько бывает ошибки и неточности вкрадываются уже после публикации, но не ошибается лишь тот кто не работает. Правки вносятся. В комментариях к посту можно понять какие изменения и почему произошли.
М-м-м-да... Прочитал. Очень сложноваримый текст... Понял только, что ядро МК61 что-то типа FPU...
ОтветитьУдалитьКонечно я еще молод, но терминов BCD, ЯВУ, LUT я совсем не понял... :( Уважаемый гуру, Вы не могли бы их декодировать.
Интересное сравнение, хотя в некоторых пунктах можно поспорить. Например, только по таблице:
ОтветитьУдалитьБазовая разрядность - не ограничена, мы же не конкретные реализации рассматриваем. И оперировать будет правильнее с десятичными разрядами.
Битовые операции - есть, хотя в МК-52/61 они практически бесполезны.
Арифметика с целыми числами - под вопросом, скорее в МК отсутствует искусственное разделение на целые и вещественные. Но при косвенном обращении и т.п. выполняется автоматическое, на уровне ядра, приведение типа, что далеко не во всех процессорах есть.
Прямая адресация - есть.
Формат инструкции - 0 или 1 адрес.
Ну и с системой команд МК-152/161 неплохо бы сравнить. Может в http://community.livejournal.com/mk_152 эту статью разместите?
В споре рождается истина.
ОтветитьУдалитьБазовая разрядность - по хорошему надо было бы сравнивать не только МК61 но и ряд Б3-34, МК-54 и т.д., но более менее полноценные данные имеются именно по МК61/52.
Битовые операции, а что Вы понимаете под битовыми операциями? Я подразумевал пересылки битов, сдвиги и переходы по битам (shift, R.x<-> T, goto if X.b) их в МК61 нет. А логику я отметил, хотя ее наличие в МК61 не совсем то что я подразумевал бы под логическими операциями. :)
Целые числа - замечено верно под большим вопросом, инкремента/декремента на 1 не достаточно что бы называть арифметикой с целыми.
Привидение типа - да конечно особенность интересная, но мера то вынужденная иначе просто нет возможности адресоваться в памяти. А вот то что РОН у МК61 находится в памяти это бы можно было бы отметить. Не одно из перечисленных ядер если я не путаю - адресоваться косвенно к РОН не умеет.
Прямая адресация - тут я ошибочку дал ПРЯМАЯ АДРЕСАЦИЯ действительно есть - сиречь регистровая. Имел ввиду я конечно же абсолютную адресацию и вот ее то у МК61 нет. Не порядок конечно с табличкой придется мне добавить строчку АБСОЛЮТНАЯ АДРЕСАЦИЯ и снестись на Ваше замечание.
Формат инструкции - я специально обозначил что случись завтра изменение в платформе и перейди МК61 на двухбайтный операнд для адресов переходов - небо не упадет на голову :) все останется на своих местах так как декодер использует микрокод, а через микрокод внести правку ничего не стоит. Гибкий формат инструкции прерогатива MISC и CISC. RISC-у как правило приходится жертвовать разносолами и исполнять инструкцию с лету, желательно за такт, а это конечно же в первую очередь накладывает жесткие требование на инструкцию, вплоть до расположение полей кодирующих адрес регистра в РОН. Если завтра в Атмел придет разнарядка :) живенько расширить адресное пространства - то придется вернуться на уровень HDL и начать пляски оттуда :)
С системой МК152/161 плотно не знаком, если у Вас есть ответы на все строки таблицы, сочту за честь внести в нее МК152/161.
Насчет разместить - конечно, буду рад, но как это сделать честно говоря не представляю. Отослать кому то "гранки" статьи?
kosmoflyko:
ОтветитьУдалитьТы действительно прав, исправился и надеюсь что еще одна статья уже по поводу терминов и понятий будет более понятной. Но конечно я очень рад что ты пробираясь через лес неудобоваримых терминов таки дочитал статью до конца.
stepanishchev:
ОтветитьУдалить> Формат инструкции - 0 или 1 адрес.
Да конечно - замечание принимается сразу не сообразил к чему относится 0 и 1.
Дак это ведь и не спор вовсе. И, если что, копирастией не страдаю, так что можете не ссылаться по каждому случаю. А то окончательную таблицу будет трудно разобрать.
ОтветитьУдалитьБазовая разрядность советских ПМК, если уж на них ориентироваться - 8 десятичных разрядов мантиссы, что примерно соответствует 26-27 двоичных разрядов. Хотя, если брать полное число во внутреннем представлении, то 4*12=48. В Б3-34 столько же, разрядность и диапазон ведь не изменялись. Но только впрямую их сравнивать с чисто двоичными процессорами нельзя.
С битовыми операциями - Вы абсолютно правы. Конечно, имелись в виду логические, а про их "полезность" в МК-52/61 уже высказывался. Но отдельной строки "логические операции" в таблице нет.
Целые числа в МК - не только автоинкремент и автодекремент в регистрах. По сути, там вообще нет отдельных типов данных, как в других вычислительных устройствах. Что гораздо правильнее, если хорошо подумать.
Цикл в ПМК выполняется по вещественному значению. Косвенную адресацию тоже можно было выполнять без приведения типа, допустим, адресоваться по целой части. Или вообще по ближайшему целому в соответствии с правилами округления - на страх врагам. :)
Абсолютной адресации данных в ПМК действительно нет. В МК-152/161 есть, но об этом лучше отдельно.
Кстати, другие столбцы особо не смотрел. Из сразу бросившегося в глаза - в Z80 есть не только команды инкремента и декремента РОН, но также пересылки с автоинкрементом и автодекрементом: LDI, LDIR, LDD, LDDR; команды поиска CPI, CPIR, CPD, CPDR; а также подобные команды ввода-вывода.
Если уложить информацию про МК-152/161 в строки таблицы, то примерно так:
ОтветитьУдалитьБазовая разрядность данных - 64 (хотя точнее, 12/14 десятичных разрядов мантиссы и 2 - порядка)
Кол-во РОН - 5/15
Регистровые фреймы - Нет (хотя в прерывании автоматически переключается контекст задачи - вместе с 5/15 РОН)
Битовые операции - Нет
Арифметика с целыми числами - Отдельной нет
Арифметика с вещественными числами - Да
Адресное пространство данных - Да
Прямая адресация - Да
Абсолютная адресация - Да
Косвенная адресация - Да
Кол-во условий ветвления - 4
PIC (перемещаемость кода) - Постранично
Самомодификация кода - Нет (хотя возможна подгрузка оверлеев из программы через функции ДОС)
Косвенный переход - Да
Цикловые конструкции - Да
Авто инкременты/декременты - Есть
Стековые структуры - 3 (основной стек=5, возвратов из п/п =64, контекст задачи для прерываний =2)
Обслуживание прерываний - Да (имеется очередь прерываний - линейная структура с учётом приоритетов = 16)
Формат инструкции - 0/1 адресный
Гибкий формат машинной инструкции - Да
Не уверен, что имеет смысл загонять это в общую таблицу. Но для ознакомления с упомянутой выше возможностью расширения системы команд МК-61 может быть полезно. :)
Опубликовать статью в ЖЖ могу и я, просто скопировав текст отсюда, но не думаю, что это будет правильно. Зарегистрироваться там дело пары минут, после чего можно сразу вступить в mk152 - членство открытое. Затем создать новую тему о сравнении архитектур и скопировать нужную информацию.
ОтветитьУдалитьКстати, краткое описание Вашей разработки там уже есть: http://community.livejournal.com/mk_152/21410.html
У стандартного mcs51, у которого 12 циклов на команду, если он с внешним ОЗУ данных и оно же внешнее ОЗУ команд, самомодификация возможна, если RD и PSEN на вентиль "и" завести. Вроде у Атмела appnote был такой, со схемой, хотя сейчас найти такой не смог, может он и не у атмела был. Как более высокоскоростные себя ведут - не знаю.
ОтветитьУдалитьstepanishchev:
ОтветитьУдалитьБазовая разрядность.
Тут ведь какая штука - если программист захочет то он может применять BCD арифметику на все указанных в таблице платформах. Я согласен что в этом случае диапазон отображения числа пострадает (но не базовая разрядность) - но нынешняя вычислительная техника живет в двоичном мире, сравнивать все таки надо стандартный для обоих систем контейнер. Вот если бы мы сравнивали Сетунь и Z80 - вот тут прямого сравнения быт не может.
Целые числа и вещественные числа.
С точки зрения пользователя, конечно все равно как представлено значение в памяти. Но с точки зрения аппаратуры - огромная разница. Взять хотя бы Ваш пример адресации по BCD я думаю, что Вы понимаете что между I и I+1 в формате BCD не всегда находится 1 ячейка стандартного ЗУ с стандартными же дешифраторами адреса (в бинарном формате). Это первое. Второе это то что аппаратуры на дешифраторы BCD и сумматоры, а так же умножители уйдет больше - соответсвенно вырастет и потребление. Ну и главный вопрос имея разрядность 48 бит (пусть так) как оперировать меньшими величинами? Как оперировать байтом? Словом? Даже при записи в LCD придется лишнее отрезать - возникает вопрос какой смысл в этой избыточности? Она позволяет нам восстановить значение как все избыточные коды? Нет, не позволяет. Тогда что же?
stepanishchev:
ОтветитьУдалитьпо поводу статьи.
Я совершенно не против, если Вы скопируете в mk_152 данную статью или таблицу сравнения. Если Вам некогда, я попросил это сделать Vitasam у него есть акаунт в ЖЖ и членство в МК_152. За приглашение в мк_152 спасибо. За этой конференцией я слежу уже очень давно, видел что описание разработки mk61avr там есть (разработка не только моя, нас двое и второй участник Vitasam как раз таки и отвечал в комментариях к ссылке). Завести второй акаунт в ЖЖ мне будет очень неудобно - можно сказать с одним то еле справляюсь :)
zuchodrig:
К сожалению информации по самомодификации кода в x51 не нашел. Хотелось бы почитать про это.
Спасибо за дополнение к таблице. Думаю, не будете возражать, если сделаю ссылку с нашего сайта?
ОтветитьУдалитьБазовая разрядность
Впрямую сравнивать ядро МК с двоичными микроконтроллерами тоже нелогично. Если в Сетуни троичная система, то в ядре МК она десятичная. И не имеет значения, как оно реализовано на существующей элементной базе. Если не указывать десятичные разряды, можно посчитать, сколько бит должна иметь мантисса в двоичной машине для обеспечения аналогичной погрешности вычислений.
Давайте разделим ядро МК как абстракцию и его конкретные реализации. Абстрактное вычислительное ядро структуры МК вообще не имеет ограничений ни по диапазону, ни по разрядности, чем и замечательно. Вполне можно представить реализацию МК-61 с теми же 15 регистрами данных и 5 стека, но разрядностью, допустим, в сотню знаков и с десятизначным порядком. В структуре команд и функциональной схеме это абсолютно ничего не изменит.
Целые и вещественные числа
Думаю, путаница здесь возникает от попытки смотреть на мир исключительно через двоичную систему. Но ядро МК - полностью десятичная ЭВМ. Неужели Вы думаете, что в МК-152/161, к примеру, не используется треть памяти. Нет, конечно. При эмуляции ядра МК непрерывная последовательность десятичных адресов виртуальной машины превращается в столь же непрерывную шестнадцатиричных адресов физической памяти.
Не представляет принципиальных сложностей и аппаратная реализация таких операций. А вопрос о потреблении и т.п. не имеет большого смысла, поскольку технологически можно добиться гораздо большего выигрыша. Другой вопрос, что выпуск микросхем подобной архитектуры мелкими партиями будет нерентабелен.
Как представлять байт в системе МК - см. логические команды МК-152/161. Конечно, не самый оптимальный способ. Но сейчас во многих системах байт по умолчанию занимает 32/64-битное слово в памяти, если специально не указать обратное.
Простите, не совсем понял про приписываемый мне пример с BCD адресацией. Имел в виду, что при косвенной адресации к памяти модификацию регистров с приведением к целому в МК можно было бы вообще не проводить. Допустим, при содержимом "1,5" адресовать первый регистр или адрес, при "12,34" - двенадцатый и т.п. Приведение к целому значению здесь не обязательно, это лишь историческая особенность, а не принципиальный момент для ядра.
Кстати, работа с целыми числами в МК-61 есть - команда K [x]. :)
Самомодификация кода в 51
Речь шла о трюке, когда внешнее ОЗУ используется как память программ, одновременно эта же область делается доступной как память данных. Поскольку 51-й можно использовать не только как микроЭВМ с гарвардской архитектурой и внутренним ПЗУ, но и как обычный универсальный процессор с внешней памятью.
to stepanishchev:
ОтветитьУдалитьДо тех пор пока МК61 существует большей своей частью как виртуальная машина, сравнение между аппаратными платформами и ядром МК61 должно вести с долей абстрактности, впрямую можно сравнить только заложенные общие принципы как то - кол-во регистров, способы доступа и пр. Касаясь же аппаратных, физических принципов реализации мы вынуждены констатировать что МК61 использует для вычислений схемотехнику того ядра на коем реализована. А реализована она на двоичной платформе и на двоичной арифметике, с последующей коррекцией результата. О Сетуни мы этого сказать не можем - Брусенцов в базу и в физическую (математическую) и в аппаратную (ферритовые колечки могут иметь три состояния +,-,0) заложил троичную систему счисления. Это важно Сетунь не симулирует троичную логику, она в ней живет. По этому я считаю и это глубокое мое ИМХО - БАЗИС имеет значение. Об абстрактном уровне. Конечно как и любая виртуальная машина МК61 практически мало зависит от аппаратуры на которой она реализована, я думаю Вы понимаете что я имею ввиду функционал. Наличие десятичной арифметики и только вещественных чисел это абстрактный уровень, физический же уровень диктует нам двоичный доступ к ресурсам и соответсвенно ограничения и трансформации выполняемые на числом при доступе к ресурсам. Ограничения - обрезка числа до целого, трансформации - трансляция в двоичный полный адрес соответствующий платформе. Исходя из этого рискну предположить :) о значительном снижении эффективности ядра, по сравнению с его реализацией на базе двоичной арифметики или наоборот с его реализацией в том виде как есть на аппаратуре разрешающей 10-уровневое кодирование единичного сигнала. Последние хоть и возможно, но энергетически затратно (на данном этапе развития электроники), а кроме того помехонеустойчиво. Я подвел к этому потому что ни секрет наверное для Вас десятичная арифметика применяется и на старом x86 и на современнейшей Power 6. И в обоих присутствуют команды либо арифметики с десятичными представлением, либо коррекции двоичного числа в BCD или BCD packed представление. И это честно, на мой взгляд. Хочешь эффективности работаешь с двоичным представлением, хочешь простоты, точности, скорости перевода в литеральную форму - с BCD. Я могу заблуждаться, как и все нормальные человеки, но реализация в прошлом веке арифметики именно на базе BCD для МК61 присследовало как раз таки последнюю цель. Вы говорите технологически можно добиться большей выгоды от не эффективного ядра. О какой выгоде идет речь? Приближение платформы к человеческим принципам выполняется за счет уровня абстракции, это понятно, но в чем же выгода внедрения единственного формата хранения и обработки данных, притом вещественного в понимании человека? Тот же уровень абстракции достигается наличием команды AAA для x86.
О представлении байта в системе.
Согласен, более того на некоторых платформах не реализован доступ к байту как к минимально возможной адресуемой величине совсем, но в таких платформах всегда имеется возможность его корректно выделить (маскировать и сдвинуть или привести к формату signed байт). Если реализовывать возможностями только ядра МК61 строчные процедуры (парсинг, сортировку и прочее) мы столкнемся с тем что нам нечем арифметически воздействовать на символ в байтовых форматах ASCII (KOI-8) (хотя бы элементарно поднять регистр). Для этого того мы вынуждены будем представлять символ - тремя разрядами числа что бы реализовать коды выше 99 и трансформировать символы строки к BCD виду. В какой-то степени логические операции в формате МК61 восполняют потерю от BCD, но пользоваться ими мягко говоря неудобно.
to stepanishchev:
ОтветитьУдалитьвынужден разбить на две части не лезет понимаете ли в 4096 ( и здесь степень двойки!!!) :)
Приписываемый Вам пример с BCD адресацией.
:) Вы подошли к этому вопросу озвучив действие команд косвенной адресации. Я лишь попросил Вас до озвучить далее что при доступе по BCD к памяти - эволюции адреса имеют места быть, ввиду того что память то хотелось бы расходовать оптимально. Что я имею ввиду - можно адрсесоваться к памяти без обрезки до ближайшего целого и без трансляции в двоичный адрес (максимально быстро), но все прекрасно понимают что это ведет к потери части адресного пространства (не экономично). Итог - не эффективно. Какими технологическими приемами в этом случае эффективность можно восстановить? :) Даже в случае FPGA боюсь это невозможно сделать.
Работа с целыми.
Отсечение до целых, это все таки работа с вещественным числом. Я подразумевал бы под работой с целыми - целочисленное деление и умножение. Деление на платформе МК61, даже заведомо целочисленных значений (не кратных) приведет к получению вещественного результата. :).
Самомодификация кода на MCS51.
Отлично я отмечу данную особенность в таблице. То что 8051 позволяет исполнять программы из внешнего ОЗУ я знал, но думал что снижение количества тактов на цикл в модификациях 8051 привело к невозможности записи во внешнее ОЗУ при исполнении из него кода.
В таком случае почему на сайте Арбинады говорится о технолгической невозможности использования ОЗУ данных для хранения нативных участков кода?
О выпуске МС большими партиями - я не говорю об ASIC для прототипирования есть более доступная и дешевая база FPGA, причем уход от практики использования микроконтроллеров к FPGA все более очевидная тенденция. Кроме того я вообще не говорю о коммерческой составляющей вопроса, для меня это хобби.
to stepanishchev:
ОтветитьУдалитьна счет ссылки
Конечно возражать не буду, даже сочту за честь :)
P.S. А Вам не кажется что разработчики МК61 оставили такую возможность работы с двоичными числами? Внимательно посмотрел на логические операции и думаю что реализация поверх BCD контейнера BIN чисел вписывается в МК61, вот только префикс бы я сменил с 8 например на F. Как считаете?