Новая модель ядра

Kernel architecture questions
  • Как по мне, можно даже 2 раза и не кликать, что мешает при первом клике на окне сразу выводить его на передний план и потом запоминать картинку в буфер? Это один из немногих случаев, где реакция должна быть не на отпускание, а именно на нажатие кнопки мыши. Хотя может я и ошибаюсь )

    UPD: проверил в колибри - действительно перемещение неактивного окна возможно только по второму клику - надо править, ибо жутко неудобно. )
  • У меня не только перемещение, но и закрытие/минимизация окна по второму клику.
  • UPD2: Хм, зря бочки накатил на 415, это оказалось побочным эффектом 970 ревизии.
  • Хмм...
    А так не проще будет :?:

    Code: Select all

            cmp [bPressedMouseXY_W],1
            ja  @f
            inc [bPressedMouseXY_W]
            jnc @f
            mov eax,dword[MOUSE_X]
            mov dword[mx],eax
            @@:
  • Может непонятно написал........... :wink:
    ((хотя мне казалось, что если для "посвященных" - совершенно достаточно))
    Речь идет конкретно о kernel\trunk\gui>window.inc#lines=1209-1220
  • О чем речь понятно, я даже вчера сидел и сравнивал с тем, как сделано сейчас - выглядит проще, но есть один момент, который вводит меня в ступор:
    вижу

    Code: Select all

            mov eax,dword[MOUSE_X]
            mov dword[mx],eax
    но не вижу в таком случае еще и

    Code: Select all

            mov eax,dword[MOUSE_Y]
            mov dword[my],eax
    Я чего-то не понимаю и так нужно, или эти строчки все же нужны?
  • Heavyiron

    mx my 16-ти битные переменные. Обе копируются одним dword
  • Добавил в ядро функции для работы с мьютексами. Реализация взята из Linux, ABI gcc fastcall.
    void __attribute__ ((fastcall)) mutex_init(struct mutex*);
    void __attribute__ ((fastcall)) mutex_lock(struct mutex*);
    void __attribute__ ((fastcall)) mutex_unlock(struct mutex*);
    структура MUTEX определена в kernel32.inc.
    Прежде чем использовать мьютекс его обязательно следует инициализировать вызовом mutex_init и только вызовом mutex_init.
    Только один поток может захватывать мьютекс.
    Множественные блокировки не допускаются.
    Нельзя использовать мьютексы в обработчиках прерываний.
  • Ядро сейчас целиком влезает в первую 4Мб-страницу, но в init.inc до сих пор висит код дозагрузки "хвоста" в PSE-режиме:

    Code: Select all

               mov eax, 0x400000+PG_SW
               mov ecx, [tmp_page_tabs]    ;) однако [tmp_page_tabs] < 4M 
               sub ecx, 0x400000            ;) отрицательное
               shr ecx, 12                  ;( а теперь еще и знак потерялся
               jmp .map_low
    .no_PSE:
               mov eax, PG_SW
               mov ecx, [tmp_page_tabs]
               shr ecx, 12
    .map_low:
               mov edi, [tmp_page_tabs]
    @@:                                   ; заносим в таблицу хз сколько ненужных страниц 
               stosd
               add eax, 0x1000
               dec ecx
               jnz @B
    
    насколько я понимаю, этот рудимент остался от более рыхлой модели памяти, когда sys_pgmap лежала за пределами 4Mb:
    diamond wrote:начальный кусок системных адресов [OS_BASE, OS_BASE + a), где OS_BASE = 0x80000000 (const.inc), маппится на начало физической памяти [0,a) "почти тривиально" - вычитанием OS_BASE; в этот кусок входит само ядро и все системные таблицы (точный список в memmap.inc); длина куска a = 0x47F000 + (некоторая память для таблицы страниц, размер которой зависит от размера имеющейся памяти). Если процессор поддерживает страницы по 4 Мб (page-size extensions), то первые 4 Мб маппятся одной страницей...
    попробовал фиксануть #1451 - у меня вроде работает. Следите за глюками
    Евангелие от Иоанна: стих 1

    Code: Select all

    ; В начале было Слово:
    B32:        mov     ax, os_stack       ; Selector for os
    [/size]
  • art_zh

    Да, ядро сильно ужалось. Ветку .no_PSE: можно выкинуть, на таких процессорах Колибри не работает.
  • Я никак не могу разобраться зачем ядру маппинг пустой зоны до HEAP_BASE - ради одного только tss?

    Кстати, tss надо бы тоже внести в "большую" страницу: если верить fast_call_test, системные вызовы через int40 в ядре #1451 стали грузиться в полтора раза дольше. На sysenter/syscall вызовах переделка init.inc никак не сказалась.
    Евангелие от Иоанна: стих 1

    Code: Select all

    ; В начале было Слово:
    B32:        mov     ax, os_stack       ; Selector for os
    [/size]
  • art_zh

    tss нельзя, в крайнем случае в самый хвост большой страницы,
    или пометить страницу как глобальную. За tss идут две copy-on-write страницы с картой ввода вывода.

    В полтора раза дольше по сравнению с чем ? tss при быстрых вызовах не используется. Так что врядли это связано с ним.
  • в полтора раза дольше по сравнению с предыдущей версией.
    tss используется при вызове через int40, и судя по сумасшедшей скорости вызова (почти также быстро как sysenter/sysexit) раньше постоянно сидела в кеше.
    Теперь вызов int40 на моей керосинке занимает 330 тыс тактов вместо 200тыс раньше.
    Время вызовов через sysenter и syscall заметно не изменилось (~200тыс тактов).
  • art_zh

    Странно.
  • Who is online

    Users browsing this forum: No registered users and 9 guests