Кто знает - вот это вот:
https://plus.google.com/+AlanCoxLinux/posts/a2jAP7Pz1gj
это единственный блог проекта? А то чего-то там никаких движений не происходит. Где отчеты автора? Хочется почитать.
Кто знает - вот это вот:
https://plus.google.com/+AlanCoxLinux/posts/a2jAP7Pz1gj
это единственный блог проекта? А то чего-то там никаких движений не происходит. Где отчеты автора? Хочется почитать.
Проверка, не испортилась ли память (например, если писали по нулевому указателю). Если там всё равно ПЗУ, её можно закомментировать.Цитата:
Сообщение от SfS
Вообще-то у init-а PID должен равняться 1, в doexit даже проверка есть, если завершился процесс с номером 1, то ядро паникует.Цитата:
Сообщение от SfS
Про то, что это "не горит" - согласен. Но раз ты об этом думал, значит у нас мысли идут в похожем направлении.Цитата:
Сообщение от Eltaron
Честно говоря, не вижу проблем запилить в либы свои несколько функций работы с 64-битной арифметикой. Больше разговоров, ИМХО.Цитата:
Сообщение от Eltaron
Ну я твой код не правил шибко. Пока больше читаю, чем пишу :)Цитата:
Сообщение от Eltaron
А почему?)
Да просто лишнее это. На дефайнах заменить нафиг на 32-разрядный. Т.к. 64-разрядный вариант работать будет медленее, а у нас не Т80 на сотне мегагерц. В Юзикс всего одна (одна!) функция где используется 32-разрядный параметр, во всех остальных местах все 16-разрядное. А тут какие-то 64-разрядные излишества.Цитата:
Сообщение от SfS
если сделать вот так:Цитата:
Сообщение от Error404
то проигрыш с переходом на 64 бит переменную - минимальный (если вообще есть )Код:inc_64_value:
;hl - указатель на 8-байтовую переменную
dup 7
inc (hl)
ret nz
inc hl
edup
inc (hl)
ret
надо использовать adc (учитывать перенос), а не inc, чтобы был не инкремент 8 байтов, а 8-байтного числа. Или я что-то не догоняю.Цитата:
Сообщение от shurik-ua
Кроме того, инкремент - это частный случай (и то вдвое больший по коду и вдвое меньший по скорости аналогичного 32бит), а когда зайдет речь про арифметику с двумя операндами, да передачу всего этого на стеке, да загрузку по индексному регистру - там будет медленно и объемно. Плюс на регистрах это не сделать в принципе (нету у Z80 столько регистров), а только в памяти (как в примере), а для к примеру 16-битной арифметики, при желании все делается на регистрах, да и для 32-битной многое тоже.
---------- Post added at 17:57 ---------- Previous post was at 17:53 ----------
Потому что там в лдире очистки экрана не зря BC был именно 1800 :)Цитата:
Сообщение от SfS
Ты его на единицу уменьшил, а вот DE и HL соответственно увеличить забыл. В итоге у тебя атрибуты начинаются с 57FF.
Я потому 1800 и поставил. Одно лишнее обращение к памяти один раз при инициализации - фигня. А вот два лишних INC - это два занятых байта драгоценного _COMMONMEM.
Короче SD-карта начала читать.! И писать тоже, по идее должна.
Твой образ прочитала. И запустила Hello World. Только вот многозадачный образ почемуто форкаться отказался... Сцука!
Пишет всё время один процесс.
Это ты очень правильно спросил! У меня из-за этой проверки ядро в определенный момент решало, что всё плохо, и слало процессу SIGSEGV. Добавил jp 3 по адресу 0, чтоб проверка проходила - счас форкнутые процессы уже минут 20 крутятся, полёт нормальный!Цитата:
Сообщение от SfS
Блин, не представляю, как ты на реальном железе отлаживаешься :) Я на вышеописанный баг убил весь вечер, и это притом, что у меня-то и отладчик есть, и эмуль лог M1-чтений пишет.
---------- Post added at 03:11 ---------- Previous post was at 03:08 ----------
Если всегда пишет process 2 (это сам инит), то смотри прерывания, если process 1 (форк), то переключение банок.Цитата:
Сообщение от SfS
Off:
make для CPM (нативного - для Z80 и 60к ОЗУ) есть у кого-нить? Он в природе для CPM есть вообще?