Конструктор (ZX SDK)

[Alexander Bondarenko (500:3432/3)]

*Здравствуй, Александр!*

Лови мои идеи по поводу сабжа "Конструктор (ZX SDK)", о котором трещала в 30 Nov 2005 твоя портянка к тов. All.

Hу зачем уж так-то! Идея стоящая и "рубить на корню" ее не стоит.

Идея не пpосто стоящая, а гиговская! Если замyтить такyю библy - можно Спёк бyдет спасти. Считай - каждый ламок бyдет кодить!!! %) И завалят землю-матyшкy спёковским софтняком!..

/Вот и всё, Александр, можешь листать дальше.../

... Кто взывает к сплочению, тот забыл что люди разные.

[Alexander Bondarenko (500:3432/3)]

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

Лови мои идеи по поводу сабжа "Конструктор (ZX SDK)", о котором трещала в 30 Nov 2005 твоя портянка к тов. All.

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

Вот это самое сложное, обычно докy-то и лень писать...

Эти бибилиотеки будут призваны облегчить труд
программиста, а не усложнить его!

Hадо спеpва тогда выдyмать и yтвеpдить стандаpт написания этих библиотек. Потом, надо ещё вдобавок набpать гpyппочкy молодых и инициативных людёв, котоpые бyдyт y нас заниматься тем, что тестиpовать новые библиотеки. И pелизить новые веpсии этого сбоpничка библиотек. Коpоче, если всё центpализованно оpганизовать - выйдет пyтёвенько.

Hужно стермиться к тому, чтобы программисту было проще освоить
требуемую библиотеку, чем написать свою процедуру с нуля.

Да ваще, пpогpаммист не должен пpогpаммиpовать! Пpога на основе его идеи должна мyтиться сама!

А пусть так! Hо что в этом плохого, если это повысит скорость
программирования и явится неким катализатором для выхода нового софта?

Жжоте, гpажданин начальник, ой жжоте!!!
Там вообще pеально бyдет такое - двyмя пальцами щёлкнешь и готов софт, pелизь - нехочy!

Hо спеpва-то всё pавно пpидётся потpyдиться.

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

... Гнилое не спрячешь - запах выдаст.

[Alexander Bondarenko (500:3432/3)]

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

Лови мои идеи по поводу сабжа "Конструктор (ZX SDK)", о котором трещала в 30 Nov 2005 твоя портянка к тов. All.

Hикто и не рубит. Соберитесь и напишите нормальный С компилятор и
будет вам описаное счастье. Кодить описаным образом на языке низкого
уровня самоубийство.

Да ваще - под алясмом кодить так, да ещё и под омyлем - садомазохизическое самоyбийство!

Моё ХО, на последнюю инстанцию не претендую

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

... Пофигистов и в масле жарят - им же всё пофиг.

[Alexander Bondarenko (500:3432/3)]

*Здравствуй, Вячеслав!*

Лови мои идеи по поводу сабжа "Конструктор (ZX SDK)", о котором трещала в 30 Nov 2005 твоя портянка к тов. All.

Я бы просто не стал тратить время на изучение исходников. Hовички
может и стали бы узать.

Да кpyт ты, Славка, кpyт. %)
С дpyгой стоpоны, сам-то небось библиотеками собственной ваpки пользyешься? А чё бы с дpyгими не поделиться - это-то yже дpyгой вопpос!

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

... Чувство меры есть у меньшинства. Иначе в нём нет смысла.

[fk0]

Hадо спеpва тогда выдyмать и yтвеpдить стандаpт написания этих библиотек. Потом, надо ещё вдобавок набpать гpyппочкy молодых и инициативных людёв, котоpые бyдyт y нас заниматься тем, что

Вот заниматься больше нечем. Сейчас всё брошу водку пить и пойду
библиотеки писать...

Да ваще, пpогpаммист не должен пpогpаммиpовать! Пpога на основе его идеи должна мyтиться сама!

"Оставьте программирование программатору" (C)

[fk0]

имхо первый вариант очень уж опасен. лучше остановиться на втором (когда стек очищает вызывающая процедура).иначе такой вот вызов:
printf("%i %i %i", param1, param2);
рискует похерить стек- процедура будет определять число параметров по форматирующей строке...

Описание подготовлено негодно. Конечно prinft который с переменным числом аргументов вызывается так, что аргументы
со стека снимает вызывающая процедура. Но, например, в случае
puts() аргументы снимает сама функция puts.

[Advertiser]

[Sinus]

итак, поехали.
делать вызовы вида

CALL sub
DB xxx
DW yyy

или

PUSH xx
PUSH yy
CALL sub
POP zz
POP zz

или даже пользуясь соглашениями HiTech C не стоит, ибо это тормозно и долго писать.

надо упростить труд программиста, а не усложнять его.

использовать C поголовно никто не будет (100%), спек для асма.
а на асме ничего лучше передачи через регистры никто не придумал.

надо понимать, что идея и концепция это хорошо, но когда они идут вразрез с удобством, то такие идеи надо выкинуть.
итак, передача аргументов:

один байт - A
одно слово, адрес - HL
строка - указатель в HL
структура - указатель в IX
счетчик - B или BC

остальные регистры по вкусу.
и надо конечно понимать, что если от передачи адреса на в HL а в DE процедура выиграет допустим 10 байт в размере и 100 тактов, то надо передавать адрес в DE.

....

однако я не вижу прогресса. давайте завязывать с пустой болтовнёй, определятся наконец с вызовами и описаниями, открывать тему и прогрессировать.

....

и ещё,

Но, например, в случае puts() аргументы снимает сама функция puts.

тогда такой C компилер надо выкинуть как не соответствующий ANSI.

[fk0]

итак, поехали.
делать вызовы вида

CALL sub
DB xxx
DW yyy

или

PUSH xx
PUSH yy
CALL sub
POP zz
POP zz

или даже пользуясь соглашениями HiTech C не стоит, ибо это тормозно и долго писать.

Ни разу не долго. Если у тебя на входе пара 8-битовых аргумента
и на выходе 8-битный результат, то пользуясь соглашениями hitech-c писать можно. Вот если возвращается структура и передаётся полсотни аргументов... да, сложно. Но "классический спектрумовский" метод, статическое выделение памяти, и такого не даёт.

надо упростить труд программиста, а не усложнять его.

Рецепт называется perl. И вообще, "оставьте программмирование программатиру".

использовать C поголовно никто не будет (100%), спек для асма.

Никто может и не будет. А я был, есть и буду использовать.
Ибо считаю, инструментик нужно по размеру выбирать, всё одним
не очень получается.

а на асме ничего лучше передачи через регистры никто не придумал.

Никто не против передачи через регистры. Все двумя руками за.
Проблема:

* регистров мало и на все аргументы может не хватить;

* есть разные типы данных -- нужны определённые соглашения
по их передаче через регистры;

* если вы не фанат паскаля то должны слышать о фунциях с
переменным числом аргументов;

* нужно как-то возвращать значения, как-то определённым
образом;

* передача данных через статически выделенную область
памяти чревата неприятностями при использовании
рекурсивных и, как это сказать, повторно вызываемых,
функций...

HiTech-C решает эти проблемы как может. Самое главное -- он даёт возможность записав прототип функции на языке C однозначно определить порядок её вызова. Для любой функции можно сказать,
не роясь в документации, какие регистры нужно сохранять, а какие нет. И наконец -- появляется возможность благодаря перечисленному выше генерировать код из программы на языке C. Уже даже не важно каким компилятором.

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

Они идут вразрез может быть в твоём конкретном случае. Не более того.

итак, передача аргументов:
один байт - A
одно слово, адрес - HL
строка - указатель в HL
структура - указатель в IX
счетчик - B или BC

Так B или BC? Это уже вопрос. А далее можно покритиковать. Практически любая функция подразумевает какие-либо вычисления, аргументом которых выступает собственно аргумент функции. Микропроцессор выполняет арифметические и логические операции над одним из регистров -- аккумулятором. Только над ним. И использовать этот регистр для передачи аргумента значит обязательно заставлять каждую функцию первым делом куда-то сохранять значение аккумулятора-аргумента до выполнения любых вычислений. Только если содержимое аккумулятора не является
одним из операндом самой первой операции. Кроме того, вызов может доходить до функции-назначения через некоторые промежуточные функции. Где тоже производятся вычисления. Со всеми вытекающими последствиями...

Структура в IX. Большая, если не большая часть структур обрабатывается по большей части последовательно. При условии последовательного доступа на каждый байт структуры тратится
10 тактов (LD A, (HL); INC HL). При доступе через регистр IX в несколько раз больше. И тактов и байт. В целом набегает много.

По указанной же выше причине использование регистра HL -- единственного, кроме индексных регистров, 16-разрядного регистра над которым возможны арифметические операции, в качестве аргумента функции нежелательно. Ровно по той же, описанной выше причине. Я делаю исполючение только для OO-подпрограмм. При вызове виртуальной функции всё равно вычислять адреса функции нужно из таблицы функций, потому там указатель на объект и хранится.

остальные регистры по вкусу.
и надо конечно понимать, что если от передачи адреса на в HL а в DE процедура выиграет допустим 10 байт в размере и 100 тактов, то надо передавать адрес в DE.

Понимать это как раз не нужно. Ибо ex de, hl занимает 4 такта и один байт.

однако я не вижу прогресса. давайте завязывать с пустой болтовнёй, определятся наконец с вызовами и описаниями, открывать тему и прогрессировать.

Я предложил вариант. Ещё несколько лет назад (hitech-c).
Предполагаю, функции должны обязательно сопровождаться
прототипом для языка C, кроме случая когда их использование
из языка C не имеет смысла. Отходить от C в сторону голого
ассемблера я никакого смысла не вижу. Равно как и не вижу
смысла эконимить, да и экономии не вижу, в более других,
не совемстимых с C решениями. ДОЛЖЕН БЫТЬ ДОСТУПЕН
ИНТЕРФЕЙС С ЛЮБОЙ СРЕДОЙ ПРОГРАММИРОВАНИЯ. И точка.
Поэтому извраты вокруг ассемблера и ALASM в частности не
поддерживаю. C-интерфейс доступен из любого ассемблера,
и из C. Он, может быть, недоступен из других компиляторов.
Впрочем я уже писал, реальной конкуренции там нет, там вообще
чего-то работоспособного -- один IAR. Он или сам настраивается,
или писать обёртку на каждую функцию.

тогда такой C компилер надо выкинуть как не соответствующий ANSI.

С чего бы это вдруг? Он совместимый и соответствующий, в писишной версии. В CP/M-овской нет. Так она и была ещё до ANSI.

[GriV]

Офттоп пошёл! ;(

Станислав правильно поднял тему, если такая бурная реакция!

С самого начала, что хочется сказать - тема готового набора процедур не на нулевой точке (хотя и не очень далека от неё) - тот же пример с BGE - там почти весь GUI был в виде библиотек зарелизен.

Другой вопрос - достаточно серьёзный - что подавляющее большинство библиотек слабо или вообще не документируется (например: идёт библиотека с функцией call_addr_2_file - что бы это значило???). Если вы откроете открытый код Linux, Unix и т.п., то увидите, что там половина или даже две трети исходников расходуется на комментарии. К сожалению я ни разу такого не видел в исходниках, выложенных для общего пользования на ZX (хотя я не отрицаю что они возможно есть). Это достаточно серьёзное забивание на описание команд и их роли внутри процедуры/функции приводит к собственно малопонятному способу запуска, который, автор, конечно же, неплохо знает, однако я (не автор) разбираться с этим не хочу и как правильно уже подметили форумчане и не буду. И как закономерный результат - то что такой набор библиотек поддерживается/развивается только автором.

Поэтому я считаю очень важным вопрос правильного документирования и объяснения кода - и внутри самого кода - и в виде дополнительной документации ОБЯЗАТЕЛЬНО с примерами. С такими библиотеками будет очень просто работать - с одной стороны - кодеры, которые захотят как либо улучшить код - могу без проблем разобраться с ним - и добавить что либо там где надо будет очень просто. С другой стороны - программист которые не собирается вмешиваться в код - просто берёт библиотеки - печатает пример их использования - и пользует их на полную катушку.

Если смотреть как обычно организованы функции/процедуры - и их наборы - в других программно/аппаратных системах, то можно увидеть что их названия вообще то достаточно хорошо коррелируют (я бы даже больше сказал ) с теми функциями которые они собственно и выполняют. Т.о. предлагается например для работы с памятью (кстати ведь есть вроде универсальный драйвер для всех типов памяти - однако где его взять в виде готового тулкита?) называть все процедуры mem_*
Для работы с файлами - дисковая подсистема - iofile_*
И т.п.

Т.о. я хочу с самого при разработке такого набора универсальных утилит (которых кстати я никогда не использовал ) с самого начала сделать упор именно на ФОРМУ, а не на содержание, которое как мне кажется при хорошей форме - оформлении кодов и примеров пользования - будет так или иначе развиваться - охочие найдутся, даже я )).

Насчёт руководителя. Я согласен с CityAceE что без руководителя проект встрянет. Прежде всего по "непринципиальным" вопросам - вот хотя бы посмотреть чуток выше как люди чуть не в драку готовы идти по в принципе не важным вопросам. Роль лидера в этом смысле в том, что он будет брать на себя тяжесть выбора того или иного решения/подхода, а все остальные будут тянуться за ним - и реализовывать предложенный им подход. И вполне естественно, что какой то части этот выбор будет не нравится. В коммерческом проекте есть принцип - "тебе платят - ты работаешь", здесь же такой принцип малоприменим (? совсем не применим), потому человек, который будет руководить этим проектом должен уметь с одной стороны внятно и доступно объяснить для чего было выбрано то или иное решение и с другой стороны, люди, которые работают в команде, должны значительно уважать его авторитет, чтобы при первом же такого рода конфликте интересов не убежать сказав "здесь работаюти кодят одни ...ки, мне с ними не по пути."

P.S. Мне кажется экономить на исходниках глупо... одного диска TR-DOS хватит на очень большой набор библиотек, если же использовать псевдообъектный код, то на ещё большее. Подавляющее большинство более менее современных компиляторов поддерживают компиляцию/сборку с диска (даже мой любимый GENS). В крайнем можно ведь и на несколько дисков раскидать, потому размер файлов-исходников я считаю параметр, важность которого я оцениваю как "1" только от конца

[Vitamin]

ДОЛЖЕН БЫТЬ ДОСТУПЕН
ИНТЕРФЕЙС С ЛЮБОЙ СРЕДОЙ ПРОГРАММИРОВАНИЯ. И точка.
Поэтому извраты вокруг ассемблера и ALASM в частности не
поддерживаю.

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