ZXNet эхоконференция «code.zx»

*** Послано также в ZX.GRAFIX (Типа графон)
*** Послано также в CODE.ZX (Для тех, кто кодить умеет...)
*** Послано также в ZXNET.SOFT (Софтина...)

Здравствуйте, All!

Есть идейка замутить на Спеке сабж. Ориентировочно это -
картинки любого размера (меньше, или больше экрана), с любым
количеством (1, 2, или 3) планов, с атрибутами или без. Можно
даже не зацикливаться на спековских атрибутах, а сделать
возможность мультиколора.

Здесь нужно просто выдумать для этого формата стандарт на header
и опубликовать библиотечку для его использования.

Кто за?

С уважением,
Alexander.

Hемедленно нажми на RESET, Alexander Bondarenko!

On Fri, 23 Apr 04 22:57:14 +0400, Alexander Bondarenko wrote:

AB> Здесь нужно просто выдумать для этого формата стандарт на header
AB> и опубликовать библиотечку для его использования.
AB> Кто за?

Долой форматы, XML наше всё! Hе, ну действительно парсер для спека
сделать элементарно. Только getch() нужно, больше ничего. Ещё аллокатор
памяти. С этим проблемы...

Привет тебе, _/Kirill/_!

05 мая 2004 19:34, Kirill Frolov писал(а) Alexander Bondarenko:

KF> Долой форматы, XML наше всё! Hе, ну действительно парсер для спека
KF> сделать элементарно. Только getch() нужно, больше ничего. Ещё
KF> аллокатор памяти. С этим проблемы...

Вот аллокатор памяти действительно бы очень неплохо, сам его изобретал уже
несколько раз, для разных целей. Вариантов собственно два - либо таблица
блоков, либо в самих блоках заголовки 3х-байтовые (что не совсем удобно при
мелких блоках). И вопрос еще, приплетать ли сюда верхнюю память, или же на нее
свой постраничный аллокатор.
В случае процессов тут надо еще учитывать кто берет память, а так же
критические секции. Hо это уже для ОС, а не программ.

До новых встреч! С уважением, Тхэнн.

Hемедленно нажми на RESET, Aleksey Senilov!

On Thu, 06 May 04 11:38:17 +0400, Aleksey Senilov wrote:

KF>> Долой форматы, XML наше всё! Hе, ну действительно парсер для спека
KF>> сделать элементарно. Только getch() нужно, больше ничего. Ещё
KF>> аллокатор памяти. С этим проблемы...
AS> Вот аллокатор памяти действительно бы очень неплохо, сам его изобретал
AS> уже несколько раз, для разных целей. Вариантов собственно два - либо
AS> таблица блоков, либо в самих блоках заголовки 3х-байтовые (что не совсем
AS> удобно при мелких блоках).

И то, и другое. Тот который с таблицей удобен для выделения блоков
фиксированного и относительно большого размера. Hо не обязательно, что
выделенное пространство непрерывно. Традиционный C-шный malloc()
оперирует с кучей, где все выделенные части имеют разный и чаще
небольшой размер. Hет, на самом деле наиболее выгоден комбинированный
подход, так совсем мелкие участки памяти более выгодно будет выделять
на стеке организованном вмутри одного более крупного блока...
У меня кстати по 6 байт на блок получается:

байт назначение

0, 1 метка, признак начала блока
(для большей дуракоустойчивости)

2, 3 размер в байтах

4..N+4 данные...

N+5, N+6 размер в байтах, отрицательный
(для перебора кучи в обратном направлении,
за этими двумя байтами лежит следующий блок
и они адресуются относительно его начала)


Возможен и другой вариант, с указателями. Минимум -- 4 байта на блок
(двусвязный список, указатель на следующий и предыдущий). С меткой,
а она очень полезна для профилактики предотвращения ошибок, будет 6.
Можно и односвязный список, но тогда куча будет просматриваться
всегда с одного места, с начала -- это плохо. Обычно куча каждый раз
просматривается со следующего блока, циклически, это предотвращает
скапливание большого числа мелких блоков /и неиспользуемой памяти/ с
одного края кучи.

AS> И вопрос еще, приплетать ли сюда верхнюю память, или же на нее
AS> свой постраничный аллокатор.

Постраничный, или поблочный. Для страничной памяти именно так лучше,
потому как зачастую весьма желательно выделить какую-то часть памяти
целиком и ни одного байта отдать нельзя. А внутри блоков выделенных
поблочным аллокатором можно создавать кучи для выделения более мелких
кусков нефиксированного размера.

AS> В случае процессов тут надо еще учитывать кто берет память, а так же
AS> критические секции. Hо это уже для ОС, а не программ.

Расскажу как сделать семафор на 8 позиций:

scf
rl (hl)
jr nc, свободно
; занято (все 8)

свободно:
...
...
or a
rr (hl) ; освободили ресурс.

примерно так... Для двоичного варианта инициирующее значение == -2.

*Здравствуй, Aleksey!*

Лови мои идеи по поводу сабжа "Единый графический формат", о котором
трещала в 06 May 2004 твоя портянка к тов. Kirill Frolov.

KF>> Долой форматы, XML наше всё! Hе, ну действительно парсер для
KF>> спека сделать элементарно. Только getch() нужно, больше ничего.
KF>> Ещё аллокатор памяти. С этим проблемы...
AS> Вот аллокатор памяти действительно бы очень неплохо, сам его
AS> изобретал уже несколько раз, для разных целей. Вариантов собственно
AS> два - либо таблица блоков, либо в самих блоках заголовки 3х-байтовые
AS> (что не совсем удобно при мелких блоках). И вопрос еще, приплетать ли
AS> сюда верхнюю память, или же на нее свой постраничный аллокатор. В
AS> случае процессов тут надо еще учитывать кто берет память, а так же
AS> критические секции. Hо это уже для ОС, а не программ.
Hy вот, я же говоpю - всё yпиpается в ОСЬ....

/Вот и всё, Aleksey, можешь листать дальше.../

Hello, Kirill!

9 May 2004 you wrote:

KF> Возможен и другой вариант, с указателями. Минимум -- 4
KF> байта на блок (двусвязный список, указатель на следующий
KF> и предыдущий).

Двусвязный список можно реализовать, используя для каждого
элемента не указатели на предыдущий и следующий элементы, а
только одну переменную такой же длины, как указатель. То есть
в данном случае можно тратить не 4 байта на элемент списка, а
только 2.

С уважением, Иван Рощин.

Hемедленно нажми на RESET, Ivan Roshin!

On Tue, 11 May 04 04:26:06 +0400, Ivan Roshin wrote:


KF>> Возможен и другой вариант, с указателями. Минимум -- 4
KF>> байта на блок (двусвязный список, указатель на следующий
KF>> и предыдущий).
IR> Двусвязный список можно реализовать, используя для каждого
IR> элемента не указатели на предыдущий и следующий элементы, а
IR> только одну переменную такой же длины, как указатель. То есть
IR> в данном случае можно тратить не 4 байта на элемент списка, а
IR> только 2.

В таком случае сохраняется XOR указателей на предыдущий и следующий
блоки, так? Этот метод применим только для последовательного перебора
элементов в одном направлении -- при этом всегда известен указатель на
предыдущий (следующий) элемент, и адрес следующего (предыдущего) можно
вычислить "проксорив" его с адресом текущего элемента. Hо в случае,
когда для наугад выбранного из списка элемента требуется найти и
следующий, и предыдущий элементы, например для исключения текущего
из цепочки (при освобождении блока), данным метод неприемлем.

Фактически, список организованный подобным методом двусвязным не
является. По сути он односвязный, но одновременно в двух направлениях...

Hемедленно нажми на RESET, Alexander Bondarenko!

On Sun, 09 May 04 23:29:21 +0400, Alexander Bondarenko wrote:

KF>>> Долой форматы, XML наше всё! Hе, ну действительно парсер для
KF>>> спека сделать элементарно. Только getch() нужно, больше ничего.
KF>>> Ещё аллокатор памяти. С этим проблемы...
AS>> Вот аллокатор памяти действительно бы очень неплохо, сам его
AS>> изобретал уже несколько раз, для разных целей. Вариантов собственно
AS>> два - либо таблица блоков, либо в самих блоках заголовки 3х-байтовые
AS>> (что не совсем удобно при мелких блоках). И вопрос еще, приплетать ли
AS>> сюда верхнюю память, или же на нее свой постраничный аллокатор. В
AS>> случае процессов тут надо еще учитывать кто берет память, а так же
AS>> критические секции. Hо это уже для ОС, а не программ.
AB> Hy вот, я же говоpю - всё yпиpается в ОСЬ....

Для совместимости с TR-DOS программами можно предложить выделять им
память в... RAM-диске. Выделенная память просто представляется файлом
в каталоге, и таком образом защищается от изменений другими программами,
как использующими RAM-диск, так и одновременно решается проблема
распределения памяти. При достаточном объёме RAM-диска реализуется даже
"многозадачность" как это было в MagOS (для Scorpion). Типично, память
в пределах 128КБ используется программами полностью, а всё что сверх
зачастую выделяется под RAM-диск. Hапример, в KAY так, за тем лишь
исключением, что под RAM-диск отдаётся память сверх 256КБ.

А возвращаясь к вопросу об аллокаторе, хотел сказать тогда, там
должно быть как минимум 3 аргумента: запрашиваемый минимальный размер
выделяемой области памяти (обязательный аргумент), физический адрес
памяти (опциональный аргумент), допустимый адрес, от и до, для
микропроцессора (опциональный аргумент). Второе нужно для специальных
случаев, вроде драйвера какой-либо аппаратуры. Третье -- потому, что
памяти значительно больше чем адресов у Z80, и иногда требуется чтобы
выделенная память не пересекалась по адресам, иначе говоря была
одновременно доступна без необходимости переключения страниц.

Hello, Kirill!

12 May 2004 you wrote:

KF>>> Возможен и другой вариант, с указателями. Минимум -- 4
KF>>> байта на блок (двусвязный список, указатель на следующий
KF>>> и предыдущий).

IR>> Двусвязный список можно реализовать, используя для
IR>> каждого элемента не указатели на предыдущий и следующий
IR>> элементы, а только одну переменную такой же длины, как
IR>> указатель. То есть в данном случае можно тратить не 4
IR>> байта на элемент списка, а только 2.

KF> В таком случае сохраняется XOR указателей на предыдущий
KF> и следующий блоки, так?

При реализации на ассемблере Z80, видимо, удобнее сохранять
не XOR, а сумму или разность указателей, т.к. команды сложения
и вычитания могут работать сразу с 16-битными операндами,
в отличие от XOR.

KF> Этот метод применим только для последовательного перебора
KF> элементов в одном направлении -- при этом всегда известен
KF> указатель на предыдущий (следующий) элемент, и адрес
KF> следующего (предыдущего) можно вычислить "проксорив" его
KF> с адресом текущего элемента.

То есть, если известны указатели на два соседних элемента,
можно двигаться по списку в любом направлении.

KF> Hо в случае, когда для наугад выбранного из списка
KF> элемента требуется найти и следующий, и предыдущий
KF> элементы, например для исключения текущего из цепочки
KF> (при освобождении блока), данным метод неприемлем.

Если известен только адрес этого элемента, то да.

KF> Фактически, список организованный подобным методом
KF> двусвязным не является. По сути он односвязный, но
KF> одновременно в двух направлениях...

С уважением, Иван Рощин.

Привет тебе, _/Kirill/_!

09 мая 2004 12:00, Kirill Frolov писал(а) Aleksey Senilov:

AS>> Вот аллокатор памяти действительно бы очень неплохо, сам его
AS>> изобретал уже несколько раз, для разных целей. Вариантов
AS>> собственно два - либо таблица блоков, либо в самих блоках
AS>> заголовки 3х-байтовые (что не совсем удобно при мелких блоках).

KF> И то, и другое. Тот который с таблицей удобен для выделения блоков
KF> фиксированного и относительно большого размера. Hо не обязательно, что
KF> выделенное пространство непрерывно. Традиционный C-шный malloc()
KF> оперирует с кучей, где все выделенные части имеют разный и чаще
KF> небольшой размер. Hет, на самом деле наиболее выгоден комбинированный
KF> подход, так совсем мелкие участки памяти более выгодно будет выделять
KF> на стеке организованном вмутри одного более крупного блока...
KF> У меня кстати по 6 байт на блок получается:

А у меня получилось 5. Байт на флаг занятости+владелец, 2 байта длина, и 2
байта адрес предыдущего блока.
Да вне зависимости от структуры, интерфейс остается одинаковым - настройка на
расположение кучи и ее инициализация (init), alloc, free и realloc.

KF> Возможен и другой вариант, с указателями. Минимум -- 4 байта на блок
KF> (двусвязный список, указатель на следующий и предыдущий). С меткой,
KF> а она очень полезна для профилактики предотвращения ошибок, будет 6.
KF> Можно и односвязный список, но тогда куча будет просматриваться
KF> всегда с одного места, с начала -- это плохо.

Да, односвязный точно плохо. А насчет профилактики ошибок, то можно ведь (хотя
это и дольше по скорости) проверить предыдущий и следующий блок, сходятся ли
длины/указатели. Тогда не надо метки.

KF> Обычно куча каждый раз
KF> просматривается со следующего блока, циклически, это предотвращает
KF> скапливание большого числа мелких блоков /и неиспользуемой памяти/ с
KF> одного края кучи.

То есть запоминается адрес последнего выделенного блока, и при следующем alloc
ищется не сначала, а после него? Да, пожалуй верно.

AS>> И вопрос еще, приплетать ли сюда верхнюю память, или же на нее
AS>> свой постраничный аллокатор.

KF> Постраничный, или поблочный. Для страничной памяти именно так лучше,
KF> потому как зачастую весьма желательно выделить какую-то часть памяти
KF> целиком и ни одного байта отдать нельзя. А внутри блоков выделенных
KF> поблочным аллокатором можно создавать кучи для выделения более мелких
KF> кусков нефиксированного размера.

Тогда получается что функциям аллокатора надо передавать еще и адрес/размер
кучи. Hе слишком ли?
А то что верхняя память постранично, это да, наиболее удобный и наименее
ресурсоемкий вариант. Таблица занятости - битовая маска, либо если надо
владельцев учитывать, то по байту на страницу.

AS>> В случае процессов тут надо еще учитывать кто берет память, а
AS>> так же критические секции. Hо это уже для ОС, а не программ.

KF> Расскажу как сделать семафор на 8 позиций:

KF> scf
KF> rl (hl)
KF> jr nc, свободно
KF> ; занято (все 8)
KF> свободно:
KF> ...
KF> ...
KF> or a
KF> rr (hl) ; освободили ресурс.
KF> примерно так... Для двоичного варианта инициирующее значение == -2.

Это все понятно, но к чему оно было сказано? Причем тут критические секции? По
мне, так лучше не двоичный, а простой однобайтовый счетчик. Если он 0, значит
свободно.

До новых встреч! С уважением, Тхэнн.

Привет тебе, _/Kirill/_!

09 мая 2004 12:00, Kirill Frolov писал(а) Aleksey Senilov:

AS>> Вот аллокатор памяти действительно бы очень неплохо, сам его
AS>> изобретал уже несколько раз, для разных целей. Вариантов
AS>> собственно два - либо таблица блоков, либо в самих блоках
AS>> заголовки 3х-байтовые (что не совсем удобно при мелких блоках).

KF> И то, и другое. Тот который с таблицей удобен для выделения блоков
KF> фиксированного и относительно большого размера. Hо не обязательно, что
KF> выделенное пространство непрерывно. Традиционный C-шный malloc()
KF> оперирует с кучей, где все выделенные части имеют разный и чаще
KF> небольшой размер. Hет, на самом деле наиболее выгоден комбинированный
KF> подход, так совсем мелкие участки памяти более выгодно будет выделять
KF> на стеке организованном вмутри одного более крупного блока...
KF> У меня кстати по 6 байт на блок получается:

А у меня получилось 5. Байт на флаг занятости+владелец, 2 байта длина, и 2
байта адрес предыдущего блока.
Да вне зависимости от структуры, интерфейс остается одинаковым - настройка на
расположение кучи и ее инициализация (init), alloc, free и realloc.

KF> Возможен и другой вариант, с указателями. Минимум -- 4 байта на блок
KF> (двусвязный список, указатель на следующий и предыдущий). С меткой,
KF> а она очень полезна для профилактики предотвращения ошибок, будет 6.
KF> Можно и односвязный список, но тогда куча будет просматриваться
KF> всегда с одного места, с начала -- это плохо.

Да, односвязный точно плохо. А насчет профилактики ошибок, то можно ведь (хотя
это и дольше по скорости) проверить предыдущий и следующий блок, сходятся ли
длины/указатели. Тогда не надо метки.

KF> Обычно куча каждый раз
KF> просматривается со следующего блока, циклически, это предотвращает
KF> скапливание большого числа мелких блоков /и неиспользуемой памяти/ с
KF> одного края кучи.

То есть запоминается адрес последнего выделенного блока, и при следующем alloc
ищется не сначала, а после него? Да, пожалуй верно.

AS>> И вопрос еще, приплетать ли сюда верхнюю память, или же на нее
AS>> свой постраничный аллокатор.

KF> Постраничный, или поблочный. Для страничной памяти именно так лучше,
KF> потому как зачастую весьма желательно выделить какую-то часть памяти
KF> целиком и ни одного байта отдать нельзя. А внутри блоков выделенных
KF> поблочным аллокатором можно создавать кучи для выделения более мелких
KF> кусков нефиксированного размера.

Тогда получается что функциям аллокатора надо передавать еще и адрес/размер
кучи. Hе слишком ли?
А то что верхняя память постранично, это да, наиболее удобный и наименее
ресурсоемкий вариант. Таблица занятости - битовая маска, либо если надо
владельцев учитывать, то по байту на страницу.

AS>> В случае процессов тут надо еще учитывать кто берет память, а
AS>> так же критические секции. Hо это уже для ОС, а не программ.

KF> Расскажу как сделать семафор на 8 позиций:
KF> scf
KF> rl (hl)
KF> jr nc, свободно
KF> ; занято (все 8)
KF> свободно:
KF> ...
KF> ...
KF> or a
KF> rr (hl) ; освободили ресурс.
KF> примерно так... Для двоичного варианта инициирующее значение == -2.

Это все понятно, но к чему оно было сказано? Причем тут критические секции? По
мне, так лучше не двоичный, а простой однобайтовый счетчик. Если он 0, значит
свободно.

До новых встреч! С уважением, Тхэнн.

Привет тебе, _/Alexander/_!

10 мая 2004 00:29, Alexander Bondarenko писал(а) Aleksey Senilov:

AB> Hy вот, я же говоpю - всё yпиpается в ОСЬ....

Так что же мешает её создать? Груз прошлого софта? Разобщенность попыток
написания?

До новых встреч! С уважением, Тхэнн.

Hемедленно нажми на RESET, Aleksey Senilov!

On Fri, 14 May 04 14:26:05 +0400, Aleksey Senilov wrote:

KF>> целиком и ни одного байта отдать нельзя. А внутри блоков выделенных
KF>> поблочным аллокатором можно создавать кучи для выделения более мелких
KF>> кусков нефиксированного размера.
AS> Тогда получается что функциям аллокатора надо передавать еще и
AS> адрес/размер кучи. Hе слишком ли?

Один указатель на объект-кучу, в котором всё что нужно и хранится.

KF>> Расскажу как сделать семафор на 8 позиций:
KF>> scf
KF>> rl (hl)
KF>> jr nc, свободно
KF>> ; занято (все 8)
KF>> свободно:
KF>> ...
KF>> ...
KF>> or a
KF>> rr (hl) ; освободили ресурс.
KF>> примерно так... Для двоичного варианта инициирующее значение == -2.

AS> Это все понятно, но к чему оно было сказано? Причем тут критические
AS> секции?

Более традиционный способ предполагает запрещение прерываний.
Hеприемлемо при отсчёте времени по кадровому прерыванию (легко его
пропустить) и сложно реализуемо при работе с модемами подключенными
по кондратьевской схеме (там NMI, запрещается выводом в порт...)

AS> По мне, так лучше не двоичный, а простой однобайтовый счетчик. Если он 0,
AS> значит свободно.

Проблема в том, как проверить что он 0, и установить в не 0, если он
был 0... Даже для этого придётся или запрещать прерывания, или
использовать команду сдвига.

Привет тебе, _/Kirill/_!

15 мая 2004 00:54, Kirill Frolov писал(а) Aleksey Senilov:

AS>> Тогда получается что функциям аллокатора надо передавать еще и
AS>> адрес/размер кучи. Hе слишком ли?

KF> Один указатель на объект-кучу, в котором всё что нужно и хранится.

Впрочем да... просто в системе этот параметр может проставляться автоматом,
перед вызовом непосредственно alloc.

AS>> Это все понятно, но к чему оно было сказано? Причем тут
AS>> критические секции?

KF> Более традиционный способ предполагает запрещение прерываний.
KF> Hеприемлемо при отсчёте времени по кадровому прерыванию (легко его
KF> пропустить) и сложно реализуемо при работе с модемами подключенными
KF> по кондратьевской схеме (там NMI, запрещается выводом в порт...)

Тогда да, правильный вариант.

AS>> По мне, так лучше не двоичный, а простой однобайтовый счетчик.
AS>> Если он 0, значит свободно.

KF> Проблема в том, как проверить что он 0, и установить в не 0, если он
KF> был 0... Даже для этого придётся или запрещать прерывания, или
KF> использовать команду сдвига.

А что насчет inc/dec (hl) и проверки флага Z? Свободное значение тогда скорее
#FF, но все же.

До новых встреч! С уважением, Тхэнн.