cresta
Ну хорошо, тогда конкретно так:
1) Eсть y=(2^32-1)*sin(x), и a=(2^32-1)*cos(b).Как правильно сравнить y и a ?

Для полноты картины неплохо было бы их округлить :)

Допустим, мы так и сделали.
Так как и sin и cos дают нам значения в интервале [-1;+1],
следовательно, и y, и a могут принимать как положительные, так и отрицательные значения.
Следовательно, они должны быть знаковыми.
Однако в этом случае получится, что числа меняются в интервале -2³²-1..+2³²-1, то есть им требуется 33 бита.
Вывод: если можно изменить формулу, меняем её (делаем 2³¹-1).
Если нельзя - используем 64-битные операции.
Если таковые отсутствуют, реализуем их программно.

letopisec

То, что ты вычитал - не показатель. Посмотри на то что показывает отладчик:

    0040120D  |. B8 FFFFFFFF    MOV EAX,-1   ;mov eax,4294967295 
    00401212  |. B8 FFFFFFFF    MOV EAX,-1   ;mov eax,-1

„и кста, FFFFFFFF - это тоже число“
Ясно дело, число. Его десятичный аналог 4294967295. А то, что мы видим в отладчике - это не число. Это то, как некоторое число себе представляет процессор. Имея строку B8 FFFFFFFF, нельзя однозначно ответить на вопрос: что создало эту строку: mov eax,4294967295 или mov eax,-1.

Зри в корень cresta.

Для восьмиразрядного знакового числа -1 представление в дополнительном коде FF, для 16 разрядного -1 это FFFF, а для 33 разрядного 1FFFFFFFF. А то что мы видим в отладчике cresta, это именно число не надо ля-ля.

letopisec

А ты возьми обычный настольный калькулятор, а ещё лучше лист бумаги и ручку, да умножь цифру 2 саму на себя 32 раза и посмотри, какое-же число получится?

Да, и ещё: подумай, какая разница между 33-мя разрядами и 33-мя битами. И когда поймешь, то будет тебе счастие.

Мужики, вам не надоело переливать из пустого в порожнее ?

Вопрос то элементарный: о диапазоне однозначного представления чисел при ограниченном числе двоичных разрядов. Если мы работаем с 32-разрядными числами, то для гарантии правильного результата мы должны быть уверены в том, что в итоге арифметических операций мы не выйдем за диапазон:
1) 0..4294967295 если все числа заведомо положительные или
2) -2147483648..+2147483647 если числа могут быть и положительными и отрицательными.
Причем здесь имеются в виду не только исходные числа, но и результаты операций: если мы используем вычитание положительных чисел, то результат может быть отрицательным.
Иначе возможно переполнение и => неверный результат. Например:

mov eax,4294967295
inc eax

получим eax = 0 , а не 4294967296 как на калькуляторе.
Не уверен - используй вещественные числа, int64 (EDX:EAX или MMX), или Int128 (XMM). Иначе жди "сюрпризов", которые вы тут столько времени мусолите.

cresta > „какая разница между 33-мя разрядами и 33-мя битами“

Да, а какая между ними разница? Если число двоичное, то один бит - это один разряд.
Если шестнадцатеричное - то один разряд - 4 бита.
Но это в нашем "высокоуровневом" понимании происходит такое разделение.
Для ALU все числа одинаковы, он работает с 33 разрядными двоичными числами (DWORD + CF).
Десятичные же числа - это вообще чисто человеческая выдумка.
Процессор не знает команды printf !

S_T_A_S
>„Для ALU все числа одинаковы, он работает с 33 разрядными двоичными числами (DWORD + CF).
Десятичные же числа - это вообще чисто человеческая выдумка.“

Ты слишком категоричен. ALU поддерживает обработку binary-coded decimal integers (BCD), упаковнных и неупакованных. Для неупакованных: один байт = одной десятичной цифре, для упакованных = двум десятичным цифрам. Вот только вопрос кто сейчас этим пользуется.

Дык пусть поддерживает. Всё равно это реализовано на базе одной схемы.
Добавили цепи в сумматоре для учёта чисел больше 1010b и усё.