FADD

[Debugger]

Изучаю использование команд математического сопроцессора.
FADD - складывает указанные числа и записывает их на место первого операнда. Если операнд один, то складывает с верхушкой стека
Во-первых: где собственно "находится" этот стек? Он "располагается" в самом сопроцессоре и прямого доступа к нему нет?
Во-вторых: на некоторых сайтах написаны странные вещи: напротив FADD стоит "целочисленное сложение". Это - зараза, распространяющаяся копипастой?
И самый главный вопрос: почему когда мы указываем два операнда, второй остается в стеке? Его надо вручную вытаскивать?

P.S. В какой форум подобные вопросы лучше запихивать?
Added:
На последний вопрос таки нашел ответ - надо использовать FADDP

[Хакер]

где собственно "находится" этот стек? Он "располагается" в самом сопроцессоре и прямого доступа к нему нет?

Собственно в в самом процессоре, в виде 8 особых регистров ST(0)...ST(7).

и прямого доступа к нему нет?

Смотря что считается под прямым. Можно сделать GetThreadContext и получить в числе прощего содержимое всех ST-регистров. Но это в случае с чужим потоком, потому что получать свой же контекст как-то глупо. А для своего потока можно воспользоваться инструкцией FXSAVE, которая сохранить в памяти (где укажешь) содержимое всех регистров FP-математики, включая ST-шки.

Это - зараза, распространяющаяся копипастой?

Копипастой и просто глупостью и невнимательностью. Поэтому нужно читать не такие сайты, а трёхтомник от Intel.

И самый главный вопрос: почему когда мы указываем два операнда, второй остается в стеке?

Потому что все инструкции FP используют семантику выполнения на стековой машине.

[Debugger]

Спасибо!

Смотря что считается под прямым.

С обычным стеком можно делать разные хитрые штуки, изменяя регистр SP или данные, которые там лежат. С FPU-стеком такого не пройдет.
З.Ы. "стеком" иногда называют участок памяти, где лежат переменные программы (со слов препода). Почему от этого никого не коробит?

[Хакер]

С обычным стеком можно делать разные хитрые штуки, изменяя регистр SP или данные, которые там лежат.

Зато под вычислительную машину с чисто-стековой моделью работы настоящая сказка писать компилятор кода: просто переводим выражения в обратную польскую нотация и записываем в соответствие операндам — пуш-инструкции, а операторам — прочие инструкции. Пример от tyomitch-а.

З.Ы. "стеком" иногда называют участок памяти, где лежат переменные программы (со слов препода).

Я бы сказал, что участок памяти, где лежат локальные переменные процедур выполняющегося потока, вне зависимости от мнения препода и называющего, является стеком потока. То, что участок памяти, являющийся стеком потока, иногда называют стеком — это в принципе допустимое утвереждение, ничего неправильного здесь нет.

Но вообще стеком называют всё что угодно, что допускает по отношению к себе работу со принципу LIFO. Это ведь может быть и какой-то самостоятельный объект-стек, лежащий в локальной переменной, принадлежащей стеку потока. Или может быть стек стеков. Или стек стеков стеков. Или стек указателей на стек указателей на стеки. Или ещё как-нибудь.

В ядерной архитектуре Windows есть граф устройств, являющийся по своей сути древовидным, то есть деревом. А путь в графе от корневого узла (соответствующего обычно виртуальному устройству «Корневому перечислителю») до конечно узла (какого нибудь устройства), то есть то, что обычно называются ветвью (Branch), там называется не ветвью, а... тоже стеком. Что отражено в названии многих функций, например IoAttachDeviceToDeviceStack, которая добавляет к конечному узлу дерева новый подузел. А всё потому, что с деревом устройств как с деревом практически никто никогда не работает. Работают с ветвью устройств (которую называют стеком устройств), прокачивая приходящие IRP (нечто вроде оконного сообщения) от верхушки стека к корню. А всё потому, что модель восприятия такая: новые ложатся сверху на положенные ранее.

Ну и со стеком протоколов та же история — вопрос восприятия.