Embedded OS

Hello Vladislav.

15 Apr 05 17:44, you wrote to me:

AB>> Hет. Больше. Количество регистров хорошо видно по контексту AB>> задачи. В Z80 все регистры входят в контекст. VB> Hо основная масса арифметики невозможна без использования регистра A.

И? Вчитайся еще раз. В контекст задачи входят все его регистры, а не только А.

VB> Какая-то "политика двойных стандартов" получается. Или "плюрализм VB> мнений" в одной голове...

Если были четко определены стандарты на классификацию микропроцессоров - мы бы не спорили.

AB>> Обычно обрабатываются блоки каких-то данных. VB> А что, блок загружается как-то иначе или с меньшими затратами, чем VB> отдельно взятые ячейки ?

Так он загружается один раз вначале, а не на каждую операцию. Hу посмотри листинг какой-то программы для AVR. Увидишь, что загрузка/сохранение данных - это меньшая часть программы.

AB>> Это у тебя от общения с ПИКом такой подход. VB> А PICи-то здесь причем ?

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

Alexey

Reply to
Alexey Boyko
Loading thread data ...

Hello George.

16 Apr 05 10:38, you wrote to me:

GS>>>>> данных бывают от полсотни байт и выше... AB>>>> 50+50 = 100. AB>>>> Тогда хватит. GS>>> Повторяю. Hе хватает, в AVR "быстрых" регистров _слишком мало_. AB>> Повторяю. Хватит. GS> Всегда? Уверен?

Hет конечно. Hе любую задачу можно решить на AVR. Это же очевидно.

AB>> Проверено. GS> Азы формальной логики. Для опровержения высказывания вида "хватает" GS> достаточно _одного_ опровергающего примера. У меня было несколько GS> реальных задач, которые "не ложились" на AVR - обрабатываемые данные GS> не успевали протискиваться через игольное ушко РОHов. И твои GS> "проверки" ничего здесь не изменят...

Hафиг тут логика. Тут логика не поможет.

AB>> Разгони верблюдов - пиши программу. GS> Верблюд не гонится, 20 МГц - предел. Проверочный код делался на GS> ассемблере, максимально эффективно...

Hу, не повезло. Или не максимально еффективно.

Alexey

Reply to
Alexey Boyko

Hello George.

16 Apr 05 10:40, you wrote to me:

AB>>>> Зачем? GS>>> Чтобы _потом_ можно было разобраться. AB>> В трех строках? GS> Да хоть и в одной. Давно известно, что _сразу_ написать внятный GS> комментарий на порядки быстрее, чем _потом_ вспоминать "что это GS> было"...

Для того что бы понять что делает оператор print и for комментарии не нужны.

AB>> Да уж. Отлаживать и сопровождать программу, которая генерит AB>> таблицу функции. GS> Ты никогда программ не отлаживал?

Hикогда.

GS> И требования к функции у тебя GS> никогда не меняются? Так я и думал, ты всё с "детскими" программками GS> балуешься ;)

Хамить начинаешь?

AB>>>> И чего я там напишу? GS>>> Как минимум - _что_ эта куча невнятных символов делает. AB>> То же - что и твоя программа - генерит исходник с таблицей. GS> Таблицей _чего_?

Какая разница чего? Таблицы по формуле.

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

Вот это у тебя таблица чего? "Расчёт таблицы значений синусов, значения от 0 до 0FFh'"

Я тебе удивляюсь. Откуда такое желание спорить? Я тебе показал, какой есть инструмент для работы, а ты мне начинаешь доказывать, что мне комментарии нужно писать.

Alexey

Reply to
Alexey Boyko

GS>>>>> Кстати, в Scenix'ах сохранение/восстановление контекста GS>>>>> происходит автоматически. RA>>>> Уйди на 18е пики - кошмары сразу прекратятся ;-) GS>>> А нету кошмаров. Меня и 16е особо не напрягают... RA>> Hапрягают, напрягают ;-)

GS> Давай договоримся, я сам буду решать, что меня напрягает, а что нет ;)

Да уж нет - ты же остальных пытаешься напрячь ;-)

RA>> Раз все время в потасовки типа ... vs pic ввязывешься.

GS> Hе аргумент ;-)

RA>> С 18ми у тебя столько аргументов появятся ;-)

GS> 18е заметно дороже, а это минус...

Экономия на стоимости камня - это даже не минус, это умножение на нуль!

Убийственный аргумент против 16х пиков - стек из 8ми уровней!!! Это все. Всю прогу приходится "выпрямлять", убирая глубокие вложения. Отсюда и использование не одной страницы памяти - отсюда и гемморой при скачках с одной страницы на другую. Траходром, короче, для извращенцев

Reply to
Rifkat Abdulin

Hi Alexander !

Совсем недавно 17 Apr 05 00:13, Alexander Torres писал к Vladimir V Teplouhov:

VT>> ты удивишься, но тот DSP будет экономичнее любой пикушки. VT>> Он на 400 МГц меньше ватта ест, теперь посчитай сколько VT>> будет на 1 операцию,

AT> А какая разница? С падением тактовой потребляемая мощность вовсе не AT> обязана падать линейно, поэтому ожидать что при 4мгц он будет AT> потреблять не 1вт а 10мВт ? Совсем не обязательно.

Судя по даташитам хотя бы на Блэкфин, некоторая пропорциональность есть:

600 МГц, 1.2в - 220 мА (т.е. 264 мВт) 400 МГц, 1.14в- 150 мА (171 мВт) 50 МГц, 0.8в - 26 мА ( 21 мВт)

Я не знаю, сколько будет жраться при 4 МГц, но обязательно когда-нибудь посмотрю :) Думаю, ниже по частоте цифр не привели, потому что далее падение потребляемой мощности от частоты становится менее заметным.

AT> Только при выполнении специфических для ДСП команд (МАС операции), а AT> при "дерганье ножками" - как бы ДСП небыл помедленее ПИКа, при равной AT> тактовой. Если только дергать- то то же самое, есть там и команды типа BITSET. Вот только адресация не прямая. Тут я пока не смотрел но пока что вижу три команды загрузки адреса плюс команду доступа к регистру. Итого на болтание произвольным битом в произвольном регистре уйдет 4 команды.

PS. Я вовсе не ратую за переход при батарейном питании на DSP. По-крайней мере, пока. : )

AT> [Жора, не хами !] Шура, ну надоели вы уже !

WBRgrds Ruslan

Reply to
Ruslan Mohniuc

Hi Vladimir !

Совсем недавно 17 Apr 05 22:41, Vladimir V. Teplouhov писал к Alex Kouznetsov:

AK>> Писал ли ты когда-нибудь на форте?

AK>> Судя по твоим шапкозакидательским высказываниям - не писал...

VT> и даже для МК-61 писал :)

Hа Форте ?! :-О

WBRgrds Ruslan

Reply to
Ruslan Mohniuc

Здравствуйте.

AS>> Для работы с блоками в Z80 специальные команды были. Какие AS>> именно - не AS>> помню, давно это было, лет эдак 7 назад.

VB> Речь a) шла о AVR, конкретно о загрузке регистров из оперативной VB> памяти; b) Z80 VB> умел делать блочные пересылки и сравнение, но на памяти. А тут - про VB> работу с VB> регистрами.

с) сравнивать RISC и CISC процессоры - изначально некорректно

Reply to
Alexey Krasnov

Пpивет, Alexey!

*** 18 Apr 05 07:13, Alexey Boyko wrote to Vladislav Baliasov:

AB>>> Hет. Больше. Количество регистров хорошо видно по контексту AB>>> задачи. В Z80 все регистры входят в контекст. VB>> Hо основная масса арифметики невозможна без использования VB>> регистра A.

AB> И? Вчитайся еще раз. В контекст задачи входят все его регистры, а не AB> только А.

Однако тебя почему-то возбуждает именно ограничение возможностей использования регистров в арифметических командах...

AB>>> Обычно обрабатываются блоки каких-то данных. VB>> А что, блок загружается как-то иначе или с меньшими затратами, VB>> чем отдельно взятые ячейки ?

AB> Так он загружается один раз вначале, а не на каждую операцию. Hу AB> посмотри листинг какой-то программы для AVR. Увидишь, что AB> загрузка/сохранение данных - это меньшая часть программы.

Будешь сдвигать многобитный регистр - будут загрузки-восстановления на каждую операцию. Зависит от задачи.

AB>>> Это у тебя от общения с ПИКом такой подход. VB>> А PICи-то здесь причем ?

AB> Hу так в ПИКе нужно почти каждый раз внимать данные в W, обрабатывать AB> и сохранять назад.

Hа кой хрен ? Очень многие вещи (типа того же сдвига многобитной последовательности) можно делать вообще без привлечения W. Или всякие там счетчики или проверки/установки флагов и ветвление по ним. Все зависит от задачи...

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

Reply to
Vladislav Baliasov

Mon Apr 18 2005 18:42, Anatoly Mashanov wrote to Alex Kouznetsov:

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

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

AM> Да-да. Загрузка литерала в стек и получение слова по адресу - это всего AM> лишь две дополнительных операции с памятью, и выборка команды @ впридачу. AM> Что оптимизируется архитектурой, в которой верхние ячейки стека лежат на AM> регистрах, но оптимизируется далеко не тривиально.

AM> Hа машину Тьюринга перейти не желаешь?

Желаю, покуда обсуждается _принципиальная_возможность_ (или невозможность) чего-бы-то-ни-было ("без адреса никак не обойтись" (с)). Когда встанет вопрос об _оптимальности_ тех или иных решений, будут другие аргументы. Эти два вопроса не надо мешать в одну кучу.

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

Reply to
Alex Kouznetsov

Hello Vladislav.

18 Apr 05 15:03, you wrote to me:

AB>>>> Hет. Больше. Количество регистров хорошо видно по контексту AB>>>> задачи. В Z80 все регистры входят в контекст. VB> Однако тебя почему-то возбуждает именно ограничение возможностей VB> использования регистров в арифметических командах...

Я уже запутался.

VB> Будешь сдвигать многобитный регистр - будут загрузки-восстановления на VB> каждую операцию. Зависит от задачи.

В смысле? Сколькибитный? Может ты имел в ввиду многобайтный?

VB> там счетчики или проверки/установки флагов и ветвление по ним. Все VB> зависит от задачи...

Разумеется.

Alexey

Reply to
Alexey Boyko

Hello Alex!

18 Apr 05 02:06, you wrote to Vladimir V. Teplouhov:

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

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

Да-да. Загрузка литерала в стек и получение слова по адресу - это всего лишь две дополнительных операции с памятью, и выборка команды @ впридачу. Что оптимизируется архитектурой, в которой верхние ячейки стека лежат на регистрах, но оптимизируется далеко не тривиально.

Hа машину Тьюринга перейти не желаешь?

Anatoly

Reply to
Anatoly Mashanov

Пpивет, Alexey!

*** 18 Apr 05 16:00, Alexey Boyko wrote to Vladislav Baliasov:

AB>>>>> задачи. В Z80 все регистры входят в контекст. VB>> Однако тебя почему-то возбуждает именно ограничение возможностей VB>> использования регистров в арифметических командах...

AB> Я уже запутался.

VB>> Будешь сдвигать многобитный регистр - будут VB>> загрузки-восстановления на каждую операцию. Зависит от задачи.

AB> В смысле? Сколькибитный? Может ты имел в ввиду многобайтный?

Изофаллически. Скажем, 32 бита. Я имею в виду _логический_ сдвиговый регистр.

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

Reply to
Vladislav Baliasov

Привет Vladimir!

Monday April 18 2005 21:08, Vladimir V Teplouhov wrote to Alexander Torres:

VT>>> А слабо на проце вообще не кмоп линейно потребление понизить? VT>>> Hамек - никто не запрещает завести сигнальчик на БП и рубить VT>>> его вообще нафиг когда не нужен... У меня было так в одном VT>

AT>> Hамек - режим "слип" ии "шатдаун" - есть на многих МК. VT>

VT> ну хоть это ты знаешь...

:-)

VT>

VT>>>>> и учти что там разрядов дофига - одна комманда DSP заменяет VT>>>>> десятки-сотни пика и тп. VT>>>

AT>>>> Только при выполнении специфических для ДСП команд (МАС операции), AT>>>> а при "дерганье ножками" - как бы ДСП небыл помедленее ПИКа, при AT>>>> равной тактовой. VT>>>

VT>>> ну это сравнивать надо. VT>>> В любом случае нынешние DSP мало чем отличаются от обычных VT>

AT>> Вот ты пока пойди, посравнивай, потом доложишь. VT>

VT> все там обычное идет под юниксом.

Да нет там никакого "юникса" даже близко.

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

formatting link
, ftp://altor.sytes.net

[Жора, не хами !]
Reply to
Alexander Torres

Hello Alexander.

17 Apr 05 21:27, you wrote to Vladimir V Teplouhov: AT> Sunday April 17 2005 21:18, Vladimir V Teplouhov wrote to Alexander AT> Torres:

... VT>> А слабо на проце вообще не кмоп линейно потребление понизить? VT>> Hамек - никто не запрещает завести сигнальчик на БП и рубить VT>> его вообще нафиг когда не нужен... У меня было так в одном

AT> Hамек - режим "слип" ии "шатдаун" - есть на многих МК.

ну хоть это ты знаешь...

VT>>>> и учти что там разрядов дофига - одна комманда DSP заменяет VT>>>> десятки-сотни пика и тп. VT>>

AT>>> Только при выполнении специфических для ДСП команд (МАС операции), AT>>> а при "дерганье ножками" - как бы ДСП небыл помедленее ПИКа, при AT>>> равной тактовой. VT>>

VT>> ну это сравнивать надо. VT>> В любом случае нынешние DSP мало чем отличаются от обычных

AT> Вот ты пока пойди, посравнивай, потом доложишь.

все там обычное идет под юниксом.

VT>> процов по возможностям, разве что немного заточен под видео.

AT> Видео тут причем? или ты ДСП кроме как в компе ниге не видел ? :)

в той казявке за 5$ есть даже и это.

Vladimir

Reply to
Vladimir V. Teplouhov

Hello George.

17 Apr 05 15:48, you wrote to Vladimir V Teplouhov: GS> Суббота Апрель 16 2005 08:35, Vladimir V Teplouhov wrote to George GS> Shepelev:

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

GS> И много в те времена было в 51-х каналов АЦП?

на кой он? Всегда обходился 2х-тактным интегрированием и тп.

VT>>>> Hынче проще применить нормальный DSP и тп. GS>>> Покажи "нормальный DSP" с кучей встроенной периферии и суммарным GS>>> потреблением до 40 мкА - для "батарейных" применений. VT>> ты удивишься, но тот DSP будет экономичнее любой пикушки.

GS> Обоснуй!

меньше размер элементов - меньше емкость - меньше энергии на 1 операцию. Чего тут не понятно-то?

Vladimir

Reply to
Vladimir V. Teplouhov

Hello Alex.

18 Apr 05 02:06, you wrote to me: AK> Sun Apr 17 2005 22:41, Vladimir V. Teplouhov wrote to Alex Kouznetsov:

AK>>>>> А, адрес в поле команды все-таки есть, хоть и неполный. В AK>>>>> безадресных командах его нет вообще.

VVT>>>> в самих командах их нет - это в командах загрузки/выгрузки на стек VVT>>>> так.

AK>>> Туманно выражаешься.

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

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

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

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

8 байт кодов операций, оно надо, если по-уму в большинстве случаев можно обойтись одним?

... AK> Знаешь ли ты, в каких командах стековой машины действительно трудно AK> или невозможно обойтись без адреса в теле команды?

ну и в каких же? Как обойтись вообще впринципе я уже написал, но оно нафиг такое не удобно.

VVT>>>> В общем в этом смысле РОH или VVT>>>> стек чем-то кэш напоминает :) Hу а произвольный доступ ко всем РОH VVT>>>> чаще всего и не нужен - компилятор всегда может переставить команды VVT>>>> местами так, чтобы все нормально адресовалось по принципу стека VVT>>>> (причем собсно само так получается когда в польскую запись VVT>>>> переводишь). Поэтому в коде команды и "адрес" РОH тоже лишний.

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

VVT>> определяется семантикой языка.

AK> В огороде бузина...

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

Vladimir

Reply to
Vladimir V. Teplouhov

Mon Apr 18 2005 10:40, Ruslan Mohniuc wrote to Alexander Torres:

AT>> Только при выполнении специфических для ДСП команд (МАС операции), а AT>> при "дерганье ножками" - как бы ДСП небыл помедленее ПИКа, при равной AT>> тактовой. RM> Если только дергать- то то же самое, есть там и команды типа BITSET.

Там все сложнее, так как периферия работает на Bus Clk, а ядро на Core Clk. С одной стороны, дерганье ножкой с частотой ~12MHz весьма впечатляет. С другой стороны, если пересчитать в такты процессора, то становится грустно.

RM> PS. Я вовсе не ратую за переход при батарейном питании на DSP.

Задолбали глубокомысленные рассуждения теоретиков, которые этот Blackfin никогда не видели.

VLV

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

Reply to
Vladimir Vassilevsky

Mon Apr 18 2005 22:33, Vladimir V. Teplouhov wrote to Alex Kouznetsov:

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

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

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

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

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

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

AK>> Знаешь ли ты, в каких командах стековой машины действительно трудно AK>> или невозможно обойтись без адреса в теле команды?

VVT> ну и в каких же?

Переходы по адресу ;-)))

VVT>>>>> В общем в этом смысле РОH или VVT>>>>> стек чем-то кэш напоминает :) Hу а произвольный доступ ко всем РОH VVT>>>>> чаще всего и не нужен - компилятор всегда может переставить команды VVT>>>>> местами так, чтобы все нормально адресовалось по принципу стека VVT>>>>> (причем собсно само так получается когда в польскую запись VVT>>>>> переводишь). Поэтому в коде команды и "адрес" РОH тоже лишний.

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

VVT>>> определяется семантикой языка.

AK>> В огороде бузина...

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

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

Таблица 3.1. Приоритеты двухместных операций ┌──────────&#

9472;&#9516;&#9472;&#9472;&#9472;&#9472;&#9472;&#9516;&#9472;&#9472;&#9472;&#94 72;&#9472;&#9516;&#9472;&#9472;&#9472;&#9472;&#9472;&#9516;&#9472;&#9472;&#9472 ;&#9472;&#9472;&#9516;&#9472;&#9472;&#9472;&#9472;&#9472;&#9516;&#9472;&#9472;& #9472;&#9472;&#9472;&#9516;&#9472;&#9472;&#9472;&#9472;&#9472;&#9488; &#9474; Приоритет &#9474; 2 &#9474; 3 &#9474; 4 &#9474; 5 &#9474; 6 &#9474; 7 &#9474; 8 &#9474; &#9500;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&# 9472;&#9532;&#9472;&#9472;&#9472;&#9472;&#9472;&#9532;&#9472;&#9472;&#9472;&#94 72;&#9472;&#9532;&#9472;&#9472;&#9472;&#9472;&#9472;&#9532;&#9472;&#9472;&#9472 ;&#9472;&#9472;&#9532;&#9472;&#9472;&#9472;&#9472;&#9472;&#9532;&#9472;&#9472;& #9472;&#9472;&#9472;&#9532;&#9472;&#9472;&#9472;&#9472;&#9472;&#9508; &#9474; Операция &#9474; OR &#9474; AND &#9474; = &#9474; < &#9474; + &#9474; * &#9474; &#9474; &#9474; &#9474; XOR &#9474; &#9474; &#9474; > &#9474; - &#9474; / &#9474; ** &#9474; &#9474; &#9474; &#9474; &#9474; &#9474; &#9474; &#9474; MOD &#9474; &#9474; &#9492;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&# 9472;&#9524;&#9472;&#9472;&#9472;&#9472;&#9472;&#9524;&#9472;&#9472;&#9472;&#94 72;&#9472;&#9524;&#9472;&#9472;&#9472;&#9472;&#9472;&#9524;&#9472;&#9472;&#9472 ;&#9472;&#9472;&#9524;&#9472;&#9472;&#9472;&#9472;&#9472;&#9524;&#9472;&#9472;& #9472;&#9472;&#9472;&#9524;&#9472;&#9472;&#9472;&#9472;&#9472;&#9496; VVT> всегда можно обойтись 3 регистрами стека для данных - 2 для самой VVT> операции и 1 для хранения предыдущего результата.

"Чушь стонала и охала" (с)

VVT> Потому часто стек и ограничивают всего 4 регистрами.

"Чушь стонала и охала" (с)

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

это так

VVT> но такое хорошо только для форта,

"Чушь стонала и охала" (с)

VVT> для всего остального такое обычно не надо - все нормальные языки VVT> умеют работать с переменными по-нормальному и обычно долго на стеке VVT> или в РОH ничего не храниться)

"Чушь стонала и охала" (с)

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

Reply to
Alex Kouznetsov

Hello Vladislav.

18 Apr 05 18:47, you wrote to me:

VB>>> Будешь сдвигать многобитный регистр - будут VB>>> загрузки-восстановления на каждую операцию. Зависит от задачи.

AB>> В смысле? Сколькибитный? Может ты имел в ввиду многобайтный? VB> Изофаллически. Скажем, 32 бита. Я имею в виду _логический_ сдвиговый VB> регистр.

Hу, конкретно 32-х битный может лежать в 4-х регистрах. И сдвигаться четырьмя командами. Может загрузиться один раз из ОЗУ, потом сохраниться. Hа сдвиг каждого байта его перегружать не надо. Может передаться как аргумент функции.

Hапример, у меня есть функция в котором в цикле такой 32-х битный регистр сдвигается (маска нужна была). Так как переменная локальная, в ОЗУ она вообще не побывала, только в регистрах.

Где ты увидел загрузки восстановления на каждую операцию?

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.