Index
> Main > Some questions: [edi+ecx*3] | PUSH | RAM limit | IDT PITGoto page Previous 1, 2, 3, 4 Next |
| Author |
|
|
edfed 07 Mar 2011, 13:00
it is not absolute, but linear!!!
then linear = segment*16+offset segment = linear/16 and 0ffffh offset = linear -( segment*16) as i can see, you are planing on RM segments referencing in GDT, then, it is not hard.* just set bit G to 0 (granularity = 1 byte) limit=0ffffh base = segment*16 and you have the replicate of RM segment in PM. it would be good for you to read some sources, like the one from dexos that supports this feature. and read some sources about Unreal mode. |
|||
07 Mar 2011, 13:00 |
|
|
Teehee 07 Mar 2011, 13:10
> it is not absolute, but linear!!!
yeah sorry, thats what i meant 
> as i can see, you are planing on RM segments referencing in GDT, then, it is not hard.* > and you have the replicate of RM segment in PM. sorry but i didnt understand. what do you mean? |
|||
|
07 Mar 2011, 13:10 |
|
|
Teehee 07 Mar 2011, 16:43
will this work (ok it works, but i wanna know if its right):
Code: ; before here i do the boot, etc.,etc., enter in PM, then jmp here: use32 align 4 pmode: mov eax,0x10 mov ds,ax mov es,ax mov fs,ax mov gs,ax mov ss,ax mov esp,kernel32_stack_addr ; Then i move the kernel to a new address mov esi,kernel32 mov edi,kernel32_addr ; kernel32_addr = 0x0010'0000 (after the RM's 1Mb) mov ecx,kernel32_size rep movsd jmp kernel32_addr ; Then go to execute kernel! kernel32: ; copying from here ahead... to kernel32_addr hlt jmp $ |
|||
|
07 Mar 2011, 16:43 |
|
|
Madis731 07 Mar 2011, 16:54
if you show us how you define kernel32_addr.
a) if kernel32_addr dd 100000h then your code is wrong b) if org 100000h \ kernel32_addr: or label kernel32_addr at 100000h then your code might be correct. Something to think about: My thinking is that you don't need to move your kernel around. If you load your kernel from a disk then you can already load it at the correct address. And when you have your bootloader and kernel tied together and you manage to load them at some address, you don't need to move anything because it already fits nicely at that address. If your only concern is that the starting address of your kernel should look good, then go ahead  |
|||
|
07 Mar 2011, 16:54 |
|
|
Teehee 07 Mar 2011, 17:22
here:
Code: kernel_addr = 0x0010'0000 ; The 1Mb right after RM ( the address the kernel starts ) Quote: Something to think about: My thinking is that you don't need to move your kernel around. If you load your kernel from a disk then you can already load it at the correct address. And when you have your bootloader and kernel tied together and you manage to load them at some address, you don't need to move anything because it already fits nicely at that address. But lets suppose my OS get bigger, lets say, 3Mb. There is no space to load it under RM address. So to avoid headaches ahead i just wanna copy it above RM addr, then i can use that RM space to do the routine to copy it out there. What do you think?  _________________ Sorry if bad english. |
|||
|
07 Mar 2011, 17:22 |
|
|
edfed 08 Mar 2011, 09:53
loading the kernel above 1MB is not a bad idea, because it lets the real mode bios interface as is, and then, lets you return to rm without problem.
|
|||
|
08 Mar 2011, 09:53 |
|
|
Teehee 08 Mar 2011, 13:22
however, if i load to another place, my variables (db,dd,..) won't lost their references?
|
|||
|
08 Mar 2011, 13:22 |
|
|
Teehee 09 Mar 2011, 11:36
Code:
x = 11111111b 1001b 0100b
not x = 00000000b 0110b 1011b
; ...
x = 11111111b 1001b 0100b
neg x = 01111111b 0001b 1100b
is that right? _________________ Sorry if bad english. |
|||
|
09 Mar 2011, 11:36 |
|
|
b1528932 09 Mar 2011, 12:48
not just reverse bits. 0 became 1, and 1 became 0.
its equivalent to xor by -1. neg will subtract the value trom 0. so neg ax is equivalent to: not ax inc ax inc is because when reverse bits (by not) you end up either with too low value or too large value. Its because you subtract from 0 wich is a part of positive half of variable. |
|||
|
09 Mar 2011, 12:48 |
|
|
Teehee 09 Mar 2011, 13:32
so:
Code: neg 1111b = 0 - 1111b + 1 = 0001b ? neg 0100b = 0 - 0100b + 1 = 1100b ? that means negative numbers become positive and positive, negative? |
|||
|
09 Mar 2011, 13:32 |
|
|
b1528932 09 Mar 2011, 15:13
yes.
|
|||
|
09 Mar 2011, 15:13 |
|
|
Teehee 09 Mar 2011, 16:25
but 0 - 0001b = 1110 + 1 = 1111b this is not -1, but -7.
|
|||
|
09 Mar 2011, 16:25 |
|
|
edfed 09 Mar 2011, 16:30
no way.
you should consider the MSb as the sign bit, but not as a minus sign, just as an offset. instead of being equal to 2^n, it is equal to -(2^n) that's why it is a bit sign; then, in you example, the MSb is equal to -8 -8 + 7 = -1. it is no more complicated as that. |
|||
|
09 Mar 2011, 16:30 |
|
|
Teehee 09 Mar 2011, 17:19
i think i got it. You mean 1111b is not -7 but -1 (back to forward):
1110 = -2 (-8+6 = -2) 1101 = -3 (-8+5 = -3) 1100 = -4 (-8+4 = -4) and so on.. but only if SF is set, right? |
|||
|
09 Mar 2011, 17:19 |
|
|
edfed 09 Mar 2011, 20:15
not only if SF is set, just because MSbit is equal to -(2^n)
|
|||
|
09 Mar 2011, 20:15 |
|
|
Teehee 11 Mar 2011, 15:12
question: how do you call the fact processor can process 32/64bit in a single step?
also: lets suppose this code has 4 bytes: Code: inc eax inc ecx inc ebx it means that in a 32 bit CPU it will execute these 3 instructions in single step(clock?)? |
|||
|
11 Mar 2011, 15:12 |
|
|
edfed 11 Mar 2011, 15:56
basically, it is paralelism, using pipelines.
|
|||
|
11 Mar 2011, 15:56 |
|
|
Teehee 11 Mar 2011, 23:46
thanks.
please refresh my mind, a value is stored into memory backward (big endian), and into a register the value stay the same (lil endian), right? Code: mov eax,0x00FF4411 ; eax = 0x00FF4411 mov [mem],0x00FF4411 ; [mem] = 0x1144FF00 db 0, 1 ; mem = 00, 01 dw 0x1122 ; mem = 22, 11 |
|||
|
11 Mar 2011, 23:46 |
|
|
edfed 12 Mar 2011, 00:25
in fact, the values are not stored backward, only the way we (human) read it is a source of confusion. but in fact, the first byte should be the least significant.
the little endian is the more logical way to store bytes (more logical than big endian) because, the lower adress is the least significant byte. |
|||
|
12 Mar 2011, 00:25 |
|
| Goto page Previous 1, 2, 3, 4 Next < Last Thread | Next Thread > |
Forum Rules:
|