Embedded OS

Hello, Vladimir! You wrote to Aleхander Torres on Sat, 09 Apr 2005 01:18:17 +0400:

VV> Речь не об них. Был "Tobos" весом в ~6 килобайт с поддержкой всех Tobos всё же потяжелее был. Не знаю, может разные версии были, мой весил под

VV> свойств родного бейсика и еще какой-то компилер в ~4 килобайта VV> без поддержки float. Вот этот второй - да, рулез. Когда-то, ради развлекухи склепал на нём "тетрис" за три часа :)

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

With best regards, Serg.

Hello Nickita.

VV>> Hет. Речь о том, что нельзя вызывать С функции в C++ программе, VV>> если они не обьявлены как C_decl. NS> Это следствие отсутствия стандартного вменяемого совместимого NS> манглинга вc++,

Hет, не поэтому. А потому, что в С++ - манглинг есть, а в Си - нету.

Alexey

Hello George.

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

Вот моя на питоне, пол года назад (функция другая, но принцип тот же):

#!/usr/bin/python print "prog_int16_t transfer_table[4096] = {"

for i in range(4096): print "%d," % ((float(x)-1200)*1.7 + 750)

print "};"

Alexey

Hello George.

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

AVR - 32 регистра. PIC - 1 регистр.

Всё?

Alexey

Здравствуйте, Уважаемый George!

Sun Apr 10 2005 16:44, George Shepelev wrote to Olga Nonova:

ON>> Хотелось бы все-таки интерпретатор байт-кода.

GS> Чем Forth не устраивает? Тем, что "не модный"?

Хотелось бы более распространненую вещь, чтоб наработок и инфраструктуры для разработки и отладки было бы предостаточно. Кроме того, как там у Forth с многозадачностью или multythreads? И наконец, стековый образ мышления...

ON>> Основные возражения, что я слышала,- низкое быстродействие ON>> интерпретатора.

GS> Быстродействие не столь критично, как требования к памяти...

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

Всего Вам Хорошего Ольга

Hello, Harry Zhurov !

enum в Си удобно использовать как средство для задания автонумеруемых констант, #define для этого менее удобен, так как нет автонумерации.

С уважением, Дима Орлов.

Пpивет, Alexey!

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

AB> AVR - 32 регистра. PIC - 1 регистр.

AB> Всё?

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

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

Пpивет, Harry!

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

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

Hо - в 32 регистрах, и с ограничениями. В PIC можно обнулить, сдвинуть, проверить, установить или сбросить бит, инкрементировать, декрементировать, плюс пропуски по состоянию и перестановка нибблов. Сложить, сравнить и переслать - нельзя. Hо в AVR с памятью вообще только пересылки, и только с регистрами.

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

Mon Apr 11 2005 09:44, Harry Zhurov wrote to Yuriy K:

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

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

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

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

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

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

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

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

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

VLV

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

Hello Vladislav.

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

2. Alexey

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

Суббота Апрель 09 2005 07:20, Vladimir V Teplouhov wrote to George Shepelev:

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

Ещё ты можешь найти в библиотеке обоснование того, что самой выгодной системой счисления для вычислительной техники является троичная ;)

Современная практика немножко отличается от абстрактных построений теоретиков середины прошлого века...

Георгий

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

Суббота Апрель 09 2005 22:38, Vladimir V Teplouhov wrote to George Shepelev:

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

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

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

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

Георгий

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

Суббота Апрель 09 2005 22:46, Vladimir V Teplouhov wrote to Olga Nonova:

ON>> В самом деле, выходной из-под JAVA-компилятора байт-код содержит ON>> ссылки на ячейки памяти безотносительно к ее типу. По-умолчанию- ON>> это ОЗУ, как в неймановской архитектуре. Таким образом, системы с VT> вот кстати для интерпретатора не фон-неймановская архитектура VT> может быть хороша - интерпретатор в ПЗУ программы, сам код в ОЗУ, VT> в общем вполне возможно что в такой системе даже тормозов не будет, VT> все блоки ведь работают параллельно. VT> пик для этого не пойдет,

PIC18 - прекрасно пойдёт. Hе говоря уже про dsPIC...

Георгий

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

Воскресенье Апрель 10 2005 06:52, Alex Kouznetsov wrote to George Shepelev:

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

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

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

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

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

Ещё и как обойдёшься. Hикто не мешает выполнять одноадресные команды над ячейками "медленной" памяти. Это определяется исключительно системой команд конкретного процессора.

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

Использование аккумулятора позволяет уменьшить длину команды, поскольку адрес для аккумулятора задавать не требуется.

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

Использование ограниченного набора РОH также позволяет уменьшить длину команды, указывая номера РОH вместо полных адресов ячеек памяти данных. При этом никто не запрещает отобразить аккумулятор и РОH на общее адресное пространсто данных, так чтобы с ними можно было работать и "традиционным" образом.

Итак, основной выигрыш от введения РОH - уменьшенная длина команды, что косвенно влияет на скорость её выполнения. Другой способ, которым можно получить тот-же результат - работа с памятью, разбитой на "банки". При этом адрес ячейки в выбранном банке короткий, что также позволяет уменьшить длину команды.

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

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

AK> С моей точки зрения, РОHы нужны для двух вещей: AK> 1. Для ускорения вычислений, если обращение к основной памяти AK> относительно медленное

Да. Также возможен вариант, когда основная память быстрая, но система команд процессора не позволяет работать с ней быстро, поскольку вычисления производятся только над РОH (тот самый AVR).

AK> 2. Для упрощения системы команд и уменьшения длины команд, т.к. AK> адресацию небольшого кол-ва РОHов легко втиснуть в относительно AK> короткое поле команды.

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

AK> Для PIC-ов обращение к его регистровым файлам занимает столько же AK> времени, сколько обращение к любому регистру, так что #1 роли не AK> играет.

Ото-ж. Хотя при желании выбранный банк можно считать текущим набором РОH ;)

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

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

AK> Тем не менее, комады в PIC-ах длинные, так что память программ AK> используется неэффективно.

По факту, "длинные" 14-ти битные команды PIC'ов работают при произвольном доступе заметно эффективнее, чем "короткие" (хи-хи) команды AVR. Потому что архитектура контроллера более грамотная...

AK> В конце концов, мы платим деньги за килобиты флэша, и такая AK> неэффективность PIC-ов напрямую бьет по карману ;-)

Тебе мерещится "неэффективность" PIC'ов. Есть задачи, в которых их принципиально невозможно заменить другими контроллерами равной ценовой категории, так что "бить по карману" будет тех, кто из "идеологических" соображений воротит нос от PIC'ов...

AK> Частично эта неэффективность компенсируется простотой AK> вычислителя, на него расходуется меньше кремня. Однако эта компесация AK> эффективна только пока памяти программ мало. Что мы, собственно, и AK> наблюдаем: маленькие PIC-и весьма и весьма конкурентноспособны, но с AK> "большими ребятами" им тягаться трудно.

Ерунда.

AK> Hа презентации Renesas пару лет назад была представлена относительная AK> "плотность кода" для разных процев. В смысле расходования программной AK> памяти, помнится, AVR был существенно эффективнее PIC-ов, MSP430 AK> эффективнее AVR-ов, а М16, как и можно было ожидать на такой AK> презентации, "неожиданно" оказался процентов на 20 эффективнее AK> лучших из представленных конкурентов ;-)

Какой код сравнивали? Hаверняка сгенерированный особо кривым компилятором, специально оптимизированным для M16. При сравнении кода, сделанного на ассемблере хорошими программистами, результаты сравнения были бы совершенно другими...

AK> Правда, среди представленных не было стековых процев, которые по AK> "плотности кода" уделают кого угодно в разы ;-)

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

Георгий

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

Воскресенье Апрель 10 2005 20:06, Michael Belousoff wrote to George Shepelev:

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

Сделать быстрее и проще - быть мазохистом? Где ты нашёл такое определение? ;)

MB> 2. Плохо быть воинствyющим мазохистом, то есть пpопагандиpовать MB> свои мазохистские наклонности.

Ты так и не понял. Обсуждалась вполне конкретная задача, которую разумно делать именно на ассемблере. С подсчётом тактов...

GS>> Ты конкpетнyю задачy анализиpовал? Там везде такты GS>> считать нyжно. Си pазве что инициализацию pегистpов может GS>> выполнить, но мне пpоще эти несколько стpок на ассемблеpе GS>> написать, чем pазбиpаться в нюансах сишного компилятоpа пpи GS>> pаботе с новым чипом... MB> Да делай ты что yгодно, я же не возpажаю. Только не говоpи, что MB> этот подход - пpавильный.

Для _конкретной_ задачи, которая обсуждалась - правильный. С другими задачами нужно разбираться отдельно. Андэстэнд?

Георгий

Mon, 11 Apr 2005 13:15:40 +0400 Vladislav Baliasov wrote to Alexey Boyko:

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

AB>> AVR - 32 регистра. PIC - 1 регистр.

AB>> Всё?

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

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

Привет, Nickita! Вы писали to Leha Bishletov on Fri, 08 Apr 2005 23:26:38 +0400:

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

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

With best regards, Leha Bishletov. E-mail: snipped-for-privacy@rol.ru

Привет, Harry! Вы писали to Leha Bishletov on Mon, 11 Apr 2005 04:44:36 +0000 (UTC):

LB>> А можно заставить перечислимый тип быть какой-то конкретной LB>> размерности, т.е. соответствовать char или int, причем для разных LB>> наборов разная размерность? HZ> Это, afair, определяется реализацией. В частности, помнится, в HZ> доке на какой-то IAR'овский компилятор было сказано, что размер HZ> enum'а зависит от количества значений - если они влазят в char, то HZ> выделяется 1 байт, если не влазят, то тогда инт.

Да, действительно, IAR выделяет минимально возможный размер char-short-int- ... :) Даже арифметику ограничивает, т.е. ++ можно, а +1 нельзя. Спасибо за наводку :)

With best regards, Leha Bishletov. E-mail: snipped-for-privacy@rol.ru

Пpивет, Alexey!

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

AB> 1.

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

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