weird 64 bit mode ......

[Manktown]

About the 000 thing... 48 = '0' ASCII.

[nikito]

Yep!

If you wont to print some legible to the videoram, it must be in ASCII.
My hypervisor don't offer debugging, so the only way to me to debug is to print to the videoram. For example if 2+2 print 5 something go wrong. Restart==something wrong too. Bud now I will try to set an decent 64 bit IDT and expect no more restarts.

An hopefully last question about Long mode:
I will use 32bit read/write I/O and memory access to configure PCI in long mode, but if my PCI devices is not 64 bit capable, can they write to the bus and memory in long mode?

[Owen]

Devices don't care or know about the processor operating mode (indeed, no reason you can't have a CPU running in real mode and another in long mode - in fact you will have when you're starting the APs up.)

However, they won't be able to access physical memory above 4GB (as you would expect)

[nikito]

Thanks, Owen!

I am surprised how difficult it is to do something in long mode. I don't know if another guy of this forum experimented all those issues.
Right now "My brain hurts"

The new serious problem that I encountered is that don't know how to do maths with 64 bit integers.

I have added and subtracted various values and no one coincidence with the Windows-program mode calculator(Tested Linux calculator too).

As example:

mov RAX, 60000000
mov RBX, 50000
add RAX, RBX
gives in RAX an 1200400 value just for example.

Rewriting the chunk of code for the SSE-s gives the some result exactly the same values and exactly the wrong values on 64 bit integers.

How can I do calculations with 64 bit integers?

Thanks, and sorry for my weird(novice) questions.


PD: Here an real output:

0000.0000.0000.0000 + 0FFF.9000.0000.0000 = 0FFF.9000.0000.0000 /OK
0FFF.9000.0000.0000 + 0F40.0000.0000.0000 = 000F.A000.0000.0000 /?
000F.E000.0000.0000 + 000F.2000.0000.0000 = 0000.F100.0000.0000 /?
0000.F100.0000.0000 + 5FFF.F000.0000.0000 = 000F.FFF5.0000.0000 /?! etc.....

Even reading from memory seems wrong. I have the e820 structure at 500h, reading from this address in protected mode give me the correct result, then from long mode gives me the above, it is totally incorrect. I am sure I have not wrote nothing over it, But even if did(but did not), the maths are wrong.

[gerryg400]

Code: Select all

PD: Here an real output:

0000.0000.0000.0000 + 0FFF.9000.0000.0000 = 0FFF.9000.0000.0000 /OK
0FFF.9000.0000.0000 + 0F40.0000.0000.0000 = 000F.A000.0000.0000 /?
000F.E000.0000.0000 + 000F.2000.0000.0000 = 0000.F100.0000.0000 /?
0000.F100.0000.0000 + 5FFF.F000.0000.0000 = 000F.FFF5.0000.0000 /?! etc.....

Please attach the code that does this.

[nikito]

This code in protected mode:

Code: Select all

mov EAX, 0B8000h
mov CL, [DS:0]                                      ;Here is the number of entries in the e820 structure
mov EDX, 500h                                     ;At [DS:500h] is placed the e820 structure itself
mov EDI, 0
print_1:
    print_2:
         mov BL, [DS:EDX]
         and BL, 0Fh
         call print_hex
         add EAX, 2
         mov BL, [DS:EDX]                       ;again
         shr BL, 4
         call print_hex
         add EAX, 2
         inc EDX
         inc EDI
         cmp EDI, 24
   jne print_2
   mov EDI, 0
   add EAX, 40h
   dec CL
   cmp CL, 0
jne print_1

jmp next

print_hex:
l0:
    cmp BL, 0
    jne l1
    mov byte [DS:EAX], "0"
    ret
l1:
    cmp BL, 1
    jne l2
;.............

...Prints :

0000.0000.0000.0000 00CF.9000.0000.0000
00CF.9000.0000.0000 0040.0000.0000.0000
0000.E000.0000.0000 0000.2000.0000.0000 etc.. Its correct

Here actually onlñy thing I do is print the e820

pass some code more still in protected mode:

Code: Select all

;......
mov dword [DS:9], 0                                ;Here will be the constant for the ram available
mov dword [DS:9], 0
mov EAX, 500h
mov CL, [DS,0]
search_amount_of_ram:
     movdqu XMM0, [DS:EAX]
     add EAX, 8
     movdqu XMM1, [DS:EAX]
     sub EAX, 8
     paddq XMM0, XMM1
     movq XMM2, XMM0
     movdqu XMM3, [DS:9]
     psubq XMM0, XMM3
     movdqu [DS:SSE_temp], XMM0
     mov EDX, [DS:SSE_temp+4]
     bt EDX, 31
     jb another_loop
         movdqu [DS:9], XMM2
     another_loop:
     add EAX, 24
     dec CL
     cmp CL, 0
jne  search_amount_of_ram

This calculates the highest ram to be addressed, but the value is the incorrect value of 0000000F10000000, just as latter in long mode.

Next in long mode:

Code: Select all

;.........
mov EAX, 0B8000h
mov BL, [0]
mov EDX, 500h
print:
    mov RCX, [EDX]
    mov R8, RCX                          ;Save RCX, because the print function destroys the RCX
    ;print RCX
    add EAX, 0Ah                         ;Print stuff
    add EDX, 8
    mov RCX, [EDX]
    mov R9, RCX
    ;print RCX
    add EAX, 0Ah
    add R8, R9
    mov RCX, R8
    ;print RCX
    add EAX, 20h+18                   ;new line
    add EDX, 16                            ;new entry
    dec BL
   cmp BL, 0
jne print

Produces the weird output from above posting. And if I calculate the highest ram is again 0000000F10000000 just like the SSE stuff

The line of the wrong output corresponding to the wrong highest value is:

000F.FFFF.0000.0000 + 000F.4000.0000.0000 = 0000.000F.1000.0000

[nikito]

Finally, long mode is not weird :

0000.0000.0000.0000 + 00CF.9000.0000.0000 = 00CF.9000.0000.0000 /ok
00CF.9000.0000.0000 + 0040.0000.0000.0000 = 0000.A000.0000.0000 /ok
0000.E000.0000.0000 + 0000.2000.0000.0000 = 0000.0100.0000.0000 /ok
0000.0100.0000.0000 + 0000.FEF5.0000.0000 = 0000.FFF5.0000.0000 /ok
0000.FFF5.0000.0000 + 000F.0000.0000.0000 = 000F.FFF5.0000.0000 /ok
000F.FFF5.0000.0000 + 0001.0000.0000.0000 = 0000.0006.0000.0000 /ok
0000.CFFF.0000.0000 + 0000.4000.0000.0000 = 0000.0000.1000.0000 /ok

And the output is the expected.

The problem?(I guess the experienced guys in the forum already know it)......... Myself

The print routine print only the low 4 bits of an Byte, if there an value greater than Fh, the routine print Fh.

Sorry, I guess there will be an week without posting nothing, because I am little shamed

Bye!

Niki