Embedded OS

Mar 08, 2005 Last reply: 21 years ago 1304 Replies

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

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

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

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

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

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

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

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

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

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

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

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

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

Hi Vladimir !

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

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

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

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

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

WBRgrds Ruslan

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

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

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

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

П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. Или всякие там счетчики или проверки/установки флагов и ветвление по ним. Все зависит от задачи...

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

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

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

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

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

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

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

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

Hello Vladislav.

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

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

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

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

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

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

Разумеется.

Alexey

Hello Alex!

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

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

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

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

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

Anatoly

Пpивет, Alexey!

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

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

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

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

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

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

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

Привет 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

[Жора, не хами !]

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

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

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

HÁÐÉÒÁÅÛØ ÎÁ ÚÁÉÍÓÔ×Ï×ÁÎÉÅ ËÏÄÁ, ÎÏ ÎÅ ÕÞÉÔÙ×ÁÅÛØ, ÞÔÏ ÚÁÞÁÓÔÕÀ ÐÒÏÝÅ ×ӣ ÓÎÁÞÁÌÁ É Ó ÎÕÌÑ... üÔÏ ÐÒÁËÔÉËÁ. é ÎÅ ÓÐÏÒØ.

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аполеон Бонапарт

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 ничего не храниться)

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

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

Hello Vladislav.

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

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

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

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

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

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

Alexey

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required