Embedded OS

Tue, 12 Apr 2005 10:28:28 +0400 Vladislav Baliasov wrote to Alexey Boyko:

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

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

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

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

Reply to
Harry Zhurov
Loading thread data ...

Пpивет, Harry!

*** 12 Apr 05 16:29, Harry Zhurov wrote to Vladislav Baliasov:

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

HZ> Hе понял. При переключении контекста у AVR надо сохранять все 32 HZ> регистра, потому что они общие.

Если предполагается использовать все - то все и сохранять.

HZ> А у PIC какие надо сохранять?

W и регистр состояния. PCLATH по необходимости.

HZ> Из тех, что в памяти? Hасколько мне известно, там все это не HZ> сохраняется, а "регистры" эти находятся в стеке, который HZ> переключается.

Hет. Если речь идет о PIC16 (в архитектуру PIC18 я не вникал).

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

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

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

Reply to
Vladislav Baliasov

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

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

Вернее, не 10 бит (это ашыпка), а 12 или 13, это сути дела не меняет.

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

Reply to
Alex Kouznetsov

Tue Apr 12 2005 07:47, Harry Zhurov wrote to Vladimir Vassilevsky:

HZ>>>>> Hу хорошо, ответь тогда, зачем в С такой перечислимый тип, 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>> Тебе не дадут вызвать Foo(int)

HZ> Да куда они денутся?! HZ> "D:\slon\IAR\MSP430\V3\1\slon.c",22 Warning[Pe188]: enumerated type HZ> mixed with another type

Очень плохой компиллятор. Потому что даже Cosmic C, известный тем, что пропускает очевидные ошибки, не позволяет смешивать перечислимые и числовые типы.

HZ> Я поступаю проще: не использую enum'ы в С.

Я требую, чтобы в случаях, когда есть набор состояний, этот набор был выделен в отдельный тип и описан как enum. Потому что это упрощает правки и предотвращает некоторые ошибки.

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

C++ есть, увы, не везде и не всегда.

VLV

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

Reply to
Vladimir Vassilevsky

Tue, 12 Apr 2005 13:35:42 +0400 Vladislav Baliasov wrote to Harry Zhurov:

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

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

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

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

Reply to
Harry Zhurov

Пpивет, George.

Вот что George Shepelev wrote to Michael Belousoff:

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

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

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

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

GS> Ты так и не понял. Обсyждалась вполне конкpетная задача, котоpyю GS> pазyмно делать именно на ассемблеpе. С подсчётом тактов...

Всё я понял. И вполне допyскаю, что В КОHКРЕТHОМ СЛУЧАЕ писать на ассемблеpе можно, а в любом - есть мазохизм. Ты же пpопагандиpyешь ассемблеp везде - и там, где надо, и там, где не надо. "Ассемблеpный кyсок на всю пpогpаммy" (с) твой - это yже не "конкpетный слyчай".

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авильный.

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

Have _yourself_ understood this?

Michael G. Belousoff

formatting link
mailto: mickbell(dog)r66(dot)ru

... ==== Пpоблемy надо pешать до того, как она появится. ====

Reply to
Michael Belousoff

Привет!

Mon Apr 11 2005 07:09, Alex Kouznetsov wrote to Alexander Golov:

...

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

AG>> И тормозить будут ещё больше чем регистровые, при том, что объём AG>> программной памяти далеко не самый проблеммный ресурс современных МК.

AK> Hе видно причин, почему бы им тормозить больше, чем load/store AK> архитектурам.

В такой общей постановке никаких причин быть не может, ибо стековые архитектуры одновременно являются и load/store. Я говорю лишь о конкретных реализациях, а они гарантировано будут тормозными.

AK> У стековых несколько преимуществ: AK> -- очень простое и компактное ядро

Не самое примитивное (как минимум, при сравнении с PIC16C54) ядро процессора R65C02 содержало порядка 10 тыс. элементов, а 1 кБ SRAM требует минимум 33 тыс. элементов, 16 кБ Flash -- 130 тыс. элементов. Даже опуская затраты на периферию, можешь оценить сколь актульна ныне экономия на сложности ядра.

AK> -- можно получить в 2-3 раза более плотный код чем у рисков

Или не получить. Очень сильно зависит от состава превалирующих операций.

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

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

Александр Голов, Москва, snipped-for-privacy@mail.ru

Reply to
Alexander Golov

Привет!

Tue Apr 12 2005 08:34, Alexey Boyko wrote to Vladislav Baliasov:

...

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

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

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

Александр Голов, Москва, snipped-for-privacy@mail.ru

Reply to
Alexander Golov

Привет!

Tue Apr 12 2005 14:35, Harry Zhurov wrote to Vladislav Baliasov:

...

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

HZ> У AVR регистровый файл, в частности, входит в контекст задачи. А у HZ> PIC?

А у ATtiny15?

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

В чём суть вопроса не понятно, те регистры что входят в контекст задачи те и входят, которые -- нет, так и нет.

Александр Голов, Москва, snipped-for-privacy@mail.ru

Reply to
Alexander Golov

Hi George,

Wed Apr 06 2005 10:54, George Shepelev wrote to Michael Zaichenko:

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

GS> Среда Апрель 06 2005 03:03, Michael Zaichenko wrote to George Shepelev:

MZ>>>> Так, тады в чем разница между разбором (парсингом) и линейным MZ>>>> поиском? GS>>> Второе есть частный случай первого. MZ>> Где об этом пожно почитать?

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

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

где тут разбор?

GS> Георгий

WBR, Michael

Reply to
Michael Zaichenko

Wed Apr 13 2005 01:07, Alexander Golov wrote to Alex Kouznetsov:

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

AG>>> И тормозить будут ещё больше чем регистровые, при том, что объём AG>>> программной памяти далеко не самый проблеммный ресурс современных МК.

AK>> Hе видно причин, почему бы им тормозить больше, чем load/store AK>> архитектурам.

AG> В такой общей постановке никаких причин быть не может, ибо стековые AG> архитектуры одновременно являются и load/store. Я говорю лишь о AG> конкретных реализациях, а они гарантировано будут тормозными.

В честь чего, собственно? Известные реализации стековых процев нельзя назвать тормозными. Самый быстрый микропроцессор, сделанный в СССР, был стековым процессором.

AK>> У стековых несколько преимуществ: AK>> -- очень простое и компактное ядро

AG> Hе самое примитивное (как минимум, при сравнении с PIC16C54) ядро AG> процессора R65C02 содержало порядка 10 тыс. элементов, а 1 кБ SRAM AG> требует минимум 33 тыс. элементов, 16 кБ Flash -- 130 тыс. элементов. AG> Даже опуская затраты на периферию, можешь оценить сколь актульна ныне AG> экономия на сложности ядра.

Кажется, ты себе противоречишь. Объем программной памяти для тебя не самый проблемный ресурс, экономия на сложности ядра тоже не актуальна. Что же осталось? Объем ОЗУ и периферия? Поскольку и то и другое от процессорного ядра почти не зависят, значит, тебе должно быть по фигу какой проц.

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

AK>> -- можно получить в 2-3 раза более плотный код чем у рисков

AG> Или не получить. Очень сильно зависит от состава превалирующих операций.

Ну конечно, без царя в голове можно расфукать любые преимущества

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

AG> Hу это разве что соответствующим образом характеризует ST7, а сам ST5 -- AG> жутко тормозная штука, да и особой компактности кода, что-то не AG> наблюдается; очень кстати, как иллюстрация к упоминаемым выше конкретным AG> реализациям.

А его, похоже, "пионэры" изобретали, не знакомые с Фортом, с работами Чака Мура, Купмана, и пр. "Смекалка темной головы", а не проц. Не удивительно ли, что при этом они все-таки сделали шаг вперед по сравнению с ST6 и ST7, это ли не показатель преимуществ стековой архитектуры, которые не способны до конца убить даже кривые ручки.

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

Reply to
Alex Kouznetsov

Hello Alex.

12 Apr 05 13:52, you wrote to Andrey Solomatov: AK> Tue Apr 12 2005 12:03, Andrey Solomatov wrote to Alex Kouznetsov: ... AK>>> тратя на это время понапрасну. Первый РОH появился, очевидно, в виде AK>>> аккумулятора. Hе знаю, то ли это

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

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

впринципе если применить те-же методы, что и применяются в безадресных системах комманд, то в 2 байта кода операции легко умещаются 3 адреса, тоесть 3х-адресная система комманд будет иметь 2-3 байта кода операции при любом объеме ОЗУ (4Г слов адресовалось еще в конце 80х, при переходе на 64 битный адрес длина кода тоже не изменится).

Просто это нафиг не нужно - реально все выражения очень хорошо ложаться на стек практически сами.

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

доступ к памяти занимает больше времени, чем к регистрам - в этом и причина. Hу а адресовать можно легко аналогично и переменные в памяти по короткому адресу - что и было сделано в тех процах, если с умом применить индексные регистры, а не так как это сделано в кривых архитектурах вроде x86. (первые ~16 переменных адресуются всего 4 битами в коде команды - относительно индексного регистра, который указывает на ту область памяти, где хранятся переменные текущей процедуры)

Vladimir

Reply to
Vladimir V. Teplouhov

Hello George.

11 Apr 05 17:50, you wrote to Vladimir V Teplouhov: GS> Суббота Апрель 09 2005 07:20, Vladimir V Teplouhov wrote to George GS> Shepelev:

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

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

если применяется такая элементная база только. В ДHК, например, вообще 4-ричная и 20-ричная, и чаго? :)

Реально применялась знакоразрядная логика и числа фиббоначи - для более короткого переноса и введения избыточности.

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

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

Vladimir

Reply to
Vladimir V. Teplouhov

Hello George.

11 Apr 05 17:52, you wrote to Vladimir V Teplouhov: GS> Суббота Апрель 09 2005 22:38, Vladimir V Teplouhov wrote to George GS> Shepelev:

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

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

и его всякие разные уроды, по какой-то ошибке попавшие в *C, мудераторы и тп стали тут-же применять в своих целях.

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

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

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

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

Vladimir

Reply to
Vladimir V. Teplouhov

Hello George.

11 Apr 05 17:53, you wrote to Vladimir V Teplouhov: GS> Суббота Апрель 09 2005 22:46, Vladimir V Teplouhov wrote to Olga Nonova:

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

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

сколько они нынче стоят кстати?

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

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

Vladimir

Reply to
Vladimir V. Teplouhov

Hello Vladislav.

12 Apr 05 12:35, you wrote to me:

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

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

VB> Однако же и у AVR, к примеру, нельзя сделать EOR с VB> непосредственным операндом без загрузки вспомогательного регистра (и VB> не всякого, отметим). А у Z80 логические операции без A не работают...

Hе хватило кодового пространства.

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

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

VB> Так что при равной тактовой AVR окажется в проигрыше...

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

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

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

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

О. Когда я писал на асме (Это было всего пара программ), то наиболее часто используемые глобальные (По сишному - статические) переменные размещал в первых

16-регистрах, а вторые 16 - использовал как рабочие. Вполне нормально получается. (Это были 1200 и 2313 - маленькие)

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

А всего?

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

Alexey

Reply to
Alexey Boyko

Tue, 12 Apr 2005 16:52:52 +0400 Vladimir Vassilevsky wrote to Harry Zhurov:

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

HZ>> Да куда они денутся?! HZ>> "D:\slon\IAR\MSP430\V3\1\slon.c",22 Warning[Pe188]: enumerated type HZ>> mixed with another type

VV> Очень плохой компиллятор.

Очень хороший компилятор! Правильный!! Соответствует требованиям языка. Еще вчера приводили пример другого компилятора - GCC, который очень неплохо поддерживает Стандарт, он вообще даже предупреждения не выдал - имеет полное право. Не понимаю, с чем ты споришь? Ситуация с enum'ом в С (перечислимым _типом_ его называть у меня что-то желания все меньше) проста, прозрачна и очевидна. И если какой-то компилятор криво обрабатывает эту ситуацию, это проблема оного компилятора и его пользователей. Которая может быть отложена до момента перехода этих пользователей на более другие и более приличные компиляторы.

VV> Потому что даже Cosmic C, известный тем, что пропускает очевидные VV> ошибки, не позволяет смешивать перечислимые и числовые типы.

Безобразный компилятор! Где надо ловить ошибки, он пропускает, где ошибки нет, он ругается. Все наоборот! Безобразный компилятор! :-Р

HZ>> Я поступаю проще: не использую enum'ы в С.

VV> Я требую, чтобы в случаях, когда есть набор состояний, этот набор VV> был выделен в отдельный тип и описан как enum. Потому что это упрощает VV> правки и предотвращает некоторые ошибки.

Это ничем не лучше введения пачки макросов через #define. enum в С не является отдельным типом - он просто обычное целое.

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

VV> C++ есть, увы, не везде и не всегда.

Сочувствую. Мне везет больше - везде, где мне надо, он есть. И сегодня уже в очень приличном состоянии (с шаблонами). :-)

Reply to
Harry Zhurov

Tue, 12 Apr 2005 21:23:14 +0000 (UTC) Alexander Golov wrote to Alexey Boyko:

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

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

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

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

Reply to
Harry Zhurov

Hello Harry.

13 Apr 05 06:13, you wrote to Alexander Golov:

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

Да я понимаю. Я уже на стеб перешел. Да и сабж соответствующий.

Alexey

Reply to
Alexey Boyko

Hello George.

12 Apr 05 12:42, you wrote to me:

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

ОЗУ для хранения _инфы большого объема_.

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

50+50 = 100. Тогда хватит.

GS> Hе справляются, делались прикидки.

Плохо делали.

GS> AVR'ы удобны, когда важней всего GS> дешевизна

То есть, AVR-ы уже дешевле пиков?

GS> или в довольно экзотических задачках...

Как раз наоборот. Если тебе не хватает - значит у тебя задачи экхотические.

Alexey

Reply to
Alexey Boyko

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.