Embedded OS

Привет Vladimir!

HZ>>>> Hу хорошо, ответь тогда, зачем в С такой перечислимый тип, при HZ>>>> использовании которого все работает ровно так, как будто это HZ>>>> просто целое?

VV> Затем что enum это самостоятельный тип, применительно к которому VV> работает проверка типов.

VV> typedef enum { VV> SUNDAY, VV> MONDAY, VV> ...... VV> } DAY_OF_WEEK;

void Foo(DAY_OF_WEEK); void Bar(int);

VV> Тебе не дадут вызвать Foo(int)

void test(void) { Foo(75); Bar(MONDAY); }

Оба вызова спокойно отработают.

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Я удалю твою жажду. Без возможности восстановления.

Mon Apr 11 2005 21:33, Anatoly Mashanov wrote to Alex Kouznetsov:

AK>> архитектурам. У стековых несколько преимуществ: -- очень простое и AK>> компактное ядро -- можно получить в 2-3 раза более плотный код чем у AK>> рисков -- прекрасная совмеcтимость с ЯВУ В сумме это даст много. В AK>> качестве примерa можно сослаться на стековый проц ST5: по цене он AK>> такой же, как отстойная дешевка ST6, а по производительности - как AK>> моторолоподобный ST7.

AM> По моим прикидкам, при изготовлении стекового форт-проца на 1804 серии AM> получается существенно большее у[beep]ище, чем при использовании AM> традиционной архитектуры на том же железе. Проблема в том, что каждая AM> двухместная стековая операция сопровождается двумя чтениями из памяти и AM> одной записью в память. Операция с памятью реализуется весьма ненулевым AM> количеством элементарных операций.

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

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

Перенумеровывать не надо. Можно использовать аппаратное FIFO, или, что еше проще, автоинкремент/автодeнкремент укзателя стека, как это обычно и делается для классичeского стека в любом проце

AM> Кроме того, ФОРТ предполагает (IMHO), что AM> верхушка стека - в ОЗУ, что еще усложняет логику.

Ничего такого фоpт не прeдполагает

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

Hello Harry!

VB>> У PIC _вся_ память - регистры. И это принципиальное отличие.

HZ> И можно сложить два регистра одной командой? Или сравнить два HZ> регистра одной командой? Или можно переслать содержимое одного HZ> регистра в другой одной командой? В AVR можно.

Чем тебе не нравится movff postincf0,postincf1; ?

Anatoly

Привет George!

Monday April 11 2005 16:52, George Shepelev wrote to Vladimir V Teplouhov:

VT>> брось фигней страдать - 99% людей уже не переделаешь, VT>> и никакое полиси тут тоже не поможет. GS>

GS> Policy придумали для того, чтобы в fido вредители не мешали общаться GS> нормальным людям.

Да Жора, и по этому полиси - ты не просто "сильно всех раздражаешь", но еще и "чрезмерно" - поскольку тебе на это было указано, неоднократно.

VT>> Единственный вариант сделать несколько разных резервац.. ну тоесть VT>> эх, чтобы не тесно было. GS>

GS> Пусть "резервации" создают себе нарушители правил. Закон не на их GS> стороне...

Hу почему же, для Теплоухова сделали - репеир.трикс :)

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

Hello Vladislav.

AB>>>> AVR - 32 регистра. PIC - 1 регистр. VB>>> У PIC _вся_ память - регистры. И это принципиальное отличие. AB>> 1. VB> От того, что ты это повторишь еще хоть сто раз, к реальности твое VB> утверждение не приблизится.

Просто не хочу обсасывать это по энному кругу.

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

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

Alexey

Mon Apr 11 2005 17:54, George Shepelev wrote to Alex Kouznetsov:

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

GS> Это серьёзный аргумент. У меня практически все задачи риалтаймовые, так GS> что есть принципиальные ограничения на реализуемость.

Еще раз: _в_принципе_ cправится _любая_ полная по Тьюрингу машина, так что не надо про "принципиальные ограничения на реализуемость".

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

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

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

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

GS> Ещё и как обойдёшься.

Как?

GS> Hикто не мешает выполнять одноадресные команды над GS> ячейками "медленной" памяти. Это определяется исключительно системой ^^^^^ GS> команд конкретного процессора.

В одноадресной команде возможен доступ только к одной ячейке памяти.

AK>> В этом смысле PIC имеет всего один РОH - это регистр W, он же AK>> аккумулятор.

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

У PIC-a одноадресные команды

AK>> #2 в PICах не играет особо большой роли в силу гарвардовской AK>> архитектуры.

GS> При чём тут гарвардская архитектура?

При том, что код команды может быть "широким" и некратным байту

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

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

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

Mon, 11 Apr 2005 16:36:34 +0400 Vladimir Vassilevsky wrote to Harry Zhurov:

HZ>>>> Hу хорошо, ответь тогда, зачем в С такой перечислимый тип, при HZ>>>> использовании которого все работает ровно так, как будто это просто HZ>>>> целое?

VV> Затем что enum это самостоятельный тип, применительно к которому работает VV> проверка типов.

VV> typedef enum { VV> SUNDAY, VV> MONDAY, VV> ...... VV> } DAY_OF_WEEK;

VV> void Foo(DAY_OF_WEEK day_of_week) VV> { VV> switch(day_of_week) VV> { VV> case SUNDAY: .... VV> } VV> }

VV> Тебе не дадут вызвать Foo(int)

Да куда они денутся?!

// ------------------------------------------------------------------ typedef enum { SUNDAY, MONDAY } DAY_OF_WEEK;

extern int a;

void Foo(DAY_OF_WEEK day_of_week) { switch(day_of_week) { case SUNDAY: a = 1; case MONDAY: a = 2; } }

int main() { Foo(1); } // ------------------------------------------------------------------

Выдача С:

Выдача С++:

Почувствуйте, как грицца, разницу.

При этом хороший компилятор С выдает хотя бы предупреждение. А имеет полное право промолчать. В то время как в С++ поведение однозначно и определенно: ошибка!

YK>>> Hесколько ограничена область видимости.

VV> Совершенно верно.

#define a 1 #define b 2

enum { a = 1, b = 2 };

Приведи ситуацию, где видно первое и не видно второе?

HZ>> Вот я и говорю - совершенно бесполезный!

VV> А не используй арифметические действия с enum.

Я поступаю проще: не использую enum'ы в С. И стараюсь не использовать С, где есть С++. Благо, сегодня среди интересующих меня платформ С++ есть подо все. :-)

Привет, Leha !

LB>>> А можно заставить перечислимый тип быть какой-то конкретной LB>>> размерности, т.е. соответствовать char или int, причем для LB>>> разных наборов разная размерность? NA>> Можно описать "operator + &int"

LB> Честно говоря, не понял чем это может помочь. Поясни, если не сложно.

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

. С уважением, Hикита. ... Плохое настроение - это неприлично?

Пpивет, Alexey!

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

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

Производитель считает иначе. У многих процессоров регистры неравноправны, но _регистрами_ они от этого быть не перестают. Hо, в конце концов, дело не в терминологии, а принципе работы. В AVR как ни крути, но для работы с RAM ее содержимое надо перекладывать в регистры, и только тогда с ним можно манипулировать, в PIC - это не требуется. И регистровый файл PIC соответствует регистровому набору AVR, но размером больше.

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

Hello Vladislav.

AB>> ОЗУ, имхо. А регистр один. VB> конце концов, дело не в терминологии, а принципе работы. В AVR как ни VB> крути, но для работы с RAM ее содержимое надо перекладывать в VB> регистры, и только тогда с ним можно манипулировать, в PIC - это не VB> требуется. И регистровый файл PIC соответствует VB> регистровому набору AVR,

Ты так и не привел команду сложения двух любых регистров в ПИКе.

VB> но размером больше.

А, кстати, сколько?

Alexey

Привет, *Alex*!

/воскресенье, 10 апреля 2005/ *Alex Kouznetsov* писал(а) к *George Shepelev* по поводу *Понеслась...:*

AK> Для затравки, как мне это представляется в историческом плане. Первые AK> компунтели не имели РОН, а работали только с памятью. При этом они как AK> правило имели трехадресные команды вида "c:=a+b". Потом догадались, что AK> результат выполнения одной отдельно взятой комады чаще всего является AK> не окончательным, а промежуточным результатом, используемым в AK> дальнейших вычислениях. Появились машины с двухадресными командами вида AK> "b:=a+b", однако промежуточный результат, скорее всего, продолжали AK> кидать в (медленную) память, тратя на это время понапрасну. AK> Первый РОН появился, очевидно, в виде аккумулятора. Не знаю, то ли это

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

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

Понедельник Апрель 11 2005 09:25, Alexey Boyko wrote to George Shepelev:

GS>>>> Т.е. для _твоих_ задачек 16-ти РОH хватает. Я рад за тебя. AB>>> Для твоих тоже хватит. GS>> Hет, для моих бы не хватило. В большинстве моих программок идёт GS>> интенсивная "индивидуальная" работа с инфой в 3-4 раза большего GS>> объёма. AB> Сколько надо килобайт?

Килобайт _чего_? "Быстрых" регистров нужно полсотни, да массивы данных бывают от полсотни байт и выше...

GS>> PIC'и справляются. AB> Тогда и AVR-ы справятся.

Hе справляются, делались прикидки. AVR'ы удобны, когда важней всего дешевизна или в довольно экзотических задачках...

Георгий

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

Понедельник Апрель 11 2005 09:27, Alexey Boyko wrote to George Shepelev:

AB>>> Хорошо: Были бы в ПИКе записи мнемоник нормальные, её бы AB>>> каждый производитель не перехачивал. Так лучше? GS>> Лучше. Теперь уточни, о каких "производителях" ты говоришь. AB> Я назову одного, и ты принцип поймёшь: Георгий Шепелев.

Я в этом смысле пользователь, а не производитель. Компилятор поддерживает макросы, так что _любой_ пользователь имеет _полное право_ ими пользоваться. Попробуй возразить 8-P

Георгий

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

Понедельник Апрель 11 2005 10:34, Alexey Boyko wrote to George Shepelev:

GS>> Вот типичный примерчик программки на TP, сварганенный за 10 GS>> минут лет пять назад. Генерит готовый модуль для подключения к GS>> ассемблерной программке для однокристаллок. AB> Вот моя на питоне, пол года назад (функция другая, но принцип тот же):

Hу хоть какой-то комментарий должен быть, а? Откуда эта неисправимая привычка к "слепым" программам? :-/

Георгий

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

Понедельник Апрель 11 2005 11:12, Alexey Boyko wrote to George Shepelev:

GS>> -------- Арифметические 16 (32) РОH с остальной GS>> 256-регистровый банк из BSR команды памятью жонглировать GS>> или 128 "младших" регистров GPR AB> AVR - 32 регистра. PIC - 1 регистр.

Чушь! В PIC'ах доступны для арифметико/логических операций до 256 регистров текущего банка данных.

Георгий

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

Понедельник Апрель 11 2005 11:32, Olga Nonova wrote to George Shepelev:

ON>>> Хотелось бы все-таки интерпретатор байт-кода. GS>> Чем Forth не устраивает? Тем, что "не модный"? ON> Хотелось бы более распространненую вещь,

Куда уж распространённее! Язык используется и продолжает развиваться с начала

ON> чтоб наработок и инфраструктуры для разработки и отладки было бы ON> предостаточно.

Предостаточно.

ON> Кроме того, как там у Forth с многозадачностью или multythreads?

Hикаких проблем. Если готовые реализации не устраивают, за неделю пишется своя Forth-система (проверено).

ON> И наконец, стековый образ мышления...

Главное, чтобы голова была на плечах, а не капуста. Остальное приложится ;)

ON>>> Основные возражения, что я слышала,- низкое быстродействие ON>>> интерпретатора. GS>> Быстродействие не столь критично, как требования к памяти... ON> С памятью становится все проще и проще.

Угу.

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

Стеки тоже собираешься в последовательной памяти размещать? ;)

Георгий

Пpивет, Alexey!

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

AB> Ты так и не привел команду сложения двух любых регистров в ПИКе.

Возможности манипулирования без рабочего регистра ограничены, согласен. Однако же и у AVR, к примеру, нельзя сделать EOR с непосредственным операндом без загрузки вспомогательного регистра (и не всякого, отметим). А у Z80 логические операции без A не работают... Тем не менее, сложение двух регистров с использованием W - это две команды (два слова), а для AVR - четыре, причем если без загрузки индексных регистров, то это уже будет семь слов и десять тактов, и необходимо два рабочих регистра. Так что при равной тактовой AVR окажется в проигрыше... Работать с флажками тоже утомительно. Т.е. все хорошо и прекрасно, когда хватает 16 регистров для всех нужд (счетчики, флаги, индексы), а дальше - тяжело и пухло. Впрочем, это все с позиции апологета ассемблера. "Сионисты" меня не поймут...

VB>> но размером больше.

AB> А, кстати, сколько?

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

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

Пpивет, Harry!

VB>> не требуется. И регистровый файл PIC соответствует регистровому VB>> набору AVR, но размером больше.

HZ> У AVR регистровый файл, в частности, входит в контекст задачи. А у HZ> PIC? Чтобы не возникало возражения, что, дескать на PIC16 вытесняющая HZ> ОС не получится, пусть вопрос касается PIC18 - идеология HZ> "память/регистры" там ровно такая же.

А кто мешает распределить регистровую память по задачам ?

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

Tue Apr 12 2005 12:03, Andrey Solomatov wrote to Alex Kouznetsov:

AK>> Для затравки, как мне это представляется в историческом плане. Первые AK>> компунтели не имели РОH, а работали только с памятью. При этом они как AK>> правило имели трехадресные команды вида "c:=a+b". Потом догадались, что AK>> результат выполнения одной отдельно взятой комады чаще всего является AK>> не окончательным, а промежуточным результатом, используемым в AK>> дальнейших вычислениях. Появились машины с двухадресными командами вида AK>> "b:=a+b", однако промежуточный результат, скорее всего, продолжали AK>> кидать в (медленную) память, тратя на это время понапрасну. AK>> Первый РОH появился, очевидно, в виде аккумулятора. Hе знаю, то ли это

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

Во времена, когда фон Нейман сформулировал свои принципы построения компов (в

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