да какая разница во сколько раз MSP430 выигрывает у 8051, если по вашим "экспертным" оценкам он должен солидно так проиграть.
выводы то какие? а выводы простые: весь ваш труд с вычислениями эффективности МК до сотых долей - ЛАЖА!


угу. в большинстве случаев достаточно оценить камень по жирному тесту drystone/wetstone и понять как он в математике. но это точно не должны быть умозрительные заключения с перемножениями чисел неясного происхождения.


ну а почему оценки нифига не кореллируют с практикой?


что-то вам чтение нетленки не помогает. может наоборот - у меня более правильная книга?


о. ну конечно. если добавить волшебное слово "только" - код любого проца будет "ровно такой же". с какой вероятностью интересующая нас переменная попадёт в эти счастливые 256 байт?
с 51-ым знаком крайне поверхностно.



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


ну так напиши - покажи класс. ну так, чтобы переменная не была ограничена какими-либо адресами.



а может ну её - эту оценку эффективности: запустили drystone и закрыли глаза на все технические мелочи?

В оценке ошибка, виноват. Выигрыш в коде у байтовой системы команд 8051
по сравнению с 16-разрядной составляет 1.22 (раздел 5.2 работы)
Поэтому имеем 1.22*0.73*1.0*1.15=1.02. Т.е они дают приблизительно равный объем кода.
Это подтверждают цифры Maxago..., который приводит данные по тесту switch...
где получено 1.17.
Согласись, что для прогноза 15% является допустимой погрешностью.
Вот так теория проверяется практикой.




Сгораю от стыда.
Написано Чехонте "Жалобная книга", а "Станционный смотритель" написал кто-то другой.
Но ведь никто не поправил...

Продолжаем работать над ошибками/ своими и чужими
В постановке задачи требуется выполнить инкремент 16-разрядной переменной по прерыванию/
Для обработчика прерывания маловато будет /поэтому в стеке ничего не сохраняем/ контекст не переключаем
Разработчики 8051 допустили ошибку или имели на то определенные соображения -
операция инкремента не является эквивалентом прибавления 1 и не влияет на флаги регистра состояния/
Поэтому код становится длиннее и страннее
mov A,tim0
inc A
jnz M
inc tim1
m: mov tim0,A
reti
Итого 10 байт/ Ничего другого ожидать от 8-разрядной древности нельзя/
Однако для байтового счетчика все таки 3 байта будет (на внутренней памяти)

Вчера весь день потерял на ненужные препирательства, достали.
Поэтому пропустил Ваши предложения.
По ним видно, что Вы единственный, кто ознакомился с M8.ZIP и
отметил непохожесть предлагаемой системы команд по сравнению с известными серийными 8-разрядными МК.
Из предложений остановлюсь, пока, на последнем.
Каждое принимаемое решение определяется ожидаемым результатом с учетом последствий принятого решения.
Я хотел добиться компактного кода – поэтому выбрал байтовую систему команд, 16-разрядная увеличивает объем кода по моим прикидкам в 1.22 раза (это один из результатов анализа rating.doc и писался он для целей оценки не конкретных моделей МК – заблуждение, а для оценки влияния архитектурных решений в системе команд МК и выбора наиболее оптимальных, а для этого нужны количественные, а не качественные оценки, пусть такие какие получились).
Далее, если выбрана байтовая система команд, то одноадресная как в 8051 Или другая.
Я выбрал стековую. Однако в нее ввел префиксную команду задания операнда, что позволило в рамках стековой архитектуры реализовать двух-адресные команды обработки данных (пересылка, унарные операции и модификация данных) и тем самым обеспечить сокращение числа команд до 0.73 по сравнению с 8051 (по моим прикидкам).
Выбор стековой архитектуры обусловлен еще и тем, что она хорошо сопрягается с трансляторами ЯВУ. Вспомним промежуточный P-код или Java байт-код, на который я ориентировался.
Переход на фиксированную длину 16-разрядов – это путь повторения AVR, его можно Чуть-чуть улучшить, но не радикально.
Форум не позволяет изъяснится подробно и доходчиво. Но, если есть понимание, то много слов не надо.
А 32-разрядность введена/ что бы посягнуть 8-разрядным ядром в область применения 32-разрядных МК/ а также иметь в системе команд возможность дальнейшего развития/
Пока. Об остальном подумаю.

Это смотрели? http://www.ultratechnology.com/chips.htm

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

На примере того же АВР и Си видим, что до сих пор идет бурное развитие средств оптимизации, потому что эта регистровая модель немного не вписывается в сложившиеся технологии генерации кода.


Имхо, проще и дешевле. Думается, что при введении команд (не псевдокоманд!), "каскадирующих" арифметику до 16/32 разрядов, может этот Ваш коэффициент 1,22  опять опустить ниже плинтуса Но это так - пальцем в небо.

И еще, можно АВР допилить до нужной кондиции так : разрешить операндам [Y+d] [Z+d] участвовать не только в операциях Load/Store. 

>>поток сознания иссяк

теорию потиху подгоняем. под некие сферические задачи в вакууме. а практика иногда показывает и 7 кратную разницу...

кстати, если ник правильно написать не можете сами - есть удивительная технология: Copy-Paste называется. попробуйте.


фигасе. ну вроде уже и теорию начали перекраивать, а всё туда же. http://www.atmel.com/dyn/resources/prod_do...nts/DOC1292.PDF тут атмел рвёт всех по размеру кода, хотя у них код нифига не 8-и разрядный.
неужто по предыдущей ссылке не сходили? неужто не увидели, что нет нет никакого увеличения в 1.22 раза!

ну и вопрос на засыпку: вот описали вы архитектуру, полностью определились со всеми разрядностями, количеством регистров, набором команд, расписали какие команды как и когда меняют флаги. и прочее прочее прочее. а что дальше?

Здравствуй LEKA/ Наконец-то пересеклись/ но с бабочками/ есть такие красивые яркие на М называются

К своему большому "сожалению" смотрел и автора Форта Charles Мура знаю/ но не лично
Поэтому стал сторонником стековой архитектуры в его интерпретации/ вывешено M8.zip
Что до судьбы перечисленных там проектов/ может тогда их время еще не пришло/ см выше об истории 8-разрядных МК


Форум не то место для основательного разговора/ Это не мозговой штурм/ не диспут - это ЧАТ
Если я имею свое мнение/ то изменить его могу только /// как и ты/ уже перешли
1/ Твои слова подтверждают мой тезис/ что любая архитектура / кроме подчеркнуто стековой/
требует специальной оптимизации/ которая решается в компилятор LCC GNU и иже с ними плохо
Возможно фирменные трансляторы для ххх86 обеспечивают большую эффективность
Однако открываю книгу "Использование ассемблера для оптимизации программ на Си" 2004 г
И читаю в предисловии "большинство серьезных приложений пишутся на /// и вызвано это тем/
что ни одно инструментальное средство программирования на ЯВУ не может дать максимального выигрыша///

Посмотри Глава 4 Там приведена реализация основных операторов ЯВУ в машинных кодах Как будто у меня списано

2/ Я предложил ввести //потактную// обработку данных до 32-разрядов на 8-разрядном ядре/
С одной стороны на будущее/ как возможность расширения//
С другой это дает многократный выигрыш в объеме кода по сравнению с серийными 8-битниками
а в производительности нет
Это плохо/ как решить пока не знаю

Сообщение отредактировал IgorKossak - Jan 20 2009, 18:28

По вашей рекомендации обратился к Кнуту (том первый страница далековатая но нашел///159я)
«МИХ автокод очень похож на машинный код существующих машин, но
Изящнее. Он выбран достаточно мощным для реализации алгоритмов программ на ЯВУ,
Но и достаточно простым …
Читатель должен изучить его с особым вниманием…»
И я о том же говорю. Присоединяюсь к просьбе классика, читайте внимательно http://moko.ru/mc/ M8.zip
reting.pdf для просветленных
А по МИХ коду с Кнутом не согласен. Аккумулятор/ индексные регистры//// маловато будет для изящности
МИХ код (не машинный код) должен быть как минимум 2-3-адресным/ с возможностью задания операторов в памяти/ и еще более чего///

Сообщение отредактировал vitja - Jan 20 2009, 13:50

1. Как читается так и пишется За кнопочки спасибо, но я привык больше ручками

2. Я исправил ошибку, а не результаты своей работы.
Вы можете признаться в своей ошибке. См выше. Ищите. Не найдете - никому не скажу.

3. Дальше надо читать М8.zip. Специально упакованный, что бы не лазали ламеры.
Однако. Почему нет. Смотрите здесь. (или поднять выше?)
На основе ... предлагается ... для тех, кому лениво вникать в 12 листов текста того, что указано
реферат - аннотация - тезисы, т.е. очень кратко:
- Универсальное процессорное ядро для 8-32 разрядных микроконтроллеров
- Система команд – стековая (патентно чистая)
- Объем ПЗУ до 64 К с возможностью расширения
- Объем ОЗУ до 64 К с возможностью расширения
- Производительность – 1 такт на байт команды (данного)
- Тактовая частота процессора до 500 МГц
- Площадь кристалла – при технологии 0.13 мк – точка на кристалле
- Потребление – в четыре раза меньше
- Имеется встроенный отладчик (трассировщик), 2-х канальный DMA

Обеспечивает сокращение программного кода по сравнению
с 32-разрядным ARM Thumb в два раза при равной с ним производительности,
превышет эффективность 8-разрядных серийных МК в 2-3 раза.

Все, lдальше будет позже, выдохся.

Сообщение отредактировал vitja - Jan 20 2009, 16:51

Товарищ размечтался. Причём он даже не знает ни одной фичи ARM7. Скорее всего никогда не видел листинги всех обсуждаемых им процессоров. А судит только поверхностно по системе команд. Бред.

А вообще, похоже на то, что он действительно учавствует в распиле бабла (российского?). Вот такие значит товарищи пилят наше бабло

что-то мой ник вы, Витья, ручками правильно через раз пишете. ручки не оттуда растут?


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


читал. ПРОНИКСЯ!


верю.


новая единица измерения производительности? такт на байт? и какую производительность имеют иные процессоры в этих единицах? а хватит ли такой производительности для декодирования mp3 на лету?


есть какие-нибудь доказательства этих цифр? особенно про 500 МГц интересно - на основе каких сведений получено это число? или опять - палец пососали? сколько триггеров получилось в нет-листе?


в четыре раза меньше ЧЕГО?????? кипятильника?


пока что имеются только высосанные из чего-то непонятного фантазии. чтобы говорить, что что-то там есть - как МИНИМУМ нужно построить HDL-модель нужного модуля/устройства. и только на основе результатов моделирования HDL-описания можно называть (с оговорками) и частоту, и площадь, и потребление.


какие-нибудь доказательства этого есть? или это всё на основе тех же оценок, несовместимых с практикой.

Зачем ходить по чужим граблям? Пример(Кнут): MIX --> MMIX --> ??? и где идеал? Лучше учиться прятать низкоуровневые детали конкретных архитектур от программистов - чтобы низкоуровневые ЯВУ(например Си) - могли, наконец, уйти на заслуженный отдых.

не уж то тоже присоединиться
на хоботе не вышло, так сюда придем
если что - есть ещё http://telesys.ru/ с их конференцией..

со стороны это смотрицца так, что некто пытается написать Талмуд (на диссер не тянет) о МК, рассматривая только МП в них, причём с до сих пор непонятной целью

а так бред, так как нету базы для оценки.. код для оценки высосан из пальца..
выбор МК для разработки на том же хоботе я вам тоже описал
и все дружно объясняли зачем никто не оптимизирует 8битники

Кнут: "Тем не менее, нужно признать, что в настоящее время MIX полностью устарел. Поэтому в последующих изданиях данной книги он будет заменен новым компьютером под названием MMIX (номер 2009)...
...Полный и повсеместный переход в данной книге от MIX к MMIX отнимет много времени, поэтому огромная просьба к добровольцам - окажите посильную помощь в этом деле. Между тем, автор надеется, что читатели согласятся подождать еще несколько лет и пока удовлетворятся устаревшей архитектурой MIX, которая все еще заслуживает внимания, поскольку обеспечивает среду для дальнейших разработок."

Пример альтернативного подхода - Эльбрус с Эль-76.