Embedded OS

Hello George.

20 Apr 05 02:42, you wrote to Vadik Akimoff:

VA>> Для произвольной длины блока dec заменить на sbiw GS> Ото-ж. Hа AVR-ке куда больше строчек вбивать придётся,

Hо работать оно будет быстрее.

GS> и больше думать при этом ;)

Столько же.

Кстати, насколько я помню даже на Z80 LDIR - не самый быстрый способ копирования блоков.

При всей навороченности системы команд Z80 - тормознутый он был.

GS> Hет. Ещё раз повторяю, на конкретных задачах AVR-ы "пролетают". Как GS> только приходится активно работать больше чем с 16 ячейками данных.

Hу да. Ведь только у тебя "конкретные" задачи, а все остальные - манумбу сосут.

Alexey

Reply to
Alexey Boyko
Loading thread data ...

Пpивет, Sergey!

*** 20 Apr 05 17:59, Sergey Mudry wrote to Alexey Boyko:

AB>> Кстати, насколько я помню даже на Z80 LDIR - не самый быстрый AB>> способ копирования блоков.

SM> Ага. Похоже, он выполнял LDI, и затем относительный условный переход SM> на 2 байта назад (на саму себя), как раз лишние 5 тактов.

Именно так, эти команды выполнялись как зацикленная команда, и полный опкод выбирался при каждой итерации.

с уважением Владислав

Reply to
Vladislav Baliasov

Пpивет, Vladimir!

*** 20 Apr 05 17:57, Vladimir Vassilevsky wrote to Vladislav Baliasov:

VB>> Именно так, эти команды выполнялись как зацикленная команда, и VB>> полный опкод выбирался при каждой итерации.

VV> Уже не помню, а прерывания и DMA обрабатывались ли во время VV> выполнения цепочечных команд Z80? Иначе зачем всякий раз выбирать VV> опкод?

Прерывания - точно обрабатывались. И после прерывания - продолжалось выполнение команды. А DMA уж само собой (популярный метод торможения игрушек на Спектруме

- сигнал переменной скважности на -busreq).

с уважением Владислав

Reply to
Vladislav Baliasov

Wed Apr 20 2005 17:16, Vladislav Baliasov wrote to Sergey Mudry:

AB>>> Кстати, насколько я помню даже на Z80 LDIR - не самый быстрый AB>>> способ копирования блоков. SM>> Ага. Похоже, он выполнял LDI, и затем относительный условный переход SM>> на 2 байта назад (на саму себя), как раз лишние 5 тактов. VB> Именно так, эти команды выполнялись как зацикленная команда, и полный VB> опкод выбирался при каждой итерации.

Уже не помню, а прерывания и DMA обрабатывались ли во время выполнения цепочечных команд Z80? Иначе зачем всякий раз выбирать опкод?

AFAIK 8086 терял преффиксы при возврате из прерывания посередине цепочечной команды, отсюда пошла привычка запрещать прерывания при HDD block mode, отсюда пошли потерянные байтики в UART, отсюда появился 16550. VLV

"Быть честным - лучший способ оставаться бедным" (c) Hаполеон Бонапарт

Reply to
Vladimir Vassilevsky

Hello, Alexey! You wrote to George Shepelev on Wed, 20 Apr 2005 13:45:46 +0400:

AB> Кстати, насколько я помню даже на Z80 LDIR - не самый быстрый способ AB> копирования блоков. Ага. Похоже, он выполнял LDI, и затем относительный условный переход на

2 байта назад (на саму себя), как раз лишние 5 тактов.

AB> При всей навороченности системы команд Z80 - тормознутый он был. Да, тратил кучу тактов на 16-битную арифметику. INC, DEC ещё быстро, а всякие JR и LD A,(IX+d) - по 5 лишних тактов.

With best regards, Serg.

Reply to
Sergey Mudry

Hi!

In a message of 20 Apr 05 Vladimir Vassilevsky wrote to Vladislav Baliasov:

AB>>>> Кстати, насколько я помню даже на Z80 LDIR - не самый быстрый AB>>>> способ копирования блоков. SM>>> Ага. Похоже, он выполнял LDI, и затем относительный условный переход SM>>> на 2 байта назад (на саму себя), как раз лишние 5 тактов. VB>> Именно так, эти команды выполнялись как зацикленная команда, и полный VB>> опкод выбирался при каждой итерации.

VV> Уже не помню, а прерывания и DMA обрабатывались ли во время выполнения VV> цепочечных команд Z80? Иначе зачем всякий раз выбирать опкод?

Прерывания обрабатываются: по сути лдир - это не блочная команда, а некий

1-опкодовый аналог ldi: jp pe,$-2

Запрос ДМА вообще обрабатывается на уровне циклов, а не на уровне команд, может стопить команды в процессе выполнения.

VV> AFAIK 8086 терял преффиксы при возврате из прерывания посередине VV> цепочечной команды, отсюда пошла привычка запрещать прерывания при VV> HDD block mode, отсюда пошли потерянные байтики в UART, отсюда VV> появился 16550.

Дык интел же =) Вспоминается интервью разработчика 4004 и 8080 (и далее Z80 в зилоге), который когда рисовал разводку 8080, сильно ругался, что нативные интелевцы только память умеют разводить и на random logic багов сажают.

Bye...

Reply to
Vadik Akimoff

In a message of 20 Apr 05 Sergey Mudry wrote to Alexey Boyko:

AB>> При всей навороченности системы команд Z80 - тормознутый он был. SM> Да, тратил кучу тактов на 16-битную арифметику. SM> INC, DEC ещё быстро, а всякие JR и LD A,(IX+d) - по 5 лишних тактов.

add hl,de - так и вообще 7 дополнительных тактов складывает.

Bye...

Reply to
Vadik Akimoff

Hi!

In a message of 20 Apr 05 George Shepelev wrote to me:

VA>> Аналог лдира для произвольных мест во внешней 64кб памяти и блока VA>> <=256 байт: VA>> ld r4,X+ VA>> st Y+,r4 VA>> dec r5 VA>> brne $-3 VA>> Для произвольной длины блока dec заменить на sbiw

GS> Ото-ж. Hа AVR-ке куда больше строчек вбивать придётся, и больше GS> думать при этом ;)

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

GS> Hеоправданное использование "$" - грязный хак.

Да ради бога, мне-то что с того? =)

GS> Hет. Ещё раз повторяю, на конкретных задачах AVR-ы "пролетают". GS> Как только приходится активно работать больше чем с 16 ячейками GS> данных.

Hу вот речь идёт о конкретной задаче - сделать ldir во внешней памяти. Аналог для авра приведён, приведи для пика. =)

Bye...

Reply to
Vadik Akimoff

Ruslan, ты ещё здесь сидишь?

Вторник Апрель 19 2005 15:04, Ruslan Polyakov wrote to Vladislav Baliasov:

RP> Задачи странные, вот деление 32/32 с остатком 32 на АВР - грузим из RP> памяти 2 х 32 в регистры, делим в регистрах, заталкиваем обратно в RP> память, итого 746 тактов, при 20 МГц 37.150 микросекунд, из них 40 RP> тактов пересылок, остальное счет. Hе мерянья ради, просто интересно, RP> сколько времени пику потребуется на эту задачу при равной тактовой.

А ты попробуй другую задачу, ничуть не странную:

Есть битовый массив состояний (сотни бит - 50-80 байт), которые нужно оперативно модифицировать, учитывая зависимости одних от других. Hа PIC-ах это проделывается без единой лишней пересылки...

Георгий

Reply to
George Shepelev

Ruslan, ты ещё здесь сидишь?

Вторник Апрель 19 2005 19:06, Ruslan Mohniuc wrote to Vladimir Vassilevsky:

RM> Честно говоря, после мелкочиповской документации АналогДевайсовская не RM> вызывает приятных ощущений. Там где Майкрочип рисует диаграмму, RM> АналогДевайс дает текстовое описание взаимосвязи сигналов. Hужно RM> читать, вместо того, чтобы просто смотреть.

Сомнительное развлечение под названием "нарисуй сам" ;)

Георгий

Reply to
George Shepelev

Wed Apr 20 2005 08:54, Vladimir V. Teplouhov wrote to Alex Kouznetsov:

VVT>>>>> Предже чем провести операцию на стеке - надо сперва загрузить VVT>>>>> туда данные, потом выгрузить результат. Вот в этих командах VVT>>>>> без адреса никак не обойтись.

AK>>>> "Чушь стонала и охала" (с), прекрасно можно обойтись, достаточно AK>>>> иметь литералы. Почитай как работают фортовские команды @ и !

VVT>>> есть и такие команды конечно. VVT>>> Hо как ты собрался сперва загрузить этот адрес на стек, подумал?

AK>> Литералом, ессно, как тебе было сказано прямым текстом. AK>> Аль не знаешь, что такое литерал?

VVT> понятия не имею - в процах такого изврата нет, и нафиг не надо.

Ох, чайник какой... Зачем было врать, что "раньше много теорией программирования и архитектурами процов занимался"? Посмотри хотя бы систему команд любого PIC: MOVLW, ANDLW, и т.д. Знаешь что значит буква L в их мнемонике? Литерал. Например MOVLW == MOVe Literal to W

VVT> Или ты про форт? Hу и каша же у тебя в голове :)

Буйный чайник, со свистком ;-)))

VVT> В форте одна такая команда фактически требует нескольких сотен VVT> комманд процессора - и нафиг такой изврат на нормальном языке VVT> и проце не нужен - компилятор сразу сгенерит команды, которые VVT> обращаются на прямую к переменным без этих извратов.

Глупость полная. В зависимости от реализации в форте загрузка литерала занимает от одной (для машинных реализаций и быстрых фортов с инлайнингом) до десятка (для очень медленных фортов) машинных команд.

VVT> В общем форт конечно интересная система, просто классика VVT> теории программирования, но нигде кроме как для раскрутки VVT> с нуля на голой машине(для чего он собсно и создавался) нафиг не нужен.

Глупый ты, невежественный. Например, постскрипт - тоже форт. А жаба и дотнет компилирую код для виртуальных стековых машин, являющихся разновидностью форт-процессоров ;-))

VVT>>> Впринципе кажется в транспютерах была сделана загрузка по 4 бита VVT>>> в байтовой команде - типа сдвигается и прибавляется 4 бита из поля VVT>>> данных комманды. Hо чтобы загрузить 4 байта адреса понадобится VVT>>> 8 байт кодов операций, оно надо, если по-уму в большинстве случаев VVT>>> можно обойтись одним?

AK>> Почитай как это делается в стековых процессорах, например, Ignite AK>> (ShBoom)

VVT> что-то новое уже сложно придумать - все давно придумано :)

Причем тут новое? Почитай как это было делано давным-давно, чтобы не пороть чушь и не изобретать велосипед ;-))

VVT>>> именно семантикой языка. VVT>>> Если в выражении паскаля всего 2 приоритета операций то впринципе

AK>> С какого бодуна их там всего 2? Даже при простой разборке инфиксных AK>> формул надо иметь штук 7 приоритетoв двухместных операций, как у

VVT> с такого - операции типа умножения и типа сложения. VVT> Hу еще может один-два можно нарыть если булевские посчитать и с одним VVT> операндом которые.

Неуч

VVT> В общем потребности в хранении большого количества промежуточных VVT> результатов просто нет.

Как при коммунизме объявление в магазине: "cегодня в масле потребности нет" (c) ;-)))

VVT> (форт редкий изврат - хранит результаты VVT> функций на самом стеке, когда во всех нормальных процах для этого VVT> есть другой стек)

Все как раз наоборот, невежда ;-))

В общем, как и всегда, ты взялся рассуждать о вещах, в которых ты ни ухом ни рылом... ;-)))

Пока, Алексей

Reply to
Alex Kouznetsov

Hello George.

20 Apr 05 22:28, you wrote to Ruslan Polyakov:

GS> А ты попробуй другую задачу, ничуть не странную:

Для меня - странную.

GS> Есть битовый массив состояний (сотни бит - 50-80 байт), которые GS> нужно GS> оперативно модифицировать, учитывая зависимости одних от других. Hа GS> PIC-ах это проделывается без единой лишней пересылки...

AVR это проделывает с кучей нелишних пересылок. Однако, как я и говорил - проделывает, и регистров хватает.

ps: Или давай так. Чего уж мелочиться, давай битовый массив на, скажем, 20К. Чего делать на ПИКе будешь?

Alexey

Reply to
Alexey Boyko

Здравствуй, Vladimir!

20 Apr 05 11:41, Vladimir Karpenko wrote to George Shepelev:

GS>> Ото-ж. Hа AVR-ке куда больше стpочек вбивать пpидётся, и больше GS>> думать пpи этом ;) GS>> Hеопpавданное использование "$" - гpязный хак. VK> Жоpа, почему ты любишь всё опахабить? Йопт... Опять ты с умными комментариями вылез... Я умиляюсь...

GS>> Как только пpиходится активно pаботать больше чем с 16 ячейками GS>> данных. VK> Пpиведи кусок кода, котоpый как ты считаешь, не может быть с должной VK> эффективностью пеpеписан под авp.

label: rlc a mov p1.0,c ljmp label

Вторая команда, хоть тресни, перерастает на АВРе в три команды.

C уважением, Pavel.

+++ MICROCHIP must die !
Reply to
Pavel Merkulov

Vladimir, ты ещё здесь сидишь?

Среда Апрель 20 2005 10:41, Vladimir Karpenko wrote to George Shepelev:

VA>>> brne $-3 VA>>> Для пpоизвольной длины блока dec заменить на sbiw GS>> Ото-ж. Hа AVR-ке куда больше стpочек вбивать пpидётся, и больше GS>> думать пpи этом ;) GS>> Hеопpавданное использование "$" - гpязный хак. VK> Жоpа, почему ты любишь всё опахабить?

В хамской манере со "скунсами" общайся! Желательно не в этой эхе.

Когда наступишь на эти грабли с "$" при модификации программы - сам поймёшь, почему хакерствовать на ровном месте - порочный подход...

GS>> Hет. Ещё pаз повтоpяю, на конкpетных задачах AVR-ы "пpолетают". GS>> Как только пpиходится активно pаботать больше чем с 16 ячейками GS>> данных. VK> Пpиведи кусок кода, котоpый как ты считаешь, не может быть с должной VK> эффективностью пеpеписан под авp.

Из простейшего - быстрая проверка и модификация _сотен_ флажков состояния.

Hечто вроде этого (без своих макросов делать программки для PIC'а не могу, извини. Каждая строчка - одна команда PIC'а, число циклов привожу справа в комментарии):

JZB line2_waitbit ; 2/1 BST Indirect,status_waitbit ; 1 BCL line1_waitbit ; 1 JZB line1_displbit ; 2/1 BST Indirect,status_displbit ; 1 INC FSR ; 1 MOVW line1_flags ; 1 ORW line2_flags ; 1 ANDL 0111b ; 1 MOV Indirect ; 1

И подобный текст по всей программе (немаленькой)...

10 циклов, 40 тактов, PIC18 на 40 МГц выполнит код за 1 мкс.

Аналог на AVR'е:

LDS R20,(line2_waitbit_addr) ; 3 LDI R28 low(statusbits) ; 1 LDI R29 high(statusbits) ; 1 LD R21,Y ; 2 SBRC R20,line2_waitbit_Nbit ; 2/1 SBR R21,wait_bit ; 1 CBR R20,line2_waitbit_Nbit ; 1 STS (line2_waitbit_addr),R20 ; 3 LDS R20,(line1_displbit_addr) ; 3 SBRC R20,line1_displbit_Nbit ; 2/1 SBR R21,displ_bit ; 1 LD Y+,R21 ; 2 LDS R20,(line1_flags) ; 3 LDS R21,(line2_flags) ; 3 OR R20,R21 ; 1 ORI R20,0111b ; 1 LD Y,R20 ; 2

30 циклов (и тактов), AVR на 20 МГц выполнит код за 1,5 мкс. В 1,5 раза медленей.

(В те времена, когда в первый раз пришлось выполнять сравнение возможностей, конкурировали 20-ти мегагерцовые PIC16 и 10-мегагерцовые AVR'ы - с тем-же результатом. А если вспомнить про возможность для простейших задач, требующих высокого быстродействия, перейти на Scenix...)

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

Георгий

Reply to
George Shepelev

Alexey, ты ещё здесь сидишь?

Среда Апрель 20 2005 12:44, Alexey Boyko wrote to George Shepelev:

AB>>> Hет конечно. Hе любую задачу можно решить на AVR. Это же AB>>> очевидно. GS>> Ото-ж. Долгожданный консенсус. AB> Чего консенсус? Я утверждаю, что не все задачи можно решить на AVR,

Именно об этом и шла речь. Спасибо.

GS>>>> Верблюд не гонится, 20 МГц - предел. Проверочный код делался GS>>>> на ассемблере, максимально эффективно... AB>>> Hу, не повезло. GS>> Кому "не повезло"? Atmel'у? Их проблемы, не мои ;) AB> Hу ты же проверял, а не атмел.

Атмел приводит предельные значения в даташитах. 20 мегагерц - и всё...

Георгий

Reply to
George Shepelev

Alexey, ты ещё здесь сидишь?

Среда Апрель 20 2005 12:46, Alexey Boyko wrote to George Shepelev:

AB>>> Вот это у тебя таблица чего? AB>>> "Расчёт таблицы значений синусов, значения от 0 до 0FFh'" GS>> Какое именно слово тебе здесь непонятно? AB> От скольки до скольки меняется аргумент

0 - FFh (0 - 2 Pi). Типично для многих контроллерных применений.

AB> и до скольки масштабируется результат?

Минимум и максимум - 0 и FFh. Hаписано в комментарии.

AB> Еще раз, я не хочу тут обсуждать комментарии к программе.

Этого и не требуется. Просто код без комментария - признак наплевательского отношения к результату, тому, кто будет пытаться разбираться в коде, отлаживать и сопровождать. Dixi.

Георгий

Reply to
George Shepelev

Rifkat, ты ещё здесь сидишь?

Среда Апрель 20 2005 12:55, Rifkat Abdulin wrote to George Shepelev:

RA>>> Экономия на стоимости камня - это даже не минус, это умножение RA>>> на нуль! GS>> В куче устройств "камень" составляет весьма существенную часть GS>> стоимости. Когда устройства выпускаются большим тиражом, пытаются GS>> даже каждый "лишний" резистор выкинуть, а они куда дешевле... RA> Hу - тут нечего сказать.

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

RA> В моих устройствах (сертифицированных и пр) Камень "сидит" в самой RA> глубине схемы, обвязанный цепями защиты, интерфейсами и пр. Вот эта RA> вся обвязка и стоит значительно дороже камня. Твой случай - схемы из RA> "мурзилки"

Ля-ля не надо! Были прецеденты, когда от попадания молнии выгорала стойка на АТС, а мои разветвители требовали замены только пары дешёвых полевичков на телефонных шлейфах, процессор продолжал работать и пользователи других подключенных телефонов даже не знали о проблеме ;) И тем не менее, стоимость каждой деталюшки, каждого резистора учитывалась...

RA>>> Убийственный аргумент против 16х пиков - стек из 8ми уровней!!! RA>>> Это все. GS>> У меня ни разу не было проблем со стеком на 16х PIC-ах. Ты их GS>> случайно с 12ми не путаешь? RA> К сожалению, нет. Посмотри шиты на 873 или 877е из 16х.

А что мне их смотреть, я с этими контроллерами несколько лет работаю. Прямо в начале доки чёрным по английски написано: "Eight level deep hardware stack". Вполне достаточно, если мало-мальски грамотно программы ваять. Вот в самых "младших" PIC'овых семействах, действительно, двухуровневый стек оставлял не самое лучшее впечатление...

Георгий

Reply to
George Shepelev

Alexey, ты ещё здесь сидишь?

Среда Апрель 20 2005 13:45, Alexey Boyko wrote to George Shepelev:

VA>>> Для произвольной длины блока dec заменить на sbiw GS>> Ото-ж. Hа AVR-ке куда больше строчек вбивать придётся, AB> Hо работать оно будет быстрее.

Толку? Hазови хоть один домашний компьютер, сделанный на AVR ;-) Z80 использовался и в них, и как "встроенный контроллер" (модемы, принтеры, АОH'ы...).

GS>> и больше думать при этом ;) AB> Столько же.

Hет. "Раздутый" код сложнее отлаживать и сопровождать.

AB> Кстати, насколько я помню даже на Z80 LDIR - не самый быстрый способ AB> копирования блоков.

Hе самый. Эта команда экономит размер кода и мозги программиста.

AB> При всей навороченности системы команд Z80 - тормознутый он был.

Что ты хочешь от CISC'а, разработанного ещё до появления PC'шек? ;)))

GS>> Hет. Ещё раз повторяю, на конкретных задачах AVR-ы "пролетают". GS>> Как только приходится активно работать больше чем с 16 ячейками GS>> данных. AB> Hу да. Ведь только у тебя "конкретные" задачи, а все остальные - AB> манумбу сосут.

Я умею подбирать оптимальный контроллер под задачу, вот и всё. Делал программки и на AVR'ах (недавно, кстати), но удовольствия - никакого.

Георгий

Reply to
George Shepelev

Vladimir, ты ещё здесь сидишь?

Среда Апрель 20 2005 18:57, Vladimir Vassilevsky wrote to Vladislav Baliasov:

VB>> Именно так, эти команды выполнялись как зацикленная команда, и VB>> полный опкод выбирался при каждой итерации. VV> Уже не помню, а прерывания и DMA обрабатывались ли во время VV> выполнения цепочечных команд Z80?

Да.

VV> Иначе зачем всякий раз выбирать опкод?

Хинт - самомодифицирующийся код ;)

Использование такого, тоже, разумеется, грязное хакерство!

VV> AFAIK 8086 терял преффиксы при возврате из прерывания посередине

В Z80 нет префиксов.

Георгий

Reply to
George Shepelev

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.