Вид для печати
*Здравствуй, Александр!*
Лови мои идеи по поводу сабжа "Конструктор (ZX SDK)", о котором трещала в 30 Nov 2005 твоя портянка к тов. All.
Идея не пpосто стоящая, а гиговская! Если замyтить такyю библy - можно Спёк бyдет спасти. Считай - каждый ламок бyдет кодить!!! %) И завалят землю-матyшкy спёковским софтняком!.. :DЦитата:
Hу зачем уж так-то! Идея стоящая и "рубить на корню" ее не стоит.
/Вот и всё, Александр, можешь листать дальше.../
... Кто взывает к сплочению, тот забыл что люди разные.
*Здравствуй, 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тёвенько.Цитата:
Эти бибилиотеки будут призваны облегчить труд
программиста, а не усложнить его!
Да ваще, пpогpаммист не должен пpогpаммиpовать! Пpога на основе его идеи должна мyтиться сама!Цитата:
Hужно стермиться к тому, чтобы программисту было проще освоить
требуемую библиотеку, чем написать свою процедуру с нуля.
Жжоте, гpажданин начальник, ой жжоте!!! ;)Цитата:
А пусть так! Hо что в этом плохого, если это повысит скорость
программирования и явится неким катализатором для выхода нового софта?
Там вообще pеально бyдет такое - двyмя пальцами щёлкнешь и готов софт, pелизь - нехочy!
Hо спеpва-то всё pавно пpидётся потpyдиться.
/Вот и всё, Stanislav, можешь листать дальше.../
... Гнилое не спрячешь - запах выдаст.
*Здравствуй, Andreas!*
Лови мои идеи по поводу сабжа "Конструктор (ZX SDK)", о котором трещала в 30 Nov 2005 твоя портянка к тов. All.
Да ваще - под алясмом кодить так, да ещё и под омyлем - садомазохизическое самоyбийство!Цитата:
Hикто и не рубит. Соберитесь и напишите нормальный С компилятор и
будет вам описаное счастье. Кодить описаным образом на языке низкого
уровня самоубийство.
/Вот и всё, Andreas, можешь листать дальше.../Цитата:
Моё ХО, на последнюю инстанцию не претендую :)
... Пофигистов и в масле жарят - им же всё пофиг.
*Здравствуй, Вячеслав!*
Лови мои идеи по поводу сабжа "Конструктор (ZX SDK)", о котором трещала в 30 Nov 2005 твоя портянка к тов. All.
Да кpyт ты, Славка, кpyт. %)Цитата:
Я бы просто не стал тратить время на изучение исходников. Hовички
может и стали бы узать.
С дpyгой стоpоны, сам-то небось библиотеками собственной ваpки пользyешься? А чё бы с дpyгими не поделиться - это-то yже дpyгой вопpос!
/Вот и всё, Вячеслав, можешь листать дальше.../
... Чувство меры есть у меньшинства. Иначе в нём нет смысла.
Вот заниматься больше нечем. Сейчас всё брошу водку пить и пойдуЦитата:
Сообщение от Alexander Bondarenko (500:3432/3)
библиотеки писать...
"Оставьте программирование программатору" (C)Цитата:
Да ваще, пpогpаммист не должен пpогpаммиpовать! Пpога на основе его идеи должна мyтиться сама!
Описание подготовлено негодно. Конечно prinft который с переменным числом аргументов вызывается так, что аргументыЦитата:
Сообщение от Vitamin
со стека снимает вызывающая процедура. Но, например, в случае
puts() аргументы снимает сама функция puts.
итак, поехали.
делать вызовы вида
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.
....
однако я не вижу прогресса. давайте завязывать с пустой болтовнёй, определятся наконец с вызовами и описаниями, открывать тему и прогрессировать.
....
и ещё,
тогда такой C компилер надо выкинуть как не соответствующий ANSI.Цитата:
Но, например, в случае puts() аргументы снимает сама функция puts.
Ни разу не долго. Если у тебя на входе пара 8-битовых аргументаЦитата:
Сообщение от Sinus
и на выходе 8-битный результат, то пользуясь соглашениями hitech-c писать можно. Вот если возвращается структура и передаётся полсотни аргументов... да, сложно. Но "классический спектрумовский" метод, статическое выделение памяти, и такого не даёт.
Рецепт называется perl. И вообще, "оставьте программмирование программатиру".Цитата:
надо упростить труд программиста, а не усложнять его.
Никто может и не будет. А я был, есть и буду использовать.Цитата:
использовать C поголовно никто не будет (100%), спек для асма.
Ибо считаю, инструментик нужно по размеру выбирать, всё одним
не очень получается.
Никто не против передачи через регистры. Все двумя руками за.Цитата:
а на асме ничего лучше передачи через регистры никто не придумал.
Проблема:
* регистров мало и на все аргументы может не хватить;
* есть разные типы данных -- нужны определённые соглашения
по их передаче через регистры;
* если вы не фанат паскаля то должны слышать о фунциях с
переменным числом аргументов;
* нужно как-то возвращать значения, как-то определённым
образом;
* передача данных через статически выделенную область
памяти чревата неприятностями при использовании
рекурсивных и, как это сказать, повторно вызываемых,
функций...
HiTech-C решает эти проблемы как может. Самое главное -- он даёт возможность записав прототип функции на языке C однозначно определить порядок её вызова. Для любой функции можно сказать,
не роясь в документации, какие регистры нужно сохранять, а какие нет. И наконец -- появляется возможность благодаря перечисленному выше генерировать код из программы на языке C. Уже даже не важно каким компилятором.
Они идут вразрез может быть в твоём конкретном случае. Не более того.Цитата:
надо понимать, что идея и концепция это хорошо, но когда они идут вразрез с удобством, то такие идеи надо выкинуть.
Так B или BC? Это уже вопрос. А далее можно покритиковать. Практически любая функция подразумевает какие-либо вычисления, аргументом которых выступает собственно аргумент функции. Микропроцессор выполняет арифметические и логические операции над одним из регистров -- аккумулятором. Только над ним. И использовать этот регистр для передачи аргумента значит обязательно заставлять каждую функцию первым делом куда-то сохранять значение аккумулятора-аргумента до выполнения любых вычислений. Только если содержимое аккумулятора не являетсяЦитата:
итак, передача аргументов:
один байт - A
одно слово, адрес - HL
строка - указатель в HL
структура - указатель в IX
счетчик - B или BC
одним из операндом самой первой операции. Кроме того, вызов может доходить до функции-назначения через некоторые промежуточные функции. Где тоже производятся вычисления. Со всеми вытекающими последствиями...
Структура в IX. Большая, если не большая часть структур обрабатывается по большей части последовательно. При условии последовательного доступа на каждый байт структуры тратится
10 тактов (LD A, (HL); INC HL). При доступе через регистр IX в несколько раз больше. И тактов и байт. В целом набегает много.
По указанной же выше причине использование регистра HL -- единственного, кроме индексных регистров, 16-разрядного регистра над которым возможны арифметические операции, в качестве аргумента функции нежелательно. Ровно по той же, описанной выше причине. Я делаю исполючение только для OO-подпрограмм. При вызове виртуальной функции всё равно вычислять адреса функции нужно из таблицы функций, потому там указатель на объект и хранится.
Понимать это как раз не нужно. Ибо ex de, hl занимает 4 такта и один байт.Цитата:
остальные регистры по вкусу.
и надо конечно понимать, что если от передачи адреса на в HL а в DE процедура выиграет допустим 10 байт в размере и 100 тактов, то надо передавать адрес в DE.
Я предложил вариант. Ещё несколько лет назад (hitech-c).Цитата:
однако я не вижу прогресса. давайте завязывать с пустой болтовнёй, определятся наконец с вызовами и описаниями, открывать тему и прогрессировать.
Предполагаю, функции должны обязательно сопровождаться
прототипом для языка C, кроме случая когда их использование
из языка C не имеет смысла. Отходить от C в сторону голого
ассемблера я никакого смысла не вижу. Равно как и не вижу
смысла эконимить, да и экономии не вижу, в более других,
не совемстимых с C решениями. ДОЛЖЕН БЫТЬ ДОСТУПЕН
ИНТЕРФЕЙС С ЛЮБОЙ СРЕДОЙ ПРОГРАММИРОВАНИЯ. И точка.
Поэтому извраты вокруг ассемблера и ALASM в частности не
поддерживаю. C-интерфейс доступен из любого ассемблера,
и из C. Он, может быть, недоступен из других компиляторов.
Впрочем я уже писал, реальной конкуренции там нет, там вообще
чего-то работоспособного -- один IAR. Он или сам настраивается,
или писать обёртку на каждую функцию.
С чего бы это вдруг? Он совместимый и соответствующий, в писишной версии. В CP/M-овской нет. Так она и была ещё до ANSI.Цитата:
тогда такой C компилер надо выкинуть как не соответствующий ANSI.
Офттоп пошёл! ;(
Станислав правильно поднял тему, если такая бурная реакция!
С самого начала, что хочется сказать - тема готового набора процедур не на нулевой точке (хотя и не очень далека от неё) - тот же пример с BGE - там почти весь GUI был в виде библиотек зарелизен.
Другой вопрос - достаточно серьёзный - что подавляющее большинство библиотек слабо или вообще не документируется (например: идёт библиотека с функцией call_addr_2_file - что бы это значило???). Если вы откроете открытый код Linux, Unix и т.п., то увидите, что там половина или даже две трети исходников расходуется на комментарии. К сожалению я ни разу такого не видел в исходниках, выложенных для общего пользования на ZX (хотя я не отрицаю что они возможно есть). Это достаточно серьёзное забивание на описание команд и их роли внутри процедуры/функции приводит к собственно малопонятному способу запуска, который, автор, конечно же, неплохо знает, однако я (не автор) разбираться с этим не хочу и как правильно уже подметили форумчане и не буду. И как закономерный результат - то что такой набор библиотек поддерживается/развивается только автором.
Поэтому я считаю очень важным вопрос правильного документирования и объяснения кода - и внутри самого кода - и в виде дополнительной документации ОБЯЗАТЕЛЬНО с примерами. С такими библиотеками будет очень просто работать - с одной стороны - кодеры, которые захотят как либо улучшить код - могу без проблем разобраться с ним - и добавить что либо там где надо будет очень просто. С другой стороны - программист которые не собирается вмешиваться в код - просто берёт библиотеки - печатает пример их использования - и пользует их на полную катушку.
Если смотреть как обычно организованы функции/процедуры - и их наборы - в других программно/аппаратных системах, то можно увидеть что их названия вообще то достаточно хорошо коррелируют (я бы даже больше сказал :D) с теми функциями которые они собственно и выполняют. Т.о. предлагается например для работы с памятью (кстати ведь есть вроде универсальный драйвер для всех типов памяти - однако где его взять в виде готового тулкита?) называть все процедуры mem_*
Для работы с файлами - дисковая подсистема - iofile_*
И т.п.
Т.о. я хочу с самого при разработке такого набора универсальных утилит (которых кстати я никогда не использовал :D) с самого начала сделать упор именно на ФОРМУ, а не на содержание, которое как мне кажется при хорошей форме - оформлении кодов и примеров пользования - будет так или иначе развиваться - охочие найдутся, даже я ;))).
Насчёт руководителя. Я согласен с CityAceE что без руководителя проект встрянет. Прежде всего по "непринципиальным" вопросам - вот хотя бы посмотреть чуток выше как люди чуть не в драку готовы идти по в принципе не важным вопросам. Роль лидера в этом смысле в том, что он будет брать на себя тяжесть выбора того или иного решения/подхода, а все остальные будут тянуться за ним - и реализовывать предложенный им подход. И вполне естественно, что какой то части этот выбор будет не нравится. В коммерческом проекте есть принцип - "тебе платят - ты работаешь", здесь же такой принцип малоприменим (? совсем не применим), потому человек, который будет руководить этим проектом должен уметь с одной стороны внятно и доступно объяснить для чего было выбрано то или иное решение и с другой стороны, люди, которые работают в команде, должны значительно уважать его авторитет, чтобы при первом же такого рода конфликте интересов не убежать сказав "здесь работаюти кодят одни ...ки, мне с ними не по пути."
P.S. Мне кажется экономить на исходниках глупо... одного диска TR-DOS хватит на очень большой набор библиотек, если же использовать псевдообъектный код, то на ещё большее. Подавляющее большинство более менее современных компиляторов поддерживают компиляцию/сборку с диска (даже мой любимый GENS). В крайнем можно ведь и на несколько дисков раскидать, потому размер файлов-исходников я считаю параметр, важность которого я оцениваю как "1" только от конца ;)
каки таки извраты? если про треп из соседней ветки, то там вообще по банану как передаются параметры (раз разговор зашел про них). и к чему тут упоминаются извраты с аласмом не понимаю...Цитата:
Сообщение от fk0
зы. а я хочу интерфейс с аласмом для начала! (как вот заявлено) почему он отвергается? ;) лозунги нарушаем-с %)
Нет. Почему -- в соседней ветке и пишется же.Цитата:
Сообщение от Vitamin
[/quote]Цитата:
и к чему тут упоминаются извраты с аласмом не понимаю...
зы. а я хочу интерфейс с аласмом для начала! (как вот заявлено) почему он отвергается? ;) лозунги нарушаем-с %)
Речь не про то, чтобы с аласмом было несовместимо.
Речь про то, чтобы НЕ БЫЛО СОВМЕСТИМО ТОЛЬКО С АЛАСМОМ.
Вот и Griv про BGE вспомнил. Это радует. Поэтому предлагаю без фанатизма - начать с аналогии системы аля BGE. просто процедура и описание: что на входе, что на выходе, можно ли из ПЗУ юзать/нет, сколько регистров херит. И всё. Без прибамбасов. А каменты может не надо прям в исходнике ? Рядом, в текстовичке.
имхо вопрос надо ставить не так. то, что в других компиляторах приходится делать вручную или через >|<опу, в аласме можно сделать автоматически. вот и все.Цитата:
Сообщение от fk0
гдето писалось про траблы создания плагинов к RC- создание таблиц релокации. это можно упростить!
В данном случае, вручную -- это значит НИКАК!.Цитата:
Сообщение от Vitamin
Таблицы релокации можно создать путём сравнения версий программ
откомпилированных по разным адресам. Кроме того, некоторые
компоновщики штатно умеют (тот же hitech-c). А вот таблицы патчей
для CALL -- это никто не умеет, ALASM+макросы == свой собственный,
ни с чем не совместимый, ассемблер.
MA80 (МОА) и M80 (CP/M) прекрасно умеют макросами создавать таблицы патчей.Цитата:
Сообщение от fk0
Как пример см. драйвер электронного диска под ISDOS by MOA.
хех, вспомнил - в древнючем zx-review была софтинка, которая строила такие таблицы на базе двух скомпиленых под разные адреса блоков одного и того же исходника и присобачивала настройщик. вот только блоки должны умещаться в 48к памяти, да и все равно это полуручная работа
Цитата:
Сообщение от fk0
иКод:org #6000
<код>
org ($+255)&#FF00
label ds 256
Вот и сравнивай...Код:org #789A
<такой же код>
org ($+255)&#FF00
label ds 256
нормальные люди больше одного org'a в одной проге не юзают (object save не работает как минимум). я делаю так:
defs $-(($-1)&ff00) (мож накосячил - не помню =) у меня макрос сто лет назад написан)
а чаще так:
;macros lib
_ORGA equ 0
defmac _ORGG
\0 equ _ORGA
_ORGA equ (_ORGA+\1)
endmac
;end maclib
;prog:
_ORGA=$
_ORGG buf1,#0100
_ORGG buf2,#0300
округление до ровных адресов в макросе добавить по вкусу...
а ты правильно под релокатор пиши!Цитата:
Сообщение от lvd
таблицы такие - генерить на месте или двигать :)
адрес программы тоже легко узнать
Нормальные люди вообще DEFS для кода отписываемого наЦитата:
Сообщение от jtn
диск не юзают. Я конечно понимаю, что hrust есть великий
рулез, но тем не менее, ещё с тех времён когда кроме mpack
ничего приличного не было, существовало нормальное решение,
когда все эти DEFS и извраты вокруг ORG затрагивали часть
области данных не отписываемую на диск. Для инициализации
писался код. И кроме того, вместо статического распределения
НИЧЕМ НЕ ХУЖЕ тривиальный аллокатор типа "стек", который
растёт вверх от конца программы. Или даже стек обыкновенный,
для чего он размещается не под телом кодового блока,
а в самом конце памяти. Делается просто: кодовый блок
размещается в REM-строке бейсик программы. А CLEAR ставится
на самый верх памяти. Суть в том, что в двух разных состояниях
программы отдельные статически выделенные блоки памяти
НЕ ИСПОЛЬЗУЮТСЯ и память тратится впустую. (Вот чего вечно
от спектрумистов слышно, что им памяти не хватает). Нормальный
аллокатор решает эту проблему. Её решает даже выделение
памяти на стеке. И выравнивание можно динамически, на ходу
любое выбирать.
Цитата:
Сообщение от jerri
Надо иметь три байта памяти. Ворос -- где их взять?Код:ld hl, NNNN ; push hl, pop hl
ld (XX), hl
ld hl, XX+2
ld (hl), NN ; ret
call XX
...
ORG XX
XX: DS 3
Речь про то, как отличить АБСОЛЮТНО ВСЕ ВЫЗОВЫ, от нужных.Цитата:
Сообщение от caro
Вот как здесь, вручную, да можно. Но можно элементарно ошибиться
и записать код по-старому. Со всеми вытекающими последствиями.
Другое дело, можно создать макросы вида CALL, JP, LD и т.п...
Но это не всякий ассемблер позволит и сложность всей этой
макрообвязки получится сопостовимой с написанием собственного
ассемблера...
Так... :) :( Я уже загруз по уши... Ну, можно доходчиво мне объяснить так, чтоб я сказал: да моя прога, что пишу без этого всего не может - завтра же беру релокации и навороты, вставляю - и благодаря этому архиБыстро и легко доделываю свое произведение...
согласен. но аласм+макросы=hitech-c=ma80=m80=СРЕДСТВО РАЗРАБОТКИЦитата:
Сообщение от fk0
дающее на выходе одно и то же.
а создавать таблицу релокации по двум разным кодам- это еще больший изврат!
гм. интересно, какое из двух слов связки ALASM+macro вызывает приступ аллергии? щаз выясним...
как насчет предложения TASM+macro?
За ma80 не скажу, но вроде там специально ничего не предусмотрено. А с макросами -- тот же ALASM получается.Цитата:
Сообщение от Vitamin
У hitech-c возможности ограничены только созданием таблицы релокации, для настройки кода на адрес, не более того.
А вот у ZASM -- нет ничего. Макросы есть, но ограниченные,
такого не позволяют.
Тем не менее -- оно работает, и оно доступно. Я беру любойЦитата:
а создавать таблицу релокации по двум разным кодам- это еще больший изврат!
ассемблер и элементарно это делаю. Хоть в GENS, хоть в ZASM.
Вот в ZASM и делал, пока на Hitech не перешёл. Но hitech -- это
в писюке (или CP/M). А ZASM -- на спектруме.
ALASM. ИБО ЗАСТАВИТЬ ПИСАТЬ СЕБЯ ТЕКСТ ИСКЛЮЧИТЕЛЬНОЦитата:
гм. интересно, какое из двух слов связки ALASM+macro вызывает приступ аллергии? щаз выясним...
ЗАГЛАВНЫМИ БУКВАМИ, В ИСКЛЮЧИТЕЛЬНО НЕВОЗМОЖНОМ, В ПЛАНЕ "ЮЗАБИЛИТИ" РЕДАКТОРЕ Я СЕБЯ НЕ МОГУ. Потому, что на рядом стоящем писюке есть нормальный редактор. И есть более-менее терпимый в ZASM.
И вопрос отнюдь не в GUI-интерфейса ZASM'a -- в писюке Vim в
xterm.
TASM последний раз видел в 1997 году. Как раз ZASM 3.0 тогдаЦитата:
как насчет предложения TASM+macro?
появился.
а большее разве нужно? какая стоит цель?Цитата:
Сообщение от fk0
на входе: исходный текст программы
на выходе: объектный код, который в идеале можно грузить по любому адресу (с предварительной настройкой соотвецно)
метод реализации: ЛЮБОЙ!!! в том числе и макросы, кросскомпилеры, ручная обработка, сравнение бинарников.
ну уж таким его создал автор изначально. можно попросить алко чтоб сделал поддержку маленьких букв редактором и компилятором (он различает регистр мнемоник).Цитата:
Сообщение от fk0
Цель такова, что вот есть N релоцируемых программ. Мы их загружаемЦитата:
Сообщение от Vitamin
в память, настраиваем, и они каким-то образом начинают вызывать функции друг друга (из других программ, модулей, библиотек). При
том, что до загрузки ничего не известно, что по каким адресам располагается. Существует три, уже 100 раз тут писалось, метода:
1) используя функцию диспетчер, аргументом которой является
"идентификатор функции" в "чужом" программном модуле.
Это так называемый вызов через RST в том числе. Хотя можно
и через CALL, как, например, в CP/M -- CALL 0x05, а в регистре
C -- номер функции. Детали реализации скрываются за
функцией-диспетчером -- поэтому, возможно, это слишком
общий метод и его сравнивать с остальными не совсем
корректно. Но вот тормозной он -- это точно.
2) Прямой вызов. Для этого все CALL, JP, и даже LD HL, xxx и т.п.
должны быть пропатчены в вызывающей программе после
загрузки всех модулей. Требует формирования сложных
таблиц для патчей создаваемых сложной системой макросов
поверх ассемблера, или специальным ассебмлером. Требует
дисковой памяти порядка sum(Ki)+sum(Mi), где Ki -- число
вызовов внешних функций в i-том модуле, а Mj -- общее
число экспортирующихся функций в j-том модуле. Памяти
ОЗУ после настройки не требует. Но Ki -- достаточно велико.
3) Вызов через функцию-перенаправитель. Для каждой функции
из вызываемого модуля в вызывающий модуль ещё на этапе
компиляции включается специальная функция, состоящая
из одной команды JP xxx. Все вызовы к функциям "чужого"
модуля адресуются к этим функциям-перенаправителям.
А сами функции-перенаправители патчатся, после загрузки,
так, чтобы инструкция JP xxx указвала на действительный адрес
функции из вызываемого модуля. Данный способ отличается
от предыдущего тем, что вызов тормозней на 10 тактов и
памяти ОЗУ требует порядка sum(Mi)+sum(Nj), где Mi -- общее
число экспортируемых функций в каждом i-том вызываемом
модуле, Nj -- число внешних вызываемых функций в каждом
j-том вызывающем модуле.
Считаю, способ N3 наиболее перспективный. Он позволяет относительно легко в любом ассемблере получить нужный код,
он не накладывает чрезмерных накладных расходов на совершения
вызова функций, не требует много памяти как дисковой, так и ОЗУ.
Хотя по использованию ОЗУ он, проигрывает остальным методам.
Со способом N2 сравнивать бесполезно (0 байт), против способа
N1 проигрыш составляет порядка трёх байт на каждую вызываемую
внешнюю функцию в каждом модуле. При общем числе функций
порядка десятков, максимум сотни-другой, это вполне допустимый,
с моей точки зрения, расход памяти.
Способ N2 исключительно сложен в реализации, и требует
специальной поддержки от ассемблера, поэтому, с моей точки
зрения, в общем случае не применим и имеет смысл в каких-то
специфических случаях, например, когда исключительно критично
время вызова функции.
Способ N1 даёт слишком большие накладные расходы на вызов
функий и поэтому, аналогично, имеет смысл, опять же с моей точки
зрения, исключительно в специфических ситуациях. Например,
где время некритично, но очень критичен объём занимаемой
программной памяти.
Короче что-то мы отвлеклись от темы и полезли в дебри.
Надо уже что-то начинать.
Давайте откроем отдельную тему и назначим координатора, который прислушиваясь к мнению остальных будет выбирать из множества решений некоторое одно.
И остальные будут руководствоваться решениями координатора (иначе не будет никакой коллективной работы).
Если вы ещё с нами, тогда вперёд, иначе не вперёд ^_~
Для начала выберем координатора. Предлагайте кандидатуры, а CityAceE пескай выберет кого- нибудь одного.
1) Я. Много писал (и сейчас пишу ^_~) на спектруме. Наиболее известное - TargeT. Шарю в написании больших проектов (правда не на спеке, но думаю опыт пригодится).
Я за твою кандидатуру. Ведь дело даже не в опыте, хотя он безусловно очень важен, а ещё и в заинтересованности (увлеченности)...Цитата:
Сообщение от Sinus
Тебе начинать хоть прямо сейчас никто не мешает, не думал?Цитата:
Сообщение от Sinus
Для этого не нужно ровно ничего.
Иными словами давайте поиграем в коммунизм. Я против коммунизма. Он даёт исключительно советские решения на выходе.Цитата:
Давайте откроем отдельную тему и назначим координатора, который прислушиваясь к мнению остальных будет выбирать
Вот этого я и боюсь. Одно, исключительно советское в худшемЦитата:
из множества решений некоторое одно.
смысле этого слова: ни с чем не совместимое, и исключительно горбатое. И избавиться от него потом ну никак нельзя будет.
Ключевое слово *ОДНО*. Я бы предоставил свободу выбора
авторам программ. По крайней мере можно было бы посмотреть
какое решение приживётся эволюционным путём, а не посредством
насаживания свыше. Другое дело -- совместимость. Хотелось бы
иметь некий базовый уровень, от которого могли бы происходить
вариации по разным направлениям, но так чтобы тем или иным способом была возможность преобразования интерфейса к нужному
виду. Хотелось бы отделить интерфейс вообще от деталей его
реализации.
Вот возьми и напиши. Не в ассемблере, а свое видение проблемы организации программных интерфейсив, их несовместимости и возможности преобразования из несовместимых в совместимые,Цитата:
1) Я. Много писал (и сейчас пишу ^_~) на спектруме. Наиболее известное - TargeT. Шарю в написании больших проектов (правда не на спеке, но думаю опыт пригодится).
и наконец проблемы идентификации интерфейсов.
свои проекты я делаю и никого не спрашиваю.Цитата:
Сообщение от fk0
сам по себе ZX SDK мне не нужен. для работы я использую свои наработки, и мне их достаточно.
мне интересен сам процесс.
никто не заставляет.Цитата:
Иными словами давайте поиграем в коммунизм. Я против коммунизма. Он даёт исключительно советские решения на выходе.
тогда ничего не получится. если предоставить свободу выбора, то можно смело закрывать проект прямо сейчас, ибо результата не будет.Цитата:
Вот этого я и боюсь. Одно, исключительно советское в худшем
смысле этого слова: ни с чем не совместимое, и исключительно горбатое. И избавиться от него потом ну никак нельзя будет.
Ключевое слово *ОДНО*. Я бы предоставил свободу выбора
авторам программ.
у меня нет лишних 20-ти лет на эксперименты.Цитата:
По крайней мере можно было бы посмотреть
какое решение приживётся эволюционным путём, а не посредством
насаживания свыше.
если будут всякие преобразования, это значит мниго лишней писанины. а если с ZX SDK писать придётся ещё больше чем без него, то значит он не нужен.Цитата:
Другое дело -- совместимость. Хотелось бы
иметь некий базовый уровень, от которого могли бы происходить
вариации по разным направлениям, но так чтобы тем или иным способом была возможность преобразования интерфейса к нужному
виду.
да... ООП и другие умные слова.Цитата:
Хотелось бы отделить интерфейс вообще от деталей его
реализации.
это всё тормоза. если надо тормозоть, то возьми себе пэцэ. и gcc. и g++. и отделяй интерфейсы в абстрактных классах от реализации. и никого не спрашивай.
Описывать проблемы можно 8 лет. А надо делом заниматься.Цитата:
Вот возьми и напиши. Не в ассемблере, а свое видение проблемы организации программных интерфейсив, их несовместимости и возможности преобразования из несовместимых в совместимые,
и наконец проблемы идентификации интерфейсов.
[QUOTE=Sinus]свои проекты я делаю и никого не спрашиваю.
сам по себе ZX SDK мне не нужен. для работы я использую свои наработки, и мне их достаточно.
То-есть конечный результат не важен.Цитата:
мне интересен сам процесс.
Всем (пионерам) известно -- в колхозы никого не заставляли.Цитата:
никто не заставляет.
Отсутствие результата -- тоже результат. А будет он или не ещёЦитата:
тогда ничего не получится. если предоставить свободу выбора, то можно смело закрывать проект прямо сейчас, ибо результата не будет.
вопрос. Мы имеем примеры как и в случае наличия таковой свободы
и при её отсутствии результаты получались самые разные. Есть
шанс, что будет. И это ещё зависит от того, что именно считать результатом. В конечном счёте это зависит от конкретных людей
(тебе -- никто не мешает...)
А лишнее время на бессмысленный "процесс" стало быть есть?Цитата:
у меня нет лишних 20-ти лет на эксперименты.
Это неизвестно больше или нет. Возможно больше, но не фактЦитата:
если будут всякие преобразования, это значит мниго лишней писанины. а если с ZX SDK писать придётся ещё больше чем без него, то значит он не нужен.
что намного. Нужно хотя бы иметь возможность оценить насколько.
Можно взять, например, модульную систему (C) Vitamin и мою, и
посмотреть, больше будет или нет.
Я так думаю, это тебе взять что-ли пэцэ, g++, позаниматься делом...Цитата:
да... ООП и другие умные слова.
это всё тормоза. если надо тормозоть, то возьми себе пэцэ. и gcc. и g++. и отделяй интерфейсы в абстрактных классах от реализации. и никого не спрашивай.
Описывать проблемы можно 8 лет. А надо делом заниматься.
А когда энтузиазма поубавится, уже за что-то браться. Просто иначе
получается -- тут говорят делом надо заниматься, а каким именно делом никто не может толком определиться. Каков результат-то должен быть? Ответь хоть бы для себя на этот вопрос, сформулируй задачу себе. Я вот за себя могу сказать: Я ОТВЕТА НА ЭТОТ ВОПРОС
НЕ ЗНАЮ. И ПОИСК ОТВЕТА НА ЭТОТ ВОПРОС -- ЭТО ЛИШЬ ПЕРВЫЙ
МАЛЮСЕНЬКИЙ ШАЖОК В ОЧЕНЬ ДЛИННОЙ ДОРОГЕ, где писать какой-код -- самый последний, завершающий шаг.
Ну и в итоге ? Поругались ? А результаты?
А результаты несколькими страницами выше. Рассмотрены самые разные варианты, их плюсы и минусы, личные предпочтения.Цитата:
Сообщение от Знахарь
Имхо, zx sdk должно существовать в виде исходников, причем в текстовом виде и безо всяких специфичных для каждого ассемблера штук. Плюс документация. А уж обертку для вызова каждый напишет сам...
т.е. когда нечего сказать, надо переходить на личности и нести бред не по теме.Цитата:
Сообщение от fk0
на бессмысленный нет. если будет результат (на что я надеюсь) то есть.Цитата:
А лишнее время на бессмысленный "процесс" стало быть есть?
модульная система это несколько не в тему. модули нужны тогда когда они нужны. допустим драйвера для HDD, CD-ROM и т.д.Цитата:
Это неизвестно больше или нет. Возможно больше, но не факт
что намного. Нужно хотя бы иметь возможность оценить насколько.
Можно взять, например, модульную систему (C) Vitamin и мою, и
посмотреть, больше будет или нет.
а в данном случае динамически загружаемые модули не нужны.
да я вроде как бы работаю. правда опенсорсовой фигнёй в линухе не страдаю и пишем мы под нормальные оси (виндовс)Цитата:
Я так думаю, это тебе взять что-ли пэцэ, g++, позаниматься делом...
когда энтузиазма поубавится, бесплатно я делать ничего не буду ^_~Цитата:
А когда энтузиазма поубавится, уже за что-то браться.
я уже писал (на первых страницах), каким я хочу видеть ZX SDK.Цитата:
Просто иначе получается -- тут говорят делом надо заниматься, а каким именно делом никто не может толком определиться. Каков результат-то должен быть? Ответь хоть бы для себя на этот вопрос, сформулируй задачу себе.
могу сформулировать ещё раз.
Как уже говорил Витамин, результаты вроде как есть.Цитата:
Сообщение от Знахарь
Но они такие... Как бы никакие. С чем пришли с тем и ушли.
Т.е. отсутствие результата - тоже результат ???
По словам Витамина: каждый желающий выкладывает свою процедурку с подробным описанием и всё. А координатор смотрит - куда ее пристроить / была / не была и тп. Я правильно понял ?
Что ж выходит по словам Синуса ? Не то же ?
Выходит что так.Цитата:
Сообщение от Знахарь
вроде как так. только по моему мнению координатор в таком случае не нужен, ибо была / не была чел в состоянии и сам посмотреть, а куда пристраивать если нет системы? тоже некуда. лучше уж на opensource.zx или как там он называется в таком случае сорс выложить.Цитата:
По словам Витамина: каждый желающий выкладывает свою процедурку с подробным описанием и всё. А координатор смотрит - куда ее пристроить / была / не была и тп. Я правильно понял ?
почти. только нужно в начале определить систему. ну а потом вперёд.Цитата:
Что ж выходит по словам Синуса ? Не то же ?
Да, но на openSource нет детальных доков к исходникам :( Да вообще доков нет. А тут и начинается "мне проще/быстрее самому написать, чем в чужом разбираться"... поэтому давайте "определять систему", что-ли ???
Предлагаю составить иерархическую структуру исходников с процедурами (думаю именно они будут востребованы, исходники прог целиком лежат на opensource)Цитата:
Сообщение от Sinus