Важная информация

User Tag List

Страница 1 из 9 12345 ... ПоследняяПоследняя
Показано с 1 по 10 из 87

Тема: Скрестить ZX и ПЦ

  1. #1
    Master Аватар для Oleg N. Cher
    Регистрация
    24.08.2007
    Адрес
    Днепропетровская обл.
    Сообщений
    759
    Благодарностей: 207
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию Скрестить ZX и ПЦ

    Скрестить ZX и ПЦ

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

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

    Код:
    если асм_zx, то ld a,b
    если асм_pc, то mov al,bl
    если яву, то a := b
    Третья строка - это наш выход на современные реалии бытия. Тут была масса претензий к качеству кода, выдаваемому SDCC. Но, господа, SDCC вовсе не отбирает у вас хлеб лоулевел кодера. Он только подставляет плечо. А кодировать вручную вы можете и в ZXDev. Та даже код на ЯВУ даёт очень много лазеек для его ручной оптимизации. Помните REPEAT UNTIL? Это всего лишь соптимизированный FOR. До оптимизации этот код занимал у меня 560 байт. После оптимизации - 500 (львиная доля из них - быстрая процедура рисования окружности), и это не предел. Я уверен, что если вывести переменную radius из процедуры на уровень модуля, она перестанет быть локальной, и код уже будет другой, и пооптимальнее. Да, наглядности это коду не добавит, но для оптимизации такое сделать можно. Можно скрестить все эти PAPER, INK, BRIGHT и FLASH в одну процедуру COLOR. И так далее.

    Структурно-модульный уровень - логика кода на ЯВУ + библиотеки на асме (или на ЯВУ - там, где это уместно). Я скажу очень важную вещь, сосредоточьтесь. Как, по-вашему, что нужно сделать чтобы этот код заработал на другой платформе?

    Всё просто. Есть два способа. Первый: переписать код под API (программные интерфейсы) другой платформы (а обычно - и на другой язык). Второй: эмулировать операторы ZX-Basic и Laser Basic на этой платформе, со структурой экрана и памяти (чтобы POKE работал). Какой способ вам нравится больше? Мне - ни один из них в чистом виде. Нет. Здесь нужна декомпозиция. Нужно проделать очень серьёзную работу по пересмотру абстракций, положенных в основу алгоритмов. Чем заменить PAPER и INK? Завести коды цветов как у экрана Спектрума или как-то иначе сделать? Это трудная работа, но если выйти на новый уровень абстракций, спроектировать новый интерфейс логики работы с экраном, клавиатурой, звуком, то мы получим уже нечто третье, а не два вышеперечисленных способа в чистом виде. Попробуем усложнить задачу ещё круче. Пусть выработанные нами интерфейсы будут реализованы в едином стиле для разных платформ, для начала пускай хотя бы для двух. Чувствуете какая здесь кроется мощь?

    Ещё язык программирования. Неплохо конечно использовать привычный язык, но он вряд ли будет одинаково хорош для Android и для ZX. Проект XDev ставит перед собой ещё более серьёзную задачу: пусть у нас будет средство, позволяющее развернуть нашу игру и на ZX - она будет выглядеть поскромнее; и на Android - хотя бы и управление отличается, сенсор вместо клавы с джойстиком. Но логика работы над вашим проектом остаётся, открытая, доступная для дальнейшей модификации. С долей презрения к не появившимся ещё гаджетам и платформам. ;-)

    Вы видели декомпилированный Exolon? Его нужно переписать в этом же духе, иначе через несколько лет у кого-то снова может появиться очень интересная головоломка "узнать как это устроено?". Я не хочу ломать кайф кому-то, но сколько же можно топтаться на одном месте. Видите как резво сменяются парки платформ? Или вы глубоко в эмуле ZX/любимой IDE C# и вам на всё пофиг? Но мне-то нет. И моим единомышленникам.

    Проблемы "скрещивания" кроются в том, что не всегда правильно расставляются акценты при разработке. Берутся не всегда адекватные абстракции. Игнорируется модульность. Вот, например, я бы поставил высокий удельный вес понятию спрайт (картинка на экране), при этом цветность, выравнивание по сеточке из атрибутов - уже понятия меньшего удельного веса. Язык - ещё меньше веса. Платформа - ещё меньше веса. Тогда получится программа, выводящая спрайт. А во что она превратится после нажатия на Compile - это уже второстепенно. У нас же сейчас всё иначе. Главные скрипки и трубы - платформы, процессоры и языки. А наши скромные приложения - они имеют насколько ничтожный вес, что быстро устаревают и становятся никому не нужными. У нас всё с ног на голову. Вместо того чтобы всем миром прийти к единой нотации - каждый городит свой идеальный язык. Вместо стандартизации единого апи (пусть даже этот апи будет разной мощности; и как матрёшка, совместимый сверху-вниз - для разворачивания на платформах разной мощности) - опять чёртова куча платформ, и не видно этому конца-краю. Кто-то с этим мирится и делает ZXTune для десятка платформ. Ну что ж, очень круто, молодец. А что остальным делать? ;-) У кого барьеры овладения технологий. Кто, начав с ZX-Basic, пошёл по пути QuickBasic, потом PureBasic, потом VisualBasic, потом BlitzBasic/Monkey-X. И невдомёк ему, что его мучают демоны названия языка. Это не бейсик, это много бейсиков. ;-) А В XDev язык построен по принципу матрёшек апи, как я сказал выше, чтобы разворачивать его на платформах различной мощности. Но это единый язык или в лучшем случае очень близкие диалекты, но не целый парк языков, похожих друг на друга разве что общим названем. Об этом можно долго говорить.

    Примерами кода подкреплю позже, если не возражаете.
    Последний раз редактировалось Oleg N. Cher; 17.12.2014 в 03:47.

  2. Этот пользователь поблагодарил Oleg N. Cher за это полезное сообщение:
    Reobne (17.12.2014)

  3. #1
    С любовью к вам, Yandex.Direct
    Размещение рекламы на форуме способствует его дальнейшему развитию

  4. #2
    Veteran Аватар для Destr
    Регистрация
    26.03.2008
    Адрес
    Питкяранта
    Сообщений
    1,426
    Благодарностей: 643
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Oleg N. Cher Посмотреть сообщение
    Примерами кода подкреплю позже, если не возражаете.
    Давай-давай!
    Не возражаем!
    (с) Афоня (ну почти)

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

  5. #3
    Master Аватар для Oleg N. Cher
    Регистрация
    24.08.2007
    Адрес
    Днепропетровская обл.
    Сообщений
    759
    Благодарностей: 207
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Destr Посмотреть сообщение
    А вообще мне порой кажется что тебе, старина приплачивают за продвижение этого XDev
    Просто инструмент хороший. Универсального применения. Но недооценённый. Но я вам покажу кузькину мать, т.е. как из него верёвки вьются. Да, жаль только, что кавычки выкусить препроцессором, похоже, нельзя. Поэтому придётся перекодировать команды асма в циферки ручками, и пока не знаю как сделать лучше этого:
    Код:
    MODULE TestAsm;
    IMPORT Asm;
    
    (* Set graph mode 320x200, 4 colors (CGA, EGA, VGA & SVGA) *)
    PROCEDURE SetGraxMode* ;
    BEGIN
      Asm.Byte5(
        0B8H, 4, 0, (* MOV  AX, 0004H *)
        0CDH, 10H   (* INT  10H       *)
      );
    END SetGraxMode;
    
    (* Set text mode 80x25 *)
    PROCEDURE SetTextMode* ;
    BEGIN
      Asm.Byte5(
        0B8H, 3, 0, (* MOV  AX, 0003H *)
        0CDH, 10H   (* INT  10H       *)
      );
    END SetTextMode;
    
    BEGIN (*$MAIN*)
      SetGraxMode;
      SetTextMode;
    END TestAsm.
    Eщё про миграцию языков скажу. Как я заметил, многие люди, пользуясь своей любовью к бейсику (похвально, и мне это счастье знакомо, только вот ZXDev будет покруче, чем MCoder2; притом практически во всём; что же изменилось, что тогда было счастье, а теперь его нет? ;-) ), иногда доходят от ZX-Basic даже до Monkey-X. Но парк бейсиков обширен и разномастен, допустим, если выстроить иерархию бейсик-языков, будет:

    ZXBasic/Laser/MegaBasic -> GWbasic/QuickBasic/TurboBasic -> VisualBasic -> FreeBasic/PureBasic -> Blitz/Monkey-X

    Можно такую же иерархию выстроить для Си:

    Hisoft C -> Turbo C/Quick C -> Borland C++/Visual C++ -> GCC -> Objective C ?

    Или Паскаля:

    Hisoft Pascal -> Turbo Pascal -> Delphi -> FreePascal

    Они не просто переносят одни и те же возможности из одной инкарнации в другую. Языки изменяются. Причём бейсики - больше всего. Также они усложняются, обростая деталями как снежным комом, но оставляя прикреплённость к платформе. Хотя, пожалуй, у FreePascal и GCC с этим всё хорошо, их устаревшесть и проблемы лежат в той плоскости, что подкапываются под саму их основу - их начинают заменять скриптовыми языками и виртуальными платформами, чётко отделяя мух от котлет - "опасный" натив от "безопасного управляемого кода" (ага! а в Обероне всё это есть с самого начала!), т.е. им как бы уже и нету места, в любом случае, удельный вес этих "старых" языков снижается (GCC на плаву во многом благодаря Linux'у; ObjC/LLVM - благодаря MacOS и "яблочным" технологиям). Оберон-языки особняком, но там удалось выстроить такую парадигму, что, выпуская новые диалекты с новыми возможностями, можно медленно мигрировать, уходя от устаревших опасных и ненужных возможностей. Парадигма "старых" Паскаля и Си не смогла избавиться ни от "опасного" кода, ни от рудиментов. Всё из тех же соображений совместимости.

    Также заметим миграцию платформ. Со спека (8080 или CP/M) на дос, это если не считать Amiga, потом UNIX, виндоус и, наконец, уже мультиплатформа, но без гаджетов, потом - уже гаджеты и прочее, но старые платформы утеряны. XDev оставляет нам их, если уж нам так нужно. Но XDev построен на том же принципе, что и Monkey-X с его mojo. При всех недостатках - не нужно знать десяток языков и два десятка апи. Для инди-разработчика самый рай. Разве неинтересное направление? Уже всяко интереснее, чем просто на асме кодить ИМХО.

  6. #4
    Veteran Аватар для Destr
    Регистрация
    26.03.2008
    Адрес
    Питкяранта
    Сообщений
    1,426
    Благодарностей: 643
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Oleg N. Cher Посмотреть сообщение
    Поэтому придётся перекодировать команды асма в циферки ручками, и пока не знаю как сделать лучше этого:
    А макросы там нельзя разве?

  7. #5
    Доктор Аватар для Kakos_nonos
    Регистрация
    26.12.2010
    Адрес
    Кубань
    Сообщений
    1,078
    Благодарностей: 818
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    А есть книга про программирование на обероне для ZX-а? Или большая статья, чтоб человек, совсем не знающий оберона мог разобраться и начать кодить?
    нефть.

  8. Этот пользователь поблагодарил Kakos_nonos за это полезное сообщение:
    Reobne (17.12.2014)

  9. #6
    Veteran Аватар для bigral
    Регистрация
    12.07.2006
    Адрес
    Kiev/Ukraine
    Сообщений
    1,462
    Благодарностей: 265
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Такие кучи текста ниачем пожалуй токо Blackcat на форуме писал да и то было это давно и неправда. О чем тут разговор?

    Основная ж проблема в том что 99% алгоритмов разработанны для некой виртуальной машины с неограниченным адресным пространством а зачастую еще и стек тоже бесконечной глубины подразумевается.

    В ПЕЦЕ режимов памяти - DOS16, FLAT32, FLAT64 и все они намного жирнее чем спекки-48 или страничные спекки-128/256/512/1024/2048/4096. Без переделки алгоритмов на использование мелких (до 16кб) структур данных вообще НИКАК. Так что это нетривиальная ручная работа, научиться которой можно только на примере уже выполненных конкретных примеров.

    Я как-то взял сорцы digger-a (там на С + графика на ASM под DOS16 com-file, 1 segment кода, модель tiny) и пытался компильнуть БЕЗ ГРАФИКИ используя sdcc, не помню чего я забросил это дело, но по-моему потому что в 16кб кода и данных там не влазил какой-то довольно сложный по логике кусок, который надо было разбивать а разбираться в его работе желания небыло.

    Вот бы какой-то крутой программер разбил бы эти сорцы на куски и показал бы как можно из исходника под DOS16 сделать исходник для ZX-a

  10. Этот пользователь поблагодарил bigral за это полезное сообщение:
    jerri (17.12.2014)

  11. #7
    Master Аватар для Oleg N. Cher
    Регистрация
    24.08.2007
    Адрес
    Днепропетровская обл.
    Сообщений
    759
    Благодарностей: 207
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    bigral, это не "ниачём", это ты на другой частоте вибрируешь и с этими идеями в резонанс не входишь. Что ты там за чепуху хотел прокрутить с Дигером - я не знаю, и чем там крутому программеру заниматься - яйца выеденного не стоит. Я на этой частоте не вибрирую. ;-) Я вообще нигде не предлагал переписывать бинари с винды под ZX или исходники DOS16 под ZX. Это к Destr'у. Всё от извращённых желаний скрестить нескрещиваемое, например, родить "Java для ZX". Или "идеальную ОС для Спека с памятью в 16 кб " ;-) Но подобные вопросы здешний народ очень волнуют. Впрочем, Destr хочет разработать графический движок для Спека, и наверное способом Трамплина можно действовать.

    Нельзя да и не нужно добиваться бинарной совместимости DOS16 и ZX. Ни абсолютной, ни относительной. Эта светлая мысль разлетается от простейших вещей, например, таких как сегменты. Действовать надо иначе и с другой стороны. И если ты пробьёшься сквозь мои рассуждения и увидишь в них соль, поймёшь что конкретно я предлагаю - то очень обрадуешься. Почему другие довольствуются ограниченными и устаревшими средствами разработки - такими как ZXBasic, Трамплин или MCoder2 - я не знаю, наверное дело привычки. Как мозги у человека устроены - такое средство ему и нравится.

    Но я бы с удовольствием послушал каким ты видишь средство разработки, позволяющее скрестить ZX и Android. А то ты такой суровый чел, что говоришь только "ачёмта чиста канкретном пацаны". ;-) Да, и надеюсь, что это будет не эмулятор FUSE. Вот Java на ZX - это да, конкретная и чоткая идея, заслуживающая уважения и обсуждения. Сдержанных оваций и молчаливого одобрения. А вот то что я предлагаю - это чухня, да...

    Цитата Сообщение от Kakos_nonos Посмотреть сообщение
    А есть книга про программирование на обероне для ZX-а? Или большая статья, чтоб человек, совсем не знающий оберона мог разобраться и начать кодить?
    Есть форум, куда можно прийти, почитать, прочувствовать. Ссылка в подписи. Я могу для удобства сшить эти форумные сообщения в PDF'ку, но это конечно будет ненастоящая книга. Писать настоящую - не планирую. Хотя не стоит огорчаться, вряд ли она бы у меня получилась. Тут лучшая книга - работа с готовыми примерами. Несколько маленьких игр я на Оберон портировал. Можно начать с их изучения и модификации.

    Я понимаю зияющую брешь в документации по ZXDev, однако я очень надеялся что вы поможете мне написать её. Хотя бы FAQ для начала.

    ---------- Post added at 23:59 ---------- Previous post was at 23:31 ----------

    Как повысить удельный вес алгоритма, который для нас, допустим, значимее, чем используемая для его разворачивания платформа? Очевидно, что вавилонское столпотворение языков программирования - неизбежная данность, поэтому нам нужна единая нотация, которая избавит нас от необходимости изучать нынешние и текущие языковые ухищрения. Нужно сделать ставку на что-то одно, потому что ставку на что-то делать всё равно приходится. Но это одно должно быть достойным того, чтобы на него ставить. Нам услужливо пододвигают C#/Java, и мы постепенно становимся рабами даже не этих языков, а этих платформ. Попытка развёрнутой объективной дискуссии на эту тему с явистами и шарпаками абсолютно бессмысленна - задавят массой. Ну да, они это недостатком не считают. Но заметим в уме необходимость синтеза проверенной временем процедурной парадигмы с новыми платформами.

    Monkey-X - пример такой единой нотации. Он вырос из Бейсик-мира, и ушки его торчат оттуда. Мне лично очень приятно, что он не получил сишного влияния. А для кого-то это недостаток. Ну ещё бы, Си ведь круче тучи. Как и асм. Да, круче, но на своём месте - в системном программировании. Но значимость Си в последнее время снижается. Для веб-программирования Си используется очень мало. Для разработки под гаджеты - мало. В XDev языки Си и асм - каждый на своём месте. Как колёса для телеги. Там, где в этом есть смысл, они юзаются. XDev по задумке своей - квинтэссенция лучшего из Бейсик-мира, Паскаль-мира и Си-мира. Позвольте я опишу вам своё видение этого. Из Си-мира XDev берёт высокую кроссплатформенность результатов, возможность использовать в качестве кодогенераторов готовые оптимизирующие компиляторы, возможность подключить к своим разработкам код и готовые библиотеки на Си, низкоуровневые системные фишки. Из Паскаль-мира XDev взял строгость, наглядность внешнего вида кода, удобство чтения и модификации, модульность. Т.е. мы синтезировали удачный вид Паскаль-кода и эффективную сборку его сишными компиляторами. Обратите внимание, что все три линии (Бейсик, Си, Паскаль) начинали скромненько, но в итоге пришли к кроссплатформенности и мультитаргетности (GCC, FreePascal, PureBasic/Monkey-X). Самым интересным для меня является Monkey-X. Благодаря своему подходу Monkey-X в случае если вы сделаете на него ставку даёт вам возможность с единого исходника делать игры для целой кучи платформ, а с помощью его единой нотации избавляет от необходимости изучать ActionScript, Java, C, C++, Objective C. Т.е. Monkey-X не запрещает вам знать эти языки, да и ограничений у него более чем достаточно. Но зато подход верный. Я бы в итоге предпочёл вместо массы языков программирования иметь нотацию номер один с возможностью варьировать её синтаксис (Бейсик, Паскаль или Си) и семантический набор (процедуры или методы; или то и другое; и т.д.). Нам нужно выйти из концепции языков программирования вообще. Над подобными вещами уже задумывались. Например, профессор Андрей Петрович Ершов с его «Лексиконом». Погуглите, если интересно.
    Последний раз редактировалось Oleg N. Cher; 18.12.2014 в 00:41.

  12. Этот пользователь поблагодарил Oleg N. Cher за это полезное сообщение:
    Warlockus (18.12.2014)

  13. #8
    Vitamin C++ Аватар для Vitamin
    Регистрация
    14.01.2005
    Адрес
    Таганрог, Россия
    Сообщений
    4,031
    Благодарностей: 1426
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Oleg N. Cher Посмотреть сообщение
    Вместо того чтобы всем миром прийти к единой нотации - каждый городит свой идеальный язык.
    А ничего, что единая (сиречь универсальная) нотация- это и есть "идеальный" язык в твоей терминологии?

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

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

  14. Этот пользователь поблагодарил Vitamin за это полезное сообщение:
    denpopov (18.12.2014)

  15. #9
    Veteran Аватар для Destr
    Регистрация
    26.03.2008
    Адрес
    Питкяранта
    Сообщений
    1,426
    Благодарностей: 643
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Vitamin, как жёстко ты браза...

    ---------- Post added at 10:29 ---------- Previous post was at 10:29 ----------

    Не убивай в человеке светлое-хорошее, что-ли...

  16. #10
    Vitamin C++ Аватар для Vitamin
    Регистрация
    14.01.2005
    Адрес
    Таганрог, Россия
    Сообщений
    4,031
    Благодарностей: 1426
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Destr Посмотреть сообщение
    Vitamin, как жёстко ты браза...
    Не убивай в человеке светлое-хорошее, что-ли...
    В чем жесткость-то? В озвучивании прописных истин?

Страница 1 из 9 12345 ... ПоследняяПоследняя

Информация о теме

Пользователи, просматривающие эту тему

Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •