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

Hello, Vitamin

пересилил я себя, в который раз причём

Я витамина сразу понял а вот основная масса участников видимо не прониклась
духом идеи - как говорят софисты "прежде чем отергать идею, надо проникнуть её
духом"

Витамин спросил - какова вообще идея?
Я считаю что идея отличная, и ставлю за идею 5 баллов.

Далее, что плохого есть в идее.
Как уже отмечено инерция мышления и как итог - инерция в методиких создания
программных продуктах на спекке. Hо речь не об этом.

Мне кажется основная масса непоняток выходит из того, что витамин недостаточно
внятно объяснил что это даст. А я попытаюсь это сделать.

Вот такая общая мысль.
Каждый из нас сталкивался при написании своих программ с тем, что надо рисовать
1 единственный символ в заданном знакоместе из заданного шрифта (расположенного
в памяти). Стандартное RST 8 кажется по-моему только на заре программирования
использовали - каждый сейчас пользует для этого свой код. Даже в случае, если
надо рисовать символ 8x8 точек (что справедливо далеко не всегда). Вот первый
претендент - процедура прорисовки символов. (здесь не торопитесь писать
"опровержение", потерпите и дочитатайте тред до конца). Вызов - в программе -
на внешнюю точку Call Scr.PrintChar8x8 (первая часть имени функции обозначает
его модуль - модуль Scr)

Каждый из нас сталкивался с тем, что отсутствует эффективная процедура работы с
диском (опять же стандартная #3D13 слишком медленнная, и даже имеющиеся в ней
возможности порой значительно ограничены). Тут уж я исключаю такого рода
проблемы как поддержка (полная) жёсткого диска, работа с расширенной файловой
системой TRDOS Directory System и т.д. Поэтому второй претендет - бинарник для
работы с носителями, в том числе с файлами. Вызов Disc.FileRead,
Disc.SectorRead, Disc.SectorWrite. Кстати не факт, что даже те процедуры что
сейчас есть для скачивания работают хорошо - я вот специально для себя писал
очень хитрый дискожуйный процедур, который работает не посекторно а потреково,
что уменьшает время решения разрешаемых ошибок чтения и уменьшает
"головобуйство" дисководов, экономя их ресурс в том числе, но опять же не про
это речь. Модуль - Disc.

Модуль опроса клавиатуры.
Hе секрет, что клавиатурный менеджер висящий на прерываниях спекка опять же
оставляет желать лучшего - нет буферизации нажатых символов, нет возможности
(через него) определить нажатие функциональных клавиш - таких как SymShift,
CapsShift; русскоязычная поддержка это вообще из области фантастики. KB.ReadKey
- читает клавишу нажатую пользователем. KB.Clear - очищает буфер. Модуль
соответственно - KB.

Модуль рисования всеразличных рамок - Window. Window.Show - прорисовывает
окошко. Тут даже может быть целая система, учитывающая взаимозакрывания окошек
(т.е. когда окошко одно частично закрыто другим, а потом это заднее окошко
всплывает).

Модуль арифметических операций Arithm - работает с быстрой целочисленной
арифметикой (скорость калькулятора ПЗУ SOS оставляет желать лучшего, хотя
функционал там конечно богатый). Arithm.16mul16 - перемножает два 16битных
числа. Arithm.16div16 - делает одно 16разрядное на другое.

Модуль работы с памятью - RAM. RAM.ChangePh - смена страницы памяти на заданную
физическую. RAM.ChangeLog - смена страницы памяти на заданную логическую.

И вот, я хочу написать бут, хочу написать текстовый редактор, хочу написать
вьюер, хочу написать игрушку. Что из этих процедур я буду использовать?
Правильно - все из них. И тем не менее, в существующей среде каждая из программ
использует свой воз и тележку - где хранится это всё добро, и мало того - по
причине закрытости исходов, нежелания автора заниматься программой и т.д. и
т.п. в программах есть глюки, которые (90%) являются следствием криво
написанных перечисленных процедур. Т.е. битком забитый диск программами
спекковский диск де факто повторяет себя почти на 90%. Кроме того, часто
указанные процедуры цепляются к тексту в виде некоего дополнения к каждой из
запускаемых программ - в итоге и без того ограниченное количество допустимых
файл-ячеек в ТРДОС используется малоэффективно.

И теперь смотрим как это может быть - на диске лежит 1 pak файл, лежит 1 boot.B
и кусочек кода к нему и лежат куча стартеров - файлов скажем с расширением R
(взято произвольно, кстати они тоже могут быть в виде одного файла, и вообще
здесь файловая структура не так критична). Эти стартеры могут быть и бейсик
программами и просто кодом - это не так важно. Важно, что boot.b загрузит при
старте линковщик (или компилятор если угодно), который будет уже работать с
лежащими в pak файле указанными модулями.
Хочется подчеркнуть такой немаловажный с моей точки зрения момент - модули
фактически являются законченным машинным под Z80 кодом с той лишь разницей, что
он сопровождается заголовком релокации для того, чтобы можно было склеить эти
модули с головной программой. Впрочем, лучше почитать документацию к модулям и
станет понятно что обвинения в писюканстве и амижстве здесь бессмысленные.
И вот, запускаю я свой излюбленный вьюер - и что же? фактически, загрузится МОЯ
логика реализованная в коде Z80 - мой код (назову это индивидуальный код) -
т.е. только то, что в общем то и надо было написать для того чтобы куча
библиотек превратилась в вьюер [основная масса существующего программного
зоопарка несовершенна по причинами того, что кодер реализовав свою логику,
которая на самом деле является изюминкой программы должен ещё и написать
процедуры для отработки указанных действий - работы с дисками, клавиатурой,
арифсетика, память и т.д.] - код будет просто дёргать нужные функции и я не
буду задумываться о реализации универсального драйвера памяти (кроме случая
когда он будет для меня слишком медленный, но это около 1% случаев всего
кодописания), я не буду задумываться куда мне обратиться за опросом клавиатуры,
я не буду задумываться даже на каком устройстве я сейчас работаю - потому что
драйвер уже это сделает, потому что он включен в программу - ну и т.д.

Теперь, нажал я резет. Hадоел мне вьюер, я захотел текст понабирать - и всё то
же самое - загрузился только МОЙ индивидуальный код и все остальные модули
подхватились сами.

Кстати тут очень интересный вариант, что модули будут лежать даже не на самом
диске, а скажем на ЖД, или например во втором дисководе будет лежать диск с
модулями - т.е. даже отпадёт необходимость на конечный диск писать библиотеки.

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

Hапоследок хочу сравнить два подхода - которые как мне кажется в некотором
смысле конкурирующие - 1) когда имеются ИСХОДHИКИ всех используемых процедур и
в процессе компиляции всё собирается в один конечный файл 2) когда имеется
модульная структура и фактически компилируется только индивидуальный код.

1) возможность расширения 100% за счёт стороннего кода; возможность подмены
исходных возможно глючных библиотек - только при перекомпиляции всего кода;
количество необходимых файлов (в килобайтах и в штуках) - большое
2) возможность расширения - отсутствует, это готовый код - только при
перекомпиляции; возможность подмены библиотек - 100% за счёт модульной
организации; количество необходимых файлоы (в штуках и килобайтах) - невелико.