Page 2 of 3
Posted: Tue Apr 03, 2007 11:54 pm
by Serge
Phantom-84
Может напишешь код для определения размера ОЗУ ?
Posted: Wed Apr 04, 2007 9:45 am
by Phantom-84
Serge, здесь не получится ограничиться простой функцией, возвращающей размер ОЗУ, например, в страницах! Я в стеке собираю описатели блоков памяти (значения base и after, выравненные на границу страницы), лежащих выше 1-мегабайтной границы, при использовании функции 0xE820 и только в том случае, когда данная функция не поддерживается, формирую один такой блок, после чего, уже в защищенном режиме, извлекаю эти описатели из стека и по данным из них строю таблицу свободных страниц. Короче, этот код привязан к порядку инициализации оси.
Posted: Wed Apr 04, 2007 9:50 am
by Phantom-84
Ну в принципе такую функцию можно написать, но по ней будет нельзя гарантированно определить местоположение памяти.
Posted: Wed Apr 04, 2007 10:21 am
by Serge
Phantom-84
А почему нельзя точно опрделить ?
Posted: Wed Apr 04, 2007 10:35 am
by Phantom-84
Serge, потому что память может находиться в нескольких несмежных участках! Можно, конечно, возвращать сведения в виде массива, а в функцию передавать максимально возможное число элементов массива, тогда функция будет записывать сведения о блоках памяти в массив, а возвращать, например, количество реально записанных элементов.
Posted: Wed Apr 04, 2007 11:28 am
by Serge
Phantom-84
Это из-за дыры 15 Мб или бывают ещё варианты ? Если память не раскидана слишком сильно можно настроить битовую карту страниц.
Вариант с массивом вполне подойдёт
Posted: Wed Apr 04, 2007 12:09 pm
by Phantom-84
Это из-за дыры 15 Мб или бывают ещё варианты ?
Реально далеко не всегда есть и эта дыра, но уже давно принято учитывать, что
теоретически память может быть фрагментированна. А что в Колибри это не учитывается?
Posted: Wed Apr 04, 2007 2:31 pm
by Pavia
Phantom-84
Реально далеко не всегда есть и эта дыра, но уже давно принято учитывать, что теоретически память может быть фрагментированна. А что в Колибри это не учитывается?
В Колибри 6.5.0 не учитывается.
Теоретически может, а вот практически. Там около 640КБ - базовой памяти затем дырка БИУС видео память до границе 1МБ. Дальше никаких дырок нет, вплоть до конца в конце памяти откусывается еще несколько 1МБ под нужды БИОСа и под встроенную видео карту еще несколько.
Posted: Wed Apr 04, 2007 2:55 pm
by Phantom-84
Pavia, ты видимо говоришь о конкретном компьютере... Но ведь ось пишется не под один компьютер...
Posted: Wed Apr 04, 2007 3:53 pm
by Pavia
Phantom-84
Нет, не о конкретном. Как всегда обобщил свои знания. Просто если есть дырка, то она должна быть стандартерезирована. В PC-AT и совместимых машинах нет дырок, кроме той что в 1 мегабайте. Иначе бы многие программы бы просто не стали бы работать. И вообще что бы ее сделать нужно точно знать что она будет и физически зарезервировать адреса под нее.
Единственно возможный вариант это когда память разных модулей отображается в разные места, то возникает дырка. Но о таком извращении я не слышал.
Приведи пример, где это не так.
Posted: Wed Apr 04, 2007 6:35 pm
by Serge
Phantom-84
Вообще надо учитывать дыры только выше 1 Мб а точнеее выше 8 Мб. Ниже вся память распределяется статически
Posted: Thu Apr 05, 2007 2:56 am
by N†OSKRNL
хз.. какие дыры... мне вот, этот код последовательно отработал, 256метров RAM (две планки по 128mb), от 0100000h до 0FFFFFFCh
Code: Select all
.model tiny
.code
.386P
org 100h
start:
xor eax, eax
mov ax, cs
shl eax, 4
mov gdtbase,eax
lea edx, GDT
add gdtbase,edx
cli
lgdt fword ptr gdtlimit
; Войти в прот-моде
mov eax, cr0
or al, 1
mov cr0, eax
mov ax, 8
mov es, ax
mov ds, ax
mov eax, cr0
and al, 0FEh
mov cr0, eax
; Превед, мы в унреале
xor ax, ax
mov ds, ax; 4гиговая 0-база
; указатель памяти после rom-bios'a
mov eax, 100000h
mov ecx, -1
@@top:
mov edx, [eax]
mov [eax], eax
cmp eax, [eax]
jne @@holeshit
mov [eax], edx
add eax, 4
loop @@top
call printhex
ret
@@holeshit:
call printhex
ret
;------------------------------
printhex:
mov dh,8
rol eax,4
@@loo: push eax
mov dl,30h
and al,0Fh
or dl,al
cmp dl,39h
jbe @@@
add dl,7
@@@: mov ah,2
int 21h
pop eax
rol eax,4
dec dh
jnz @@loo
mov dl,0Dh
mov ah,2
int 21h
mov dl,0Ah
mov ah,2
int 21h
retn
GDT label near
dq 0;
dq 009F93000000FFFFh; 8-oй
gdtlimit dw 2*8 ; GDT limit
gdtbase dd ? ; GDT base
ends
end start
никаких дыр... а битой оперативы у мну нету..
Posted: Thu Apr 05, 2007 11:40 am
by Phantom-84
Pavia, так уже говорили, что дыра может быть между 15-м и 16-м мегом, древние видюхи выше 12-го мега могли вставлять видеобуфер, на некоторых ноутбуках несколько ячеек выше первого мега могут некорректно работать - функция 0xE820 обрежет этот участок, между 3-м и 4-м гигом может вклиниваться множество различных устройств, поэтому в карте памяти на этом участке вполне может присутствовать большое количество дыр. Короче все нормальные оси должны это учитывать! Я, например, в своей оси считаю гарантированно непрерывным и доступным для использования только участок базовой памяти после BDA и вплоть до EBDA! Все остальные непрерывные участки я собираю исключительно посредством пейджинга!
Posted: Thu Apr 05, 2007 11:56 am
by Phantom-84
Вообще надо учитывать дыры только выше 1 Мб а точнеее выше 8 Мб. Ниже вся память распределяется статически
А я размер базовой памяти определяю вообще через int 12h, а при детекте дополнительной памяти все, что лежит ниже 1-мегабайтной границы, просто отбрасываю! Допускаю, что можно начинать детект с 8-мегабайтной границы (хотя я читал, что встречаются ноутбуки, в которых ячейки в самом начале второго мега могут сохранять информацию с ошибками), но ведь были же когда-то системы, вообще не имеющие дополнительной памяти или имеющие, например, всего 4 Мб, поэтому я выполняю детект доступной памяти, начиная с 1-го мега.
Posted: Thu Apr 05, 2007 12:47 pm
by Serge
Phantom-84
Начиная с 1 мега вполне пойдёт. Если это будет массив доступный блоков <база, размер> то можно будет его конвертировать в битовую карту для менеджера стираниц.
P.S.
Что это за твоя ось ? Посмотреть можно ?