Компилировать и копировать уже пробовал - не понравилось...
Убрал блоки _flag_attr_sprite, стало совсем хорошо. Теперь надо перенести SpritePutAnd(), SpritePutOr(), и карту, и будет вообще красиво
Компилировать и копировать уже пробовал - не понравилось...
Убрал блоки _flag_attr_sprite, стало совсем хорошо. Теперь надо перенести SpritePutAnd(), SpritePutOr(), и карту, и будет вообще красиво
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Утопичная, потому что "нас, ностальжат, мало, и у каждого самая правильная тельняшка. И полное желание контролировать абсолютно все аспекты проекта. И нежелание делать неинтересную работу, откладывая на вечное "потом".Сообщение от Andrew771
И поэтому нас есть сейчас два эмммм... средненьких... компилятора Паскаля для Z80. Вместо одного хорошего.
Бывают и другие расклады, Free Pascal вот. Он если не под всё, то много под что.
- - - Добавлено - - -
Не умеем работать вместе, господа, не умеем. Даже если идеи схожие. Честно себе признайтесь.
Free Pascal хорош, есть под много что, но пусть он там и будет. Внутрь я заглядывал лет 5 назад, там тихий ужас. Если они продолжают его писать так же, то пусть пишут. Человек со стороны вряд ли разберётся в том коде, а на письма авторы не отвечали.
Да, работать вместе "не умеем".
Мне вот сейчас очень не хватает тестов. Простых программ, которые будут проверять пограничные случаи. Да ту же арифметику прогнать и убедиться что умножение и деление работает корректно. Кто-нибудь будет их писать? Кто-нибудь будет писать графические библиотеки? Или вот сегодня напоролся на очень неоднозначную ситуацию, кто-нибудь готов думать как из этого выкручиваться или почитать спецификацию и сказать "там на 628-й странице это описано"?
Нет, люди будут ждать готовую Visual Delphi IDE for Z80 с кнопкой "сделай мне хорошо", и чтобы это хорошо было лучше чем на ассемблере.
Oleg N. Cher, а как ты представляешь объединение двух "эмммм... средненьких..." компиляторов в один хороший? При том что один компилятор является отдельным диалектом, мало с чем совместимым, а другой компилятор в идеале планируется довести до способности сборки самого себя, и даже может того же FPC. (кстати, сам себя на x86 он уже почти собирает)
Bolt, абсолютно верная постановка вопроса. Никто ничего делать не будет. Максимум - дадут совет. Или сделают что-то для себя. То есть все может и хотят объединиться, но только вокруг своего проекта.
При всех недостатках внутреннего устройства Free Pascal это большой и хороший проект, который уже довели до вполне стабильного состояния. И имеющий много пользователей. В своё время я очень просил Андрея Andrew771 открыть исходники его ZX-Like Pascal. Всё-таки открытый проект воспринимается приятнее. И есть, может быть, тайная надежда, что кто-то присоединится. Но сейчас Андрей наверняка может прибавить пять копеек и сказать, что это не имело смысла. Никто ничего на уровне исходников компилятора не делал. Максимум - ковырялись в Спектрум-рантайме.
Думаю, самое умное, что я скажу в этом посте, понимайте как хотите, это будет такая идея. Хорошо бы создать компилятор (Паскаля или Си), однотаргетный или мультитаргетный, но с возможностью описывать оптимизацию кода на каком-то внутреннем языке/скрипте. Чтобы человек, которого не устраивает конкретно тот или иной код, мог поучаствовать в написании правила оптимизации. И чтобы это было просто. Приблизительный аналог - peephole-оптимизатор, использованный в SDCC, который команда z88dk сумела снабдить набором расширенных правил, получив ZSDCC. Только такой подход мне кажется разумным в условиях, когда проект ведётся одним разработчиком, пускай даже ему все кричат "давай-давай!", а кто-то даже чем-то помогает.
Вот так и представляю. Но тут нужно переосмысление "кирпичиков" оптимизации.
Пожалуй, всё-таки недо-Си в стиле Sphinx C-- или даже PL/M для Z80 будет более реалистичным проектом, чем Си/Паскаль. Именно по качеству выхлопа, т.е. не по количеству полученного от проекта удовольствия, а по качеству получившегося в итоге инструмента. Дискуссабельно.
P.S. Bolt, ну а Вы ZXDev хоть щупали? Что в нём конкретно настолько не так, что надо пилить другой компилятор? Просто интересно. Язык не тот?)
Да, язык не тот ) ZXDev, насколько помню, транслирует Оберон в Си? Вот поэтому оно и не то. Возможно, я отстал от жизни, но 7 лет назад основной целью было никак не касаться Си. На то было причины.
Понимайте как хотите, но я не хочу продолжать это обсуждение. Кто хочет поучаствовать - на генерации кода и оптимизации свет клином не упёрся, есть ещё RTL и тесты.
Погоня за качеством вещь хорошая, но "так сложились обстоятельства" (с), что вся моя жизнь превратилась в погоню за результатом и "повышение качества жизни" (с) любой ценой. Всё, от чего я получал удовольствие, было отодвинуто на десятый план, потому что "перед нами стоит задача, нам необходимо принять ответственное решение" (с). Мне не понравилось. Теперь у меня приоритет на получение удовольствия, а качество продукта приложится.
Последний раз редактировалось Bolt; 26.04.2018 в 07:52.
Скорее всего, есть еще проблема с адресом виртуального экрана. Он у меня размещается в конце ОЗУ перед стеком, адрес жестко задан. Тебе нужно переопределелить его.
Bolt пока еще создает компилятор, причем близкий к спецификации "настоящего" Паскаля, так что всё впереди. Я, если так можно выразиться, в помощниках - предоставил библиотеку процедур. А также хотел бы по оптимизации помочь. Если Z_demo скомпилится полностью в 48к и будет работать на нормальной скорости, то можно ZX Like Pascal забросить.
Там проблем нет. Проблема есть в другом.
Выражение вида "A<(B-C)". Если B и C имеют размер 8 или 16 бит, то всё просто. Но если B, например, longword, то выражение в скобках signed или нет? Потому что сравнения cmp_us и cmp_uu дадут разный результат и я пока не знаю как правильно. На чём и споткнулся (http://zx-pk.ru/threads/24967-zx-lik...l=1#post961254).
о5 нам впаривают Оберон. Было, не?
Мне вот что интересно: когда не получается алгоритм, я скармливаю исходник Hitech C, потом смотрю на бинарник.
Выйдет ли что-то вменяемое из вышеупомянутых средств разработки? Наверное, ничего.
Но ведь оптимизация - это самое главное для разработки на Z80. Удовольствие само собой, но от разработки тестов оно сомнительно)
Трансляция в Си - компромисс, чтобы не заниматься оптимизацией и кодогенерацией. А сосредоточиться на рантайме. Кстати, библиотеки некоторые в ZXDev имеются, в т.ч. и графические, советую ознакомиться.
- - - Добавлено - - -
Ну вот, грустно всё это. А я предлагал тебе не сосредотачиваться на исключительно Z80, помнишь?)
Тебе впаришь. Было ещё когда ты был DenPopov'ым. Давно и неправда.
Наверное скудоумие некоторых товарищей или какая-то абсолютно непонятная упрямость мешают им смотреть на вещи адекватно. Я опять повторюсь: SDCC имеет намного больше права на жизнь, чем Hitech C. Впрочем, для господ извращенцев я даже начал делать подсистему ZXDev3 на базе CP/M-ного Hitech C. Ажиотажа вокруг неё совершенно не наблюдается.
Bolt, а допилить кодогенератор, чтобы на выходе был i8080 код, возможно?
ПК8010 "Корвет"+ExtRom+AY, Atari 65XE+SDrive, Дельта-С(52ИС)+AY, Scorpion ZS 1024+SMUC
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
