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, но все же. До новых встреч! С уважением, Тхэнн.