LINUX.ORG.RU

Ларри говорит: «Не отдам спарки!»

 , ,


0

0

Вопреки прогнозам некоторых мировых аналитиков о том, что Oracle продаст железный бизнес Sun на сторону, Ларри Эллисон заявил, что он никому ничего не продаст и все оставит себе. Oracle собирается инвестировать в спарки, и работать вместе с Fujitsu, с которым ранее работал Sun. Он заявил, что разработка и железа, и софта позволяет создавать более совершенные системы (как это делает IBM), чем просто разработка софта, «вот почему телефоны Apple намного лучше, чем телефоны Microsoft».

Покупка компанией Oracle компании Sun (номера 4 на рынке) сделала их номером 2 на рынке хай-энд серверов. «Sun был очень успешен долгое время, продавая системы на базе спарков и соляриса, теперь мы туда добавим ПО Oracle и выведем эти системы на прежний уровень».

Лора ДиДио (аналитик ITIC) отметила, что Sun всегда разрабатывал отличное железо, но был слабоват в маркетинге, а Ларри великолепный маркетолог.

>>> ZDNet

★★★★★

Проверено: anonymous_incognito ()
Ответ на: комментарий от elipse

>2. обойдемся без кулибинства , ok ?

ок:)

То, что в x86 многие команды могут выполняться параллельно (в т.ч. и из-за т.н. "переименования" регистров, "теневых" регистров - это тоже "кулибинство"?

Led ★★★☆☆
()
Ответ на: комментарий от elipse

>1.LEA -- Load Effective Address

>2. обойдемся без кулибинства , ok ?

Кстати, врядли можно назвать "кулибинством" то, что описано в ЛЮБОМ, даже в самом древнем учебнике по x86-ассемблеру.

Led ★★★☆☆
()
Ответ на: комментарий от Led

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

ага , и это тоже
также и 4 ярусные кеши в 2 гига с водяным охлаждением ... и прочие костыли.
Так как эти штучки просто маскируют недостатки нативной архитектуры CPU.

elipse ★★★
()
Ответ на: комментарий от Led

>Кстати, врядли можно назвать "кулибинством" то, что описано в ЛЮБОМ, >даже в самом древнем учебнике по x86-ассемблеру.


Не факт ,что это будет делать компилятор.
Может напомнить сколько лет ушло на обуздание кулибинства и создание эффективных компиляторов для x86 ? :))

elipse ★★★
()
Ответ на: комментарий от elipse

Добавлю свои 2 копейки.

То что при обращении к памяти через push/pop посчитали latency уже хорошо. Теперь нужно пойти дальше и посчитать "time to retire", то есть время между инструкцией обновления регистра и время, когда регистр может уже использоваться. Обычно "time to retire" от 2 до 6 тактов, в зависимости от размера и типа обновляемого регистра. В большинстве случаев это надо мерять, поскольку реальное время исполнения будет также зависить от предыдущих и последующих инструкций.

Что касается "что в x86 многие команды могут выполняться параллельно", то load/store как раз не могут. Впрочем, х86 тут не причем. Проблема заключается в том, что для арифметики можно создать конвейерные АЛУ (что и делается для скрытия "time to retire"), то для load/store это сделать нельзя - шину то к кэш никто не дублирует. Если шина занята, то следующий outstanding request вызывает stall. Чтобы скрыть этот stall, обычно делают request-FIFO на какое-то (10-20) количeство запросов, после чего выполняюt flash всей очереди (от 10 до 20 clks).

VIT
()
Ответ на: комментарий от VIT

Короче, как не крути, а 5-6 раз разница набегает легко. Поэтому, больше регистров всяко лучше чем меньше ;).

VIT
()
Ответ на: комментарий от Led

> 4. lea a,[a+b+$5]

> Сколько тактов?:)

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

lea ax,[a+b+$5]

mov dx, ptr[ax]

Могу ошибаться.

VIT
()
Ответ на: комментарий от elipse

>Не факт ,что это будет делать компилятор.

Факт. Компилятор так и делает.

Led ★★★☆☆
()
Ответ на: комментарий от VIT

>Теперь нужно пойти дальше и посчитать "time to retire", то есть время между инструкцией обновления регистра и время, когда регистр может уже использоваться.

В x86 регистров значительно больше, чем имён для них:) Пока регистр будет "обновляться", под его именем уже можно использовать другой.

Led ★★★☆☆
()
Ответ на: комментарий от Led

>> Теперь нужно пойти дальше и посчитать "time to retire", то есть время между инструкцией обновления регистра и время, когда регистр может уже использоваться.

> В x86 регистров значительно больше, чем имён для них:) Пока регистр будет "обновляться", под его именем уже можно использовать другой.

А данные откуда возьмете в "новом регистре"?

VIT
()
Ответ на: комментарий от VIT

>Короче, как не крути, а 5-6 раз разница набегает легко. Поэтому, больше регистров всяко лучше чем меньше ;).

Естественно. Разве кто-то с этим спорил? Вот только даже в тупом x86 регистром НАМНОГО больше, чем вам, возможно, кажется:)

Led ★★★☆☆
()
Ответ на: комментарий от VIT

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

Поправляю. Вы неправы. Эта инструкция вычисляет "адрес" и помещает его в регистр. Я, конечно, ламер, но даже мне это было известно ещё в 80-ых из учебников Абеля и Джордейна:)

Led ★★★☆☆
()
Ответ на: комментарий от VIT

>А данные откуда возьмете в "новом регистре"?

Оно там "прозрачно" продублируется (отзеркалится) из "старого регистра"

Led ★★★☆☆
()
Ответ на: комментарий от Led

>Естественно. Разве кто-то с этим спорил? Вот только даже в тупом x86 >регистром НАМНОГО больше, чем вам, возможно, кажется:)

http://www.logix.cz/michal/doc/i386/chp02-03.htm#02-03

А сколько должно казаться нам по вашему ?

elipse ★★★
()
Ответ на: комментарий от Led

>Поправляю. Вы неправы. Эта инструкция вычисляет "адрес" и помещает >его в регистр. Я, конечно, ламер, но даже мне это было известно ещё в >80-ых из учебников Абеля и Джордейна:)

:)))
4.2
ну освежим вам склероз манехо:
http://pdos.csail.mit.edu/6.828/2004/readings/i386/LEA.htm

lea ax,[a+b+$5] да, а и b тут не регистры - ну никак:))
еще как вычисляемый по месту ассемблирования макрос или выражение проканает.





elipse ★★★
()
Ответ на: комментарий от Led

> Поправляю. Вы неправы. Эта инструкция вычисляет "адрес" и помещает его в регистр. Я, конечно, ламер, но даже мне это было известно ещё в 80-ых из учебников Абеля и Джордейна:)

А данные где? Адрес то мне не нужен. Мне с данными работать нужно.

VIT
()
Ответ на: комментарий от Led

>>А данные откуда возьмете в "новом регистре"?

> Оно там "прозрачно" продублируется (отзеркалится) из "старого регистра"

А... Еще скажите "само" и "мнгновенно".

VIT
()
Ответ на: комментарий от elipse

Тут хитрость в том, что a+b+$5 может вычислить и макроассемблер. В любом случае, lea не является инструкцией - это динамический макрокод.

Вообще мне сдаётся, что Led слышал кое-где кое-как, но в деталях не очень разбирается. Регистры у него инопланетные, данные появляются "прозрачно" и "сами". Так только на бейсике можно программировать. Ну или базы данных там какие нибудь.

VIT
()
Ответ на: комментарий от VIT

>Тут хитрость в том, что a+b+$5 может вычислить и макроассемблер. В >любом случае, lea не является инструкцией - это динамический макрокод.

Ну, так как намек про кулибинство остался непонятным :))
Тут это не хитрость ,и в данном случае просто выкрутасы
- ведь всю вычислительную работу сделает ассемблер с данными в виде констант.

elipse ★★★
()
Ответ на: комментарий от elipse

> Ну, так как намек про кулибинство остался непонятным :))

Никакого кулибинства тут и нет :). Впрочем, данных тоже.

> Тут это не хитрость ,и в данном случае просто выкрутасы - ведь всю вычислительную работу сделает ассемблер с данными в виде констант.

Правильно. Но при чём тут "выкрутасы" - программист использовал "свёрку констант". К первоначальному обсуждению иммет точно такое же отношение, как "ответ 7, знаю без процессора" ;).

VIT
()
Ответ на: комментарий от VIT

> Никакого кулибинства тут и нет :). Впрочем, данных тоже.

Ну ,надо же было дать шанс одуматься человеку ? :))

elipse ★★★
()
Ответ на: комментарий от elipse

>lea ax,[a+b+$5] да, а и b тут не регистры - ну никак:))

>еще как вычисляемый по месту ассемблирования макрос или выражение проканает.

А откуда появился "ax"? В vm86-режиме - да, вариант с [a+b+$5] не прокатит, но в 32/64-битном - работает.

Led ★★★☆☆
()
Ответ на: комментарий от VIT

>А данные где? Адрес то мне не нужен. Мне с данными работать нужно.

lea a, [b+c+#5]

Данные - в "a"

a == b+c+#5,

где a,b,c - регистры, #5 - константа.

Led ★★★☆☆
()
Ответ на: комментарий от VIT

>А... Еще скажите "само" и "мнгновенно".

Само. "мгновенно" - не скажу, потому что это из той же оперы, что ваши "в 5-6 раз":)

Led ★★★☆☆
()
Ответ на: комментарий от VIT

>Вообще мне сдаётся, что Led слышал кое-где кое-как, но в деталях не очень разбирается.

Вы правы: это вам только "сдаётся":)

>Регистры у него инопланетные, данные появляются "прозрачно" и "сами". Так только на бейсике можно программировать. Ну или базы данных там какие нибудь.

Ну, я ведь сказал, что я ламер - куда мне до гуру, преподносящих регистровые окна как вершину процессорной логики:)

Led ★★★☆☆
()
Ответ на: комментарий от elipse

>- ведь всю вычислительную работу сделает ассемблер с данными в виде констант.

Нет. С точки зрения процессора - это одна команда: сложение двух регистров с константой и помещение результата в третьий регистр.

Led ★★★☆☆
()
Ответ на: комментарий от Led

>>Ну ,надо же было дать шанс одуматься человеку ? :))

>Ок, даю:)

Мне абсолютно не сложно (ок, не очень сложно:) признаться, если я прогнал и был неправ (что я сделал выше). А вам?:)

Led ★★★☆☆
()
Ответ на: комментарий от Led

>С точки зрения процессора - это одна команда: сложение двух регистров с константой и помещение результата в третьий регистр.

Если непонятно на a/b/c-регистрах, предложенных eclipse'ом, держите "живой" пример:

lea eax, [ebp+ecx*4+12345678h] ;7 байт

(здесь немного сложнее - тут ещё и умножение (вернее, сдвиг, потому что умножать можно (AFAIR) только на 2 и 4 (ещё на 8 на x86_64) - потому и "целых" 7 байт (4 из которых занимает константа)

Led ★★★☆☆
()
Ответ на: комментарий от Led

>>- ведь всю вычислительную работу сделает ассемблер с данными в виде констант.

> Нет. С точки зрения процессора - это одна команда: сложение двух регистров с константой и помещение результата в третьий регистр.

Так вроде разговор был о загрузке данных из памяти (L1 cache). Или я уже сам потерялся ;).

VIT
()
Ответ на: комментарий от Led

> Мне абсолютно не сложно (ок, не очень сложно:) признаться, если я прогнал и был неправ (что я сделал выше). А вам?:)

А ещё сложнее сначала разобраться, а потом писать. В чём, скажем, мне признаваться в прогоне?

VIT
()
Ответ на: комментарий от Led

> Ссылок на учебники под рукой нет, вот что легко нашлось: http://wasm.ru/article.php?article=1010001

AMD64 Architecture
Programmer’s Manual
Volume 1:
Application Programming
стр 49

3.3.5 Load Effective Address
• LEA—Load Effective Address
The LEA instruction calculates and loads the effective address (offset within a given segment) of a
source operand and places it in a general-purpose register.
LEA is related to MOV, which copies data from a memory location to a register, but LEA takes the
address of the source operand, whereas MOV takes the contents of the memory location specified by
the source operand. In the simplest cases, LEA can be replaced with MOV. For example:
lea eax, [ebx]
has the same effect as:
mov eax, ebx
However, LEA allows software to use any valid addressing mode for the source operand. For example:
lea eax, [ebx+edi]
loads the sum of EBX and EDI registers into the EAX register. This could not be accomplished by a
single MOV instruction.

LEA has a limited capability to perform multiplication of operands in general-purpose registers using
scaled-index addressing. For example:
lea eax, [ebx+ebx*8]
loads the value of the EBX register, multiplied by 9, into the EAX register.
------------------------
вот варианта как регистр + регистр + константа - я не нашел
может вам повезет ?
:)

elipse ★★★
()
Ответ на: комментарий от elipse

>вот варианта как регистр + регистр + константа - я не нашел

>может вам повезет ?

Да вот, как бы уже лет двадцать с таким везет:)

Держите строку, полученную из objdump'а:

8d 84 42 1a 00 00 00 lea 0x1a(%edx,%eax,2),%eax

Led ★★★☆☆
()
Ответ на: комментарий от VIT

>В чём, скажем, мне признаваться в прогоне?

А я вам и не предлагал. Это eclipse прогнал (с кем не бывает?), а вы ему поверили (с кем не бывает):)

Led ★★★☆☆
()
Ответ на: комментарий от Led

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

Я так понимаю, что кто-то изначально привёл пример этой инструкции как "быстрый load из кэш". В конце-концов выяснили, что инструкция не выполняет load, а работает с регистрами. (Ну чтобы она дольше работала, можно было ещё sin какой-нибудь запросить.) Прогнал тот, кто привёл в контексте разговора некорректную инструкцию, демонстрирующую вообще не то, что хотелось. То есть вы, Led.

VIT
()
Ответ на: комментарий от Led

Что именно я прогнал ?
Вы подменяете тему регистров гнилыми частными трюками x86.
И превращаете все в балаган x86 :))
Вообще ,операция сложения в примере частный случай.

elipse ★★★
()
Ответ на: комментарий от elipse

>Вы подменяете тему регистров гнилыми частными трюками x86.

"гнилыми"?

"частными"? да, я привёл пример, любой пример - частный случай:)

>И превращаете все в балаган x86 :))

"балаган"?:)

Мне не нравится архитектура x86. А ещё мне не нравится, когда начинают что бы то ни было хаять, не зная о предмете элементарных вещей из учебника, прикрываясь высокопарными заявлениями о "крутости регистровых окон на спарках":)

Led ★★★☆☆
()
Ответ на: комментарий от elipse

>Вообще ,операция сложения в примере частный случай.

Да.

А операция вычитания - это частный случай операции сложения:)

А умножение зачастую можно заменить сдвигом или сдвигом со сложением:)

А сравнение - это частный случай вычитания:)

Что там ещё осталось? Деление? Да здесь воможностей для "манёвра" поменьше:)

Или будем тригонометрию считать на CPU?:)

Led ★★★☆☆
()
Ответ на: комментарий от Led

>Мне не нравится архитектура x86. А ещё мне не нравится, когда >начинают что бы то ни было хаять, не зная о предмете элементарных >вещей из учебника, прикрываясь высокопарными заявлениями о "крутости >регистровых окон на спарках":)

Ага ,ну еще так не изворачивались ...
Крутость регистровых окон легко проверялась на Intel 8051
и Intel 196 KR - это как лет 15 назад еще.
Для обработки прерываний это было идеально и для переключения контекста задач (разумеется ,число задач ограниченно и их не сотни ).

Но ,у Intel все что не x86 дохнет как мухи по непонятным причинам.





elipse ★★★
()
Ответ на: комментарий от Led

>Что там ещё осталось? Деление? Да здесь воможностей для "манёвра" поменьше:)

Ну если , это весь ваш уровень аргументации - вопросов нет тогда.

elipse ★★★
()
Ответ на: комментарий от VIT

>Какая разница, кто правильно написал макроинструкцию?

Это не макроинструкция.

>И от того, что будет она выполняться 3 такта что изменится?

Ну, при 3-х тактах сложнее сказать, что на sparc'ах будет "в 5-6 раз быстрее":)

>Прогнал тот, кто привёл в контексте разговора некорректную инструкцию

Я привёл абсолютно корректную инструкцию

>демонстрирующую вообще не то, что хотелось

Она делает ровно то же, что показывал в своих примерах eclipse: складывает два регистра и константу и результат помещает в третий регистр. Естетсвенно, она не демонстрирует ни "превосходство" x86, ни "превосходство" sparc. Это был стёб, имеющий целью показать, что на таких тупых примерах показывать "превосходство регистроввых окон" над "стековыми операциями" - глупо. А оказалось, что этот стёб выявил (честно, я не хотел:), что критики x86 не знакомы с критикуемым ними объектом даже на уровне "букваря":)

Led ★★★☆☆
()
Ответ на: комментарий от elipse

>Для обработки прерываний это было идеально и для переключения контекста задач (разумеется ,число задач ограниченно и их не сотни ).

Вот! Я этого уже полсуток жду!:)

Естественно, регистровые окна МОГУТ быть полезны! Но это нишевая полезность и на CPU претендующим на универсальность (без ограничений на количество контекстов) - это в лучшем случае бесполезность, которая только неоправданно усложняет CPU.

Ещё раз: x86 ДАЛЕКО не идеален! Как и SPARC, в том числе из-за атавизмов типа пресловутого "регистрового окна" - ну есть оно, ну и ладно, но какого хрена выдавать его за ГЛАВНЕЙШЕЕ достоинство? Неужели больше нЕчего в ХОРОШИЙ пример привести?:)

Led ★★★☆☆
()
Ответ на: комментарий от Led

>Она делает ровно то же, что показывал в своих примерах eclipse: >складывает два регистра и константу и результат помещает в третий >регистр. Естетсвенно, она не демонстрирует ни "превосходство" x86, ни >"превосходство" sparc. Это был стёб, имеющий целью показать, что на >таких тупых примерах показывать "превосходство регистроввых окон" над >"стековыми операциями" - глупо. А оказалось, что этот стёб выявил >(честно, я не хотел:), что критики x86 не знакомы с критикуемым ними >объектом даже на уровне "букваря":)


Какое радостное щебетание :))
О регистровых окнах c вами и речи еще не было .
Только попробовали смоделировать нехватку регистров и обход через push
и pop - и почалось банальное траханье мозгов .

elipse ★★★
()
Ответ на: комментарий от Led

> Вот! Я этого уже полсуток жду!:)

просто читать тред надо, это уже тут упоминалось

elipse ★★★
()
Ответ на: комментарий от elipse

>Только попробовали смоделировать нехватку регистров и обход через push и pop - и почалось банальное траханье мозгов .

А почему через pushad/popad не попробовали "обход нехватки регистров"?:)

Led ★★★☆☆
()
Ответ на: комментарий от Led

>Естественно, регистровые окна МОГУТ быть полезны! Но это нишевая >полезность и на CPU претендующим на универсальность (без ограничений >на количество контекстов) - это в лучшем случае бесполезность, >которая только неоправданно усложняет CPU.

Бааа , да Вы технолог оказывается еще ? :))

Эти "сложности" есть как стандарт в микроконтроллерах за 1,5$.
А вот кеш ...

>Как и SPARC, в том числе из-за атавизмов типа пресловутого >"регистрового окна"


И где учат этому бреду ?

elipse ★★★
()
Ответ на: комментарий от Led

>>Какая разница, кто правильно написал макроинструкцию? >Это не макроинструкция.

Вы сами доказали, что это макроинструкция с помощью objdump.

>>И от того, что будет она выполняться 3 такта что изменится? >Ну, при 3-х тактах сложнее сказать, что на sparc'ах будет "в 5-6 раз быстрее":)

Я вам несколько раз говорил:"Прежде чем комментировать, читайте контекст". Оценка 5-6 раз относилась к отношению времени обращения в кэш ко времени обращения к регистру. В вашем примере нет обращения к кэш.

По остальному больше не комментирую - у вас какой-то свой странный разговор - люблю одно, не люблю другое. Любить можно женщину. А архитектуру нужно знать. Или не знать.

Вообше говоря, не существует "превосходства" одной архитектуры над другой. Чаще говорят, что на определённом классе задач одна архитектура производительнее (или эффективнее) другой. При этом определяют метрику производительности. Регистровые окна предназначены для эффективной смены контекста. Какое отношение ваше постоянное цитирование окон имеет к вашему текущему разговору? Давно уже никакого. Такой вид дискуссии называется демагогия.

VIT
()
Ответ на: комментарий от Led

> А почему через pushad/popad не попробовали "обход нехватки регистров"?:)

а чем это конкретно лучше push & pop ?

elipse ★★★
()
Ответ на: комментарий от VIT

>Вы сами доказали, что это макроинструкция с помощью objdump.

Это НЕ макроинструкция. objdump выводит в нотации AT&T, а не Intel.

Led ★★★☆☆
()
Ответ на: комментарий от Led

> Это НЕ макроинструкция.

Самому не смешно. У нас разговор постоянно переходит в плоскость "дурак - сам дурак". Если Вас столько раз ловили на неточности и вновь говорят, что что-то не так, так вы, как разумный человек, ну хоть бы взяли и проверили.

Вот Вам ссылка для изучения. Вообще советую внимательно этот документ почитать, а не только страницу 624 (3-576):

http://www.intel.com/Assets/PDF/manual/253666.pdf

где прямо говорится

"Different assemblers may use different algorithms based on the size attribute and symbolic reference of the source operand."

Вообще, если бы я сидел на LOR столько, сколько Вы, я бы пожалуй тоже нихрена ТОЛКОМ не знал. "Меньше сидите в Интернете, читайте больше книг!"

Засим, откланиваюсь. Огромное спасибо всем за приятную беседу!

VIT
()
Ответ на: комментарий от VIT

> Вы сами доказали, что это макроинструкция с помощью objdump.

Тебе уже НЕСКОЛЬКО раз показали, что это не макроинструкция.

Перестань пожалуста бредить, а то получится, что не с кем вообще будет поговорить об архитектуре спарков (что будет грустно).

elispe я уже не беру в расчет, после того, как он обосрался (или обманул) в три раза с SPECint2006/$ на UltraSPARC T2 Plus, и вместо признания своих ошибок (или хотя бы молчания) долго нес маркетоидный бред.

____________________________________________

У тебя есть идеи насчет способа замера время_доступа_к_закэшированной_памяти / время_доступа_к_регистру на тестовой программе на х86?

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от Led

Led,

мне бы хотелось померять время_доступа_к_закэшированной_памяти / время_доступа_к_регистру на тестовой программе на х86. Думаю, там будет не 5-6/1, и не 1/1.

И еще вариант с popad. И может еще один вариант, который предложите.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

>И еще вариант с popad.

Этот вариант имеет смысл только для 32-битного режима. В 64-битном PUSHA*/POPA* упразднены. Хоть и короче инструкция полочается (в байтах), но не даёт "гибкости", да и время выполнения незначительно меньше, чем несколько последовательных PUSH и POP в коде, которые всё равно выполняются параллельно.

Led ★★★☆☆
()
Ответ на: комментарий от Led

> Я привёл абсолютно корректную инструкцию
ага , вот это ?
4. lea a,[a+b+$5]

коректные инструкции для x86 выглядят хотя бы так:

lea a,5[a+b]
в квдратных скобках содержатся ТОЛЬКО индексные регистры
и их не более чем ПАРА для любых режимов.

см.
Intel Architecture Software Developer’s Manual Volume 2:
Instruction Set Reference
2.5. DISPLACEMENT AND IMMEDIATE BYTES




elipse ★★★
()
Ответ на: комментарий от www_linux_org_ru

> elispe я уже не беру в расчет, после того,

я вам буду очень признателен за это :))

> как он обосрался (или обманул)


Ну ,тут полагается по законам жанра "дать в морду вам канделябром" или как-то там обозвать - но, мне вы безразличны ... ходите таким как есть. Добро пожаловать в игнор.

elipse ★★★
()
Ответ на: комментарий от elipse

>lea a,5[a+b]

> в квдратных скобках содержатся ТОЛЬКО индексные регистры

> и их не более чем ПАРА для любых режимов.

Мне искренне жаль вас :(

Led ★★★☆☆
()
Ответ на: комментарий от Led

>Мне искренне жаль вас :(

И мне вас тоже :)) Придется и это пережить ...

elipse ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.