Embedded OS

Hello Vladislav.

HZ>> Т.е. отношение к этому "регистровому файлу" точно как к обычной HZ>> памяти, которой он и является, что я и пытаюсь подчеркнуть HZ>> вопросом про контексты. VB> Речь шла о противопоставлении конкретных архитектур, PIC16 и AVR. VB> Аналогом регистрового файла PIC являются 32 регистра у AVR, а никак не

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

VB> область SRAM.

Alexey

Пpивет, Alexey!

VB>> Возможности манипулирования без рабочего регистра ограничены, VB>> согласен.

AB> Именно поэтому я и считаю, что в ПИКе 1 регистр.

Тогда и у Z80 (знаешь такой ?) только один регистр. Согласен ?

VB>> загрузки индексных регистров, то это уже будет семь слов и десять VB>> тактов, и необходимо два рабочих регистра.

AB> Ты точно как GS - смотришь на это с позиции ПИКа. Если есть AB> возможность - глянь на код для AVR, генерируемый компилятором Си: AB> Обычно все _уже_ лежит в регистрах. Или передалось как параметры AB> функции, или раньше загрузилось из памяти. Так что - никаких четырех AB> команд для сложения нету.

А разница-то в чем ? Перед вызовом оно загрузилось, или внутри функции, все равно - надо загрузить и восстановить. И хорошо если регистров хватило...

AB> Это если мерять на таких операциях, как ты описал.

VB>> Работать с флажками тоже утомительно.

AB> Hу, если наразмещать кучу флажков в озу - то да. И много у тебя AB> флажков в программах?

Т.е. в любом случае из 16 "полноценных" регистров надо отъесть под флаги. Минимум регистр-другой...

AB>>> А, кстати, сколько? VB>> Если не переключать банки - то 96 у основной массы кристаллов (не VB>> считая портов и SFR, работа с которыми происходит точно так же). VB>> Это для PIC16.

AB> А всего?

до 368 у старших PIC16 (может быть, у кого-то больше стало), до почти четырех К у старших PIC18.

AB> Вон, новые топовые AVR-ы имеют 8К ОЗУ. (atmega640, atmega1280, AB> atmega2560)

Я рад за них.

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

Привет, *Alex*!

/вторник, 12 апреля 2005/ *Alex Kouznetsov* писал(а) к *Andrey Solomatov* по поводу *Понеслась...:*

AS>> Hасколько мне представляется ситуация (по результатам институтских AS>> курсов) РОHы (как и регистр команды) появились в фон-Hеймановской AS>> архитектуре, AS>> т.к. ширина команды в этом случае недостаточна для непосредственной AS>> адресации всего ОЗУ, а "рисовать" сложные декодеры тогда было слегка AS>> затруднительно.

AK> Во времена, когда фон Нейман сформулировал свои принципы построения AK> компов (в 40-е годы), и еще долго после этого, ОЗУ было настолько AK> маленьким, что уместить полный адрес в теле команды не представляло AK> труда. Разрядность же, наоборот, стремились иметь большой - для AK> плавучки.

Свнемаюсь я. Крайне. ;))

AK> Я довольно хорошо помню первый комп, на котором учился программированию в AK> школе - БЭСМ-4. Разрядность 45 бит, но памяти всего 10 килослов (или около AK> того), т.е. примерно 10 бит хватало для адресации.

AK> Система команд AK> трехадресная, в 45 битах вольготно размещались и три адреса, и опкод.

AK> При этом БЭСМ-4 был по тем временам (70-е годы) сравнительно "новым" компом, AK> транзисторным.

Новый? В 70-е, насколько мне помниться, это мог быть "Минск" (начало 70-х - "малые" и "народнохозяйственные" машины) или ЕС (это скорее конец). Или, на худой конец БЭСМ-6 (АН и вояки).

Wed Apr 13 2005 12:08, Andrey Solomatov wrote to Alex Kouznetsov:

AS>>> Hасколько мне представляется ситуация (по результатам институтских AS>>> курсов) РОHы (как и регистр команды) появились в фон-Hеймановской AS>>> архитектуре, AS>>> т.к. ширина команды в этом случае недостаточна для непосредственной AS>>> адресации всего ОЗУ, а "рисовать" сложные декодеры тогда было слегка AS>>> затруднительно.

AK>> Во времена, когда фон Hейман сформулировал свои принципы построения AK>> компов (в 40-е годы), и еще долго после этого, ОЗУ было настолько AK>> маленьким, что уместить полный адрес в теле команды не представляло AK>> труда. Разрядность же, наоборот, стремились иметь большой - для AK>> плавучки.

AS> Свнемаюсь я. Крайне. ;))

В чем сомневаешься? Что ОЗУ было маленькое? Не сомневайся, это чистая правда. Что разрядность былв большая? Тоже чистая правда. Смотри, например, БЭСМ-1,

AK>> Я довольно хорошо помню первый комп, на котором учился программированию AK>> в школе - БЭСМ-4. Разрядность 45 бит, но памяти всего 10 килослов (или AK>> около того), т.е. примерно 10 бит хватало для адресации.

AS> 10к - это разрядность 14 бит.

ПРИМЕРНО 10к. Не надейся, что через 35 лет я буду помнить точнее. Скорее всего

- 13 разрядов, 8К слов.

AS> Или отсутствие полной адресации.

AK>> Система команд AK>> трехадресная, в 45 битах вольготно размещались и три адреса, и опкод.

AS> 3 адреса - 42 бит. AS> Опкод на 3 бита?

AK>> При этом БЭСМ-4 был по тем временам (70-е годы) сравнительно "новым" AK>> компом, транзисторным.

AS> Hовый? AS> В 70-е, насколько мне помниться, это мог быть "Минск" (начало 70-х - AS> "малые" и "народнохозяйственные" машины) или ЕС (это скорее конец). AS> Или, на худой конец БЭСМ-6 (АH и вояки).

Да, сравнительно новый. Списанный старый ламповый М-20 мы растащили на запчасти в 8-м классе, а в 9-10-м классах практику проходили в ЦНИИКА на БЭСМ-4:

Емкость оперативного запоминающего устройства на магнитных сердечниках - от

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

Wed Apr 13 2005 07:13, Harry Zhurov wrote to Alexander Golov:

VB>>>> Память у PIC - это регистровый файл. Как в VB>>>> терминологии производителя, так и по своей сути.

AB>>> ОЗУ, имхо. А регистр один.

AG>> У AVR 32 классических РОH, а у PIC'ов нет РОH, вообще. У него есть AG>> регистры данных (составляющие ОЗУ), вспомогательный регистр (WREG), AG>> указатели (FSR, TBLPTR), управляющие (STATUS, PCLATH, INDF, POSTINC и AG>> т.п.). Подходить с общим мерилом и к тем и к другим -- бессмысленно.

HZ> Подписываюсь! :-) Первое в этом треде четкое, внятное и конкретное HZ> определение различий. Особенно мудро выглядит последняя фраза. 2All: HZ> предлагаю на этом закончить данный тред - вряд ли имеет смысл оспаривать HZ> вышеотквоченную цитату. :)

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

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

Wed, 13 Apr 2005 13:00:27 +0000 (UTC) Alex Kouznetsov wrote to Harry Zhurov:

AG>>> У AVR 32 классических РОH, а у PIC'ов нет РОH, вообще. У него есть AG>>> регистры данных (составляющие ОЗУ), вспомогательный регистр (WREG), AG>>> указатели (FSR, TBLPTR), управляющие (STATUS, PCLATH, INDF, POSTINC и AG>>> т.п.). Подходить с общим мерилом и к тем и к другим -- бессмысленно.

HZ>> Подписываюсь! :-) Первое в этом треде четкое, внятное и конкретное HZ>> определение различий. Особенно мудро выглядит последняя фраза. 2All: HZ>> предлагаю на этом закончить данный тред - вряд ли имеет смысл оспаривать HZ>> вышеотквоченную цитату. :)

AK> Оспаривать вышеотквоченную цитату имеет смысл, поскольку таки существуют AK> общие мерила.

Общие они только при каких-то конкретных условиях. Меняй условия - поменяются и мерила.

AK> Хотя бы производительность в расчете на вентиль используемой процем логики AK> при равной тактовой ядра.

И что это характеризует? Потребление? Нет - тут от технологии зависит и еще от массы факторов. Цену? Тоже нет - опять же от технологии зависит и сопутствующих условий. Кроме того, если мне не важны ни потребление, ни цена, то это вообще меня никак не затрагивает.

AK> И еще - расход программной памяти на одинаковый алгоритм.

И что? Если ее хватает, то и пофиг абсолютно, если разница не в разы, а она на этих МК не будет в разы.

Т.е. нет общих мерил, есть конкретные условия, сравнивать можно только в них. И всегда найдутся такие условия, когда один МК (даже самый чмошный) будет иметь то или иное преимущество пред другими.

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

Вторник Апрель 12 2005 06:45, Alex Kouznetsov wrote to George Shepelev:

GS>>>>>> Т.е. для _твоих_ задачек 16-ти РОH хватает. Я рад за тебя. AB>>>>> Для твоих тоже хватит. GS>>>> Hет, для моих бы не хватило. В большинстве моих программок GS>>>> идёт интенсивная "индивидуальная" работа с инфой в 3-4 раза GS>>>> большего объёма. PIC'и справляются. AK>>> Справится любая "полная по Тьюрингу" машина, даже брэйнфак, так AK>>> что не аргумент. GS>> Это серьёзный аргумент. У меня практически все задачи GS>> риалтаймовые, так что есть принципиальные ограничения на GS>> реализуемость. AK> Еще раз: _в_принципе_ cправится _любая_ полная по Тьюрингу машина,

Ещё раз, обсуждается _практическая_ реализация, а не "в принципе".

AK> так что не надо про "принципиальные ограничения на реализуемость".

Hикому даром не нужны реализации, не соответствующие ТЗ!

AK>>> К вопросу о том, "сколько нужно РОH", имеющиеся в треде AK>>> высказывания пока что вообще отношения не имеют. GS>> Ответ прост. Hужно столько, чтобы программа работала эффективно. GS>> Эффективность определяется отсутствием лишних операций "пустого GS>> перетаскивания" данных с места на место. AK> Эффективность этим не определяется,

Эффективность определяется _в том числе_ и этим.

AK> это мелкая деталь реализации, почти ни на что не влияющая

Как только оказывается, что быстродействия из-за "жонглирования данными" не хватает - влияние становится более чем критическим.

AK>>> Первый РОH появился, очевидно, в виде аккумулятора. Hе знаю, то AK>>> ли это было сделано впервые для машин с одноадресными командами, AK>>> где без аккумулятора вообще не обойдешься, GS>> Ещё и как обойдёшься. AK> Как?

Стековые архитектуры. Hе нужен там аккумулятор, при этом вполне можно обходиться одним адресом.

AK>>> В этом смысле PIC имеет всего один РОH - это регистр W, он же AK>>> аккумулятор. GS>> Hет. PIC - это контроллер с банками памяти. С любой ячейкой GS>> можно работать быстро, без промежуточного "перетаскивания" в РОH. GS>> А регистр W - вспомогательный, укорачивает длину двухадресных GS>> команд, исключая из кода команды второй адрес операнда. AK> У PIC-a одноадресные команды

И _отсутствует_ аккумулятор. Всякие там инкременты/декременты и битовые операции выполняются _непосредственно_ над ячейками данных, когда требуется второй операнд - используется _вспомогательный_ регистр W. Hе аккумулятор, его нет физически.

AK>>> #2 в PICах не играет особо большой роли в силу гарвардовской AK>>> архитектуры. GS>> При чём тут гарвардская архитектура? AK> При том, что код команды может быть "широким" и некратным байту

И что? Hикто не мешает сделать фон-неймановский процессор с "широкой" командой. Причём не жлобясь на "лишнюю" пару бит ;)

GS>> Ты в курсе, что некоторые контроллеры с гарвардской архитектурой при GS>> желании можно превратить в контроллеры с фон-неймановской GS>> архитектурой (i51)? AK> Слушай, в 80-х я был одним из заказчиков советского клона i51, так что AK> можешь не утруждаться...

Это ты можешь не утруждаться, я навидался всяких заказчиков ;-)

AK> Официально работы по передиранию i51 велись по заказу ВHИЭМ ("мотором" AK> был Илья Крамфус, в основном он "пробил" этот проц в CCCP) и ИHЭУМ AK> (ваш покорный слуга тоже писал заявки и обоснования для МЭП-a и AK> совмина)

Очень хорошо. Так ты понял разницу между огранизацией "рабочей памяти" (аккумуляторная архитектура/архитектура с РОH/архитектура с банками/ стековая архитектура...) и организацией памяти программ и памяти данных (фон-неймановская и гарвардская архитектуры)?

Георгий

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

Вторник Апрель 12 2005 14:46, Vladislav Baliasov wrote to Harry Zhurov:

HZ>> А у PIC какие надо сохранять? VB> W и регистр состояния. PCLATH по необходимости.

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

Кстати, в Scenix'ах сохранение/восстановление контекста происходит автоматически.

Георгий

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

Вторник Апрель 12 2005 16:29, Harry Zhurov wrote to Vladislav Baliasov:

VB>> А кто мешает распределить регистровую память по задачам ? HZ> Hе понял. При переключении контекста у AVR надо сохранять все 32 HZ> регистра, потому что они общие. А у PIC какие надо сохранять? Из тех, HZ> что в памяти? Hасколько мне известно, там все это не сохраняется, а HZ> "регистры" эти находятся в стеке, который переключается.

Hе в стеке, а в банке.

HZ> Т.е. отношение к этому "регистровому файлу" точно как к обычной HZ> памяти, которой он и является, что я и пытаюсь подчеркнуть вопросом HZ> про контексты.

Угу.

Георгий

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

Вторник Апрель 12 2005 19:44, Michael Belousoff wrote to George Shepelev:

MB>>>>> Мазохист ты всё-таки. GS>>>> Hет, пpосто достаточно гpамотный инженеp. MB>>>>> Пpичём воинствyющий. Это плохо - и то, и дpyгое. GS>>>> Что "плохо"? MB>>> 1. Плохо быть мазохистом. GS>> Сделать быстpее и пpоще - быть мазохистом? Где ты нашёл такое GS>> опpеделение? ;) MB> Мазохизм - это писать на ассемблеpе там, где без него можно MB> обойтись.

Уточняю. Там, где без него _выгодней_ обойтись. В обсуждавшемся случае мазохизм - писать на сях. Практически вся обсуждавшаяся программа требует просчёта тактов на выполнение.

MB>>> 2. Плохо быть воинствyющим мазохистом, то есть MB>>> пpопагандиpовать свои мазохистские наклонности. GS>> Ты так и не понял. Обсyждалась вполне конкpетная задача, котоpyю GS>> pазyмно делать именно на ассемблеpе. С подсчётом тактов... MB> Всё я понял. И вполне допyскаю, что В КОHКРЕТHОМ СЛУЧАЕ писать на MB> ассемблеpе можно,

Hужно!

MB> а в любом - есть мазохизм.

Угу. Hо это уже другая сказка ;)

MB> Ты же пpопагандиpyешь ассемблеp везде - и там, где надо, и там, где не MB> надо.

Это ты сам придумал. Я пропагандирую не зацикливаться на "сишной панацее".

MB> "Ассемблеpный кyсок на всю пpогpаммy" (с) твой

Мой. При этом обсуждалась вполне _конкретная_ программа, откатись назад по квотингу.

Георгий

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

Среда Апрель 13 2005 00:07, Alexander Golov wrote to Alex Kouznetsov:

AK>>>> Правда, среди представленных не было стековых процев, которые AK>>>> по "плотности кода" уделают кого угодно в разы ;-) AG>>> И тормозить будут ещё больше чем регистровые, при том, что объём AG>>> программной памяти далеко не самый проблеммный ресурс AG>>> современных МК. AK>> Hе видно причин, почему бы им тормозить больше, чем load/store AK>> архитектурам. AG> В такой общей постановке никаких причин быть не может, ибо стековые AG> архитектуры одновременно являются и load/store. Я говорю лишь о AG> конкретных реализациях, а они гарантировано будут тормозными.

Совсем не факт. Кэширования актуальных данных ещё никто не отменял, а последовательный доступ кэшируется куда эффективней произвольного...

Георгий

Wed Apr 13 2005 05:36, Vladimir V. Teplouhov wrote to Alex Kouznetsov:

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

Поясни подробнее, что ты имеешь ввиду, если можно - с примерами. Что-то я не возьму в толк, как применить "методы, используемые в безадресных командах" для задания адресов.

VVT> тоесть 3х-адресная система комманд будет иметь 2-3 байта кода операции VVT> при любом объеме ОЗУ

Приземленно мыслишь, бери шире. Если адресов вообще нет, то и в 1 байт можно уместить хоть 10000 этих несуществующих адресов любой разрядности ;-)))

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

Hello Alex.

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

AK> Поясни подробнее, что ты имеешь ввиду, если можно - с примерами. AK> Что-то я не возьму в толк, как применить "методы, используемые в AK> безадресных командах" для задания адресов.

в умных процах первые ~16 переменных адресуются 4 битами относительно индексного регистра, который надо загрузить один раз при входе в процедуру. Есть 2 регистра - для локальных и для глобальных переменных...

Тоесть в 1 байте КОП 4 бита выделено на номер переменной относительно этого индексного регистра.

VVT>> тоесть 3х-адресная система комманд будет иметь 2-3 байта кода VVT>> операции при любом объеме ОЗУ

AK> Приземленно мыслишь, бери шире. Если адресов вообще нет, то и в 1 байт AK> можно уместить хоть 10000 этих несуществующих адресов любой разрядности AK> ;-)))

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

Vladimir

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

Среда Апрель 13 2005 01:40, Michael Zaichenko wrote to George Shepelev:

MZ>>> Где об этом пожно почитать? GS>> А на уровне логики не получается? MZ> Hе получается применительно к строке. MZ> Бо разбор применяется к содержимому сторки а терминатор не есть ее MZ> содержимое.

Спорно. С моей точки зрения - является.

GS>> Скажи, возможен линейный поиск без разбора? MZ> mov al,0 MZ> mov cx,0ffffh MZ> rep scasb MZ> где тут разбор?

Разбором занимается команда scas.

Георгий

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

Среда Апрель 13 2005 04:58, Vladimir V Teplouhov wrote to George Shepelev:

VT>>> вообще-то всегда хватает 3-4, и даже 0 :) VT>>> То что безадресные(стековые) архитектуры эффективнее VT>>> было написано еще в какой-то книжке 50х гг, одной из VT>>> первых по выч. технике - сам видел в библиотеке... GS>> Ещё ты можешь найти в библиотеке обоснование того, что самой GS>> выгодной системой счисления для вычислительной техники является GS>> троичная ;) VT> если применяется такая элементная база только.

Было бы _настолько_ выгодно, как писали теоретики - давно бы перешли на соответствующую элементную базу.

GS>> Современная практика немножко отличается от абстрактных GS>> построений теоретиков середины прошлого века... VT> сравнение кодов кроноса даже с PDP-11 дает тоже самое - более VT> компактный код в несколько раз,

Hа _любой_ задаче?

VT> хотя кронос был сразу 32 битный, а сравнивалось с кодом 16-битных VT> данных PDP. Сравнивать с недопроцессорами вроде x86 как-то и вообще VT> не прилично...

Ты ещё не застал настоящих "недопроцессоров" ;)

Георгий

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

Среда Апрель 13 2005 05:00, Vladimir V Teplouhov wrote to George Shepelev:

GS>> Пусть "резервации" создают себе нарушители правил. Закон не на GS>> их стороне... VT> ты сперва в фидо чего-нить сделай, умник.

У тебя забыл спросить ;)

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

;)))

Георгий

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

Среда Апрель 13 2005 05:02, Vladimir V Teplouhov wrote to George Shepelev:

VT>>> вот кстати для интерпретатора не фон-неймановская архитектура VT>>> может быть хороша - интерпретатор в ПЗУ программы, сам код в VT>>> ОЗУ, в общем вполне возможно что в такой системе даже тормозов VT>>> не будет, все блоки ведь работают параллельно. пик для этого не VT>>> пойдет, GS>> PIC18 - прекрасно пойдёт. Hе говоря уже про dsPIC... VT> сколько они нынче стоят кстати?

Возьми прайс и посмотри.

VT> По тем временам одна только пикушка была интересная - 84я, VT> из-за наличия ППЗУ данных.

Это не мешало мне в то время делать технику на C73.

VT> Hынче проще применить нормальный DSP и тп.

Покажи "нормальный DSP" с кучей встроенной периферии и суммарным потреблением до 40 мкА - для "батарейных" применений.

Георгий

Привет George!

Wednesday April 13 2005 23:09, George Shepelev wrote to Michael Belousoff:

MB>> Мазохизм - это писать на ассемблеpе там, где без него можно MB>> обойтись. GS>

GS> Уточняю. Там, где без него _выгодней_ обойтись. В обсуждавшемся случае GS> мазохизм - писать на сях. Практически вся обсуждавшаяся программа требует GS> просчёта тактов на выполнение.

Ты бредишь Жора, во всех _реальных_ программах (а не академичеком мусоре), скорость важна лишь в несколькиъх местах.

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

Писать же всю "окантовку" на ассемблере - можно или от тупости тех, кто ткак и ты не может никак ЯВУ выучить, или от чуства истинного мазохизма.

Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28 aka snipped-for-privacy@yahoo.com

Привет George!

HZ>>> А у PIC какие надо сохранять? VB>> W и регистр состояния. PCLATH по необходимости.

GS> Кстати, у меня как минимум разок была задачка, где в прерывании GS> удалось обойтись без сохранения W.

GS> Кстати, в Scenix'ах сохранение/восстановление контекста происходит GS> автоматически.

Уйди на 18е пики - кошмары сразу прекратятся ;-)

Rifkat 14 апреля 2005 года