Как устроены StrToFloat и StrToInt?

Y_Mur

Нет, ты не прав, т.к. дело не в порядке числа, а в точности представления мантиссы. Возьми виндовый калькулятор, набери целое число "1"+17нулей и посмотри как это выглядит в двоичном виде (Bin) - всего будет 40 значащих бит (от младшей единицы до старшей), т.е. в формате single (dword) это число нельзя записать точно, а в double (qword) в самый раз

Эт-точно Похоже Adrax как раз и путает целые с вещественными. Дело в том, что объявления dd и dq используются как для целых, так и для вещественных чисел, хотя двичный формат у них совершенно разный (только 0 представляется одинаково). Фасм определяет целое или вещ.число по наличию десятич.точки или экспоненты. Пример
i100 dd 100 ;=целое, нужно использовать fild dword [i100]
f100 dd 100.0 ;=вещ., нужно использовать fld dword [f100]
f1E2 dd 1E2 ;=вещ., нужно использовать fld dword [f1E2]

Все процы от P6 и выше могут загружать\сохранять за раз до 64 бит, поэтому разницы по скорости между dword и qword нет, а 80-бит tbyte и 128-бит XMM грузятся\сохраняются за два приема. Это относится к сл., когда данные находятся в кэше, а с точки зрения работы с длинными массивами, подгружаемыми из памяти, ес-но чем короче, тем в целом быстрее (в 64-битной линейке умещается 16 dword, а qword только 8, а массивы tbyte и вовсе неминуемо пересекают границы кэш-линеек, что приводит к доп.тормозам)

 

leo
Однако даже и мысли не возникло, что для такого "простого" числа как 1.0eX может не хватить 24 бит мантисы )). Впредь буду осторожнее экономить на константах
А то что округление в действительное в отличии от округления в целое не тормозит эт. хорошая новость

 

Тогда ты должен еще больше удивиться, что такие "простые" числа как 9^17 и 11^16, будучи < 10^17, даже в 53 бита мантиссы double не влезают. А все потому, что степени X^n четных чисел имеют (как минимум) n незначащих нулей в младших разрядах, а нечетные ес-но нет и соотв-но требуют больше разрядов мантиссы. Поэтому макс. диапазон точного представления целых нечетных чисел = 2^m-1, где m - число бит мантиссы, т.е. для 53-бит double это будет "всего" ~9.0E15, т.е. 15-16 десятичных знаков (как собс-но и пишут во всех хэлпах и манах

Округление округлению рознь. Если речь идет об fst\fist mem, то тут округлением занимается спец.блок (fp_mov или fstore) и округление до single\double производится быстрее, чем до целого, т.к. у single\double формат фиксирован и число сохраняемых бит заранее известно, а у целых приходится брать порядок, смещать его и сдвигать мантиссу в соотв. с порядком. А вот frndint на всех процах выполняется дольше чем fist, видимо потому, что просто Intel и AMD считают, что городить спец блок ради одной "частной\несчастной" frndint не стоит и выполняют ее на универсальном блоке fp_misc за множество микроопераций (от 5 до 30 в завис-ти от проца и мнения А.Фога

 

leo
Гранд мерси за подробные разьяснения

Adrax
Может всё таки приспособишь готовые решения

 

2 leo
Огромное спасибо! Понимаю, что замучал, но хочу понять...

2 Y_Mur
Maybe... Вот только щас учёба началась - на кодинг времени в обрез, потому просто не успеваю ни своё написать, ни чужое заюзать...

 

ээээ... в общем, выдалась минутка, сел за FASM, захреначил чего-то и выпал...
Люди! как правильно разбирать BCD? как там байты идут? так как в книжках или перевёрнуто?

 

Adrax
В BCD по два символа на байт, порядок пока они в регистре - правильный, а когда кинешь в память то младший байт (пара символов) идут в начале но в правильном порядке относительно друг друга И не забывай делать + "0"
BCD 12345678 (десятичное число !)
в регистре: 12345678h
в памяти: 78563412h
ASCI: 31h, 32h, 33h, .. и т.д

 

Угу... Т.е. знаковый байт будет идти десятым по счёту?
Блииин! Разобрался!! Всё, дописываю код, осталось только ликвидировать места потенциальных переполнений - и всё...
Всё... http://rfteam.fatal.ru/ - там я вывесил то, что получилось...