Привет. Помогите разобраться, а то написал уже кучу 64-битного кода на NASM, стал просматривать листинги и заметил то, что никак не могу понять. В доках от Intel и AMD указывается что адресация в Long Mode по умолчанию 64 битная, однако когда компилирую например такой код: Код (Text): mov rax,qword [12345678h] то получаю машинные коды: Код (Text): 48 8B 04 25 78 56 34 12 Вот и вопрос: Почему NASM под адрес отводит всего 4 байта??? а не 8 ??? и соответственно такой код Код (Text): mov rax,qword [1234567890ABCDEFh] совсем не компилируется как надо: warning: dword data exceeds bounds Собственно неужели нельзя напрямую адресовать более 4 Гб памяти?? У меня написан модуль вывода графики в линейный видеобуфер, там я транслирую физические страницы видеопамяти в ЛИНЕЙНОЕ адресное пространство начиная с 1 0000 0000 h и ВСЁ ПРЕКРАСНО РАБОТАЕТ, поскольку вывожу точки примерно таким кодом Код (Text): ... .... .... add rdi,r8 ; прибавим X, т.к. 4 байта на пиксель add rdi,100000000h ; высчитываем линейный адрес первого пикселя, буфер с 1 0000 0000 h mov eax,r12d cld rep stosd т.е. адрес выше 4 Гб у меня в регистре RDI и косвеная адресация работает так как надо. Я бы и не заметил этого если бы не дошёл до момента программирования APIC. Пытаюсь прочесть dword из адреса FEE0 0000h. Само собой заранее установил соответствие страниц физическая=линейная. на реальном компе - сразу сброс процессора на инструкции чтения mov eax, dword [0FEE00000h] в отладчике Bochs на этой инструкции вижу что она интерпретируется как 8B 04 25 0000E0FE ==== mov eax,dword ptr ds:0xFFFFFFFFFEE00000 ОТКУДА ТАКОЙ АДРЕС ???? Помогите, кто в этом хорошо разбирается, пожалуйста, а то мозг кипит
Black_mirror ОГРОМНОЕ СПАСИБО !!! действительно код A1 00 00 E0 FE 00 00 00 00 работает как надо! а то как говоорится "чувствую что-то не так, а понять не могу..." . Не ожидал от NASMa такого подвоха, версию юзаю последнюю 2.08.01. Кстати и Bochs перестал тупить на этой команде. Спасибо. Сейчас курю мануалы по Local и I/O APICам. Теорию от корки до корки прочёл раз 15, а примеров находится оччень-очень мало и то под Protected Mode, вот сейчас в раздумьях какие подводные камни встретятся при программирование APIC не из 32битного а из 64-битного режима.
olegsys >add rdi,100000000h Вот это настораживает. Заглянули в ман – такое не закодировать; К любому reg64 можно добавлять лишь imm32, с пропагацией знака. Pavia >Врет отладчик. Не, там всё верно по идее – происходит знаковое расширение 32х-разрядного смещения при использовании опкода 8B. P.S. fasm 1.69.11: mov eax, [qword 123456789abcdef0h] <-> A1F0DEBC9A78563412
Sol_Ksacap виноват, это я "подправил" для "большей наглядности" при написании поста, на самом деле конечноже у меня так: Код (Text): ... add rdi,qword [data_VBE_linearbuffer] ... data_VBE_linearbuffer dq 100000000h ; адрес линейного видеобуфера Сегодня первый день зарегился на этом форуме и сразу приятно удивлен встретить действительно грамотных людей! Респект !
Зря я NASM обругал, оказывается он может правильно опкод вставлять в документации написано: т.е. пишем mov eax,[qword 0x123456789ABCDEF0] - слово qword внутри скобок а не снаружи и получаем верный код: A1F0DEBC9A78563412
Зря я NASM обругал, оказывается он может правильно опкод вставлять в документации написано: т.е. пишем mov eax,[qword 0x123456789ABCDEF0] - слово qword внутри скобок а не снаружи и получаем верный код: A1F0DEBC9A78563412
