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

User Tag List

Страница 24 из 91 ПерваяПервая ... 202122232425262728 ... ПоследняяПоследняя
Показано с 231 по 240 из 907

Тема: Мощная среда ZXDev для разработки НА ПЯТИ ЯЗЫКАХ для ZX готова к тестированию

  1. #231
    Veteran Аватар для Oleg N. Cher
    Регистрация
    24.08.2007
    Адрес
    Днепропетровская обл.
    Сообщений
    1,610
    Спасибо Благодарностей отдано 
    2,182
    Спасибо Благодарностей получено 
    140
    Поблагодарили
    106 сообщений
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Hi Alcoholics Anonymous,

    Nice to know that you read this forum.

    Yeah, I know about 100,000 lines of asm subroutines of z88dk.

    But SDCC has a better code generation. So there is a sense to adapt this libraries to SDCC at least partially. If Philipp Krause will implement passing parameters to procedures in registers (fastcall) - it will be another reason to use SDCC instead of z88dk.

    But my preference is coding in Oberon, and not only for Spectrum. And I do not see any problems to connect z88dk to ZXDev as a back-end code generator. And use all this perfect libraries with ZXDev now.

  2. #232
    Member
    Регистрация
    21.05.2006
    Адрес
    Canada
    Сообщений
    78
    Спасибо Благодарностей отдано 
    3
    Спасибо Благодарностей получено 
    2
    Поблагодарили
    2 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    [QUOTE = Олег Николаевич Шер ; 711942 ]
    Но моя предпочтение кодирования в Oberon , и не только для Spectrum. И я не вижу никаких проблем для подключения z88dk чтобы ZXDev как генератор фоновых кода. И использовать все эти прекрасные библиотеки с ZXDev сейчас . [/ QUOTE]

    Я также не заинтересованы в только Spectrum То, что мы делаем, не слишком отличается , кроме вы смотрите на более широком кросс-платформенной совместимости в то время как мы смотрим на z80 кросс-платформенной совместимости . Весь код z88dk , или столько, сколько мы можем, носит общий характер и библиотеки , которые должны быть специализированные написаны на работу , как на многих платформах , как это возможно , используя тот же интерфейс . Так, например ,1-битовый библиотека звук проигрывает музыкальные и звуковые эффекты на 20 + различных Z80 машин . Графическая библиотека также рисует графику на 20 + различных Z80 машин . Спрайт двигателя меньше повезло , только работая на трех разных машинах. Поиск хорошего API, которые могут применяться на разных платформах не легко, и есть много мелких деталей , чтобы волноваться о . Например, 1 -битная звуковая поколения зависит от скорости процессора - так как вы генерировать те же ноты из того же кода ? Точно так же существуют различия в пиксельных и цветового разрешения с платформы на платформу так , пишущие хороший кросс-платформенный графическую библиотеку не так просто.

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

    Я читал некоторые из ваших сообщений на вашем форуме и главное, что я хотел обратить ваше внимание на том, что мы написали часть кода z80 , которого вы ищете , и мы на самом деле движется в том же направлении в течение нескольких вещей . Например, у меня есть идея для реализации z80 сборщик мусора , что я буду преследовать после следующего релиза z88dk и у меня есть идеи о том, как написать лучшую графическую библиотеку, которая включает в себя графический конвейер для масштабирования ( разные разрешения ) и вырезку , в то же время что позволяет для различных цветовых решений задач . Я заинтересован в коде обмена , API и подходов к Z80 целей так вот почему я отправляю , чтобы убедиться, что все знают друг о друге

    Что касается SDCC , мы проводим тестирование компиляцию с SDCC сейчас . Я могу генерировать SDCC программы, используя z88dk библиотеки , но есть еще проблемы, которые работают вне. SDCC может утверждать основной C LIB в z88dk , но бывает ли , что не гарантируется. SDCC должен беспокоиться о более чем цель z80 и включения переменного Lib , что значительно больше, и отличается от любого другого процессора может быть не то, что они хотят сделать . В любом случае , наверняка, нестандартные вещи, как графика, звук , спрайты не представляет интереса для SDCC . z88dk всегда будет домом для этого, и целью является , чтобы позволить аналоговый или цифровой компиляции с использованием двух различных компиляторов - SDCC и sccz80 .

    ======


    Цитата Сообщение от Oleg N. Cher Посмотреть сообщение
    But my preference is coding in Oberon, and not only for Spectrum. And I do not see any problems to connect z88dk to ZXDev as a back-end code generator. And use all this perfect libraries with ZXDev now.
    I am also not interested in only the Spectrum What we're doing is not too dissimilar other than you are looking at a broader cross-platform compatibility whereas we are looking at z80 cross-platform compatibility. All the z88dk code, or as much as we can, is generic and the libraries that must be specialized are written to work on as many platforms as possible using the same interface. So, for example, the 1-bit sound library plays music and sound effects on 20+ different z80 machines. The graphics library also draws graphics on 20+ different z80 machines. The sprite engine is less fortunate, only working on three different machines. Finding good APIs that can apply across platforms is not easy and there are many small details to worry about. For example, the 1-bit sound generation is affected by cpu speed -- so how do you generate the same notes from the same code? Likewise there are differences in pixel and colour resolution from platform to platform so writing a good cross platform graphics library is not easy.

    We're fortunate in that all the z80 machines are approximately the same in terms of computing power and resolution. Your task is harder as the range in capability is extreme. You're faced with either creating a lacklustre least common denominator API or taking on a much more difficult task of designing an API that degrades sensibly for less capable targets.

    I've read some of your posts on your forum and the main thing I wanted to bring to your attention is we've written some of the z80 code you are looking for and we are in fact heading in the same direction for several things. For example, I have an idea for implementing a z80 garbage collector that I will pursue after the next z88dk release and I have ideas on how to write a better graphics library that includes a graphics pipeline for scaling (different resolutions) and clipping, while still allowing for different colour resolutions of targets. I'm interested in sharing code, apis and approaches for z80 targets so that's why I post, to make sure everyone is aware of each other

    With regard to sdcc, we are testing compilation with sdcc now. I can generate sdcc programs using z88dk libraries but there are still problems to work out. sdcc may adopt the core c lib from z88dk, but whether that happens is not guaranteed. sdcc has to worry about more than the z80 target and incorporating a c lib that is much larger and dissimilar from every other processor might not be what they want to do. In any case, for sure, the non-standard things like graphics, sound, sprites are of no interest to sdcc. z88dk will always be the home for that and the intent is to allow seemless compilation using two different compilers -- sdcc and sccz80.

  3. #233
    Veteran
    Регистрация
    29.12.2010
    Адрес
    Москва
    Сообщений
    1,858
    Спасибо Благодарностей отдано 
    131
    Спасибо Благодарностей получено 
    104
    Поблагодарили
    62 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Почитал вашу перепалку: http://zx.oberon2.ru/forum/viewtopic.php?f=10&t=201
    Оба неправы


    Oleg N. Cher, чтобы твоей средой начали пользоваться, нужно сделать ее дружелюбной - компилирование в конечный файл Спектрума без танцев с бубном (этот у тебя уже есть) и наличие необходимых библиотек (этого пока нет). Плюс хорошая кодогенерация (SDCC барахлит частенько в плане выдачи оптимального кода). Библиотеки нужны, чтобы, к примеру, юзер не писал процедуру вывода спрайта или текста на Обероне - это не будет работать быстро на ЯВУ. А медленно - не нужно, не работоспособно. Как ты сделал "Дурака" без библиотек, я не знаю.
    Поэтому, займись сейчас сам встраиванием библиотек в среду, я тебе могу подкинуть некоторые процедуры уже сейчас. А также рекомендую пособирать на сайте http://zxdn.narod.ru/coding.htm
    Также рекомендую выкинуть из языка ненужные для Спека элементы, если они существенно займут время твоей разработки - действительные числа, многомерные массивы и др. Просто, они не нужны в реальной жизни на Спеке.
    И, ИМХО, хоть Оберон и "красивее" Паскаля, но для имеющихся спектрумистов лучше всё же Паскаль, т.к. его многие уже знают, у них и в сети есть куча исходников на Паскале. На Обероне почти нет. Переводить в Оберон никто не захочет. Так исторически сложилось, и переломить это мы не можем. Вот тебе пример - формат ogg для музыки лучше mp3 по качеству со сравнимым размером файла, но его мало кто использует. Не успели вовремя раскрутиться. Тут кто первый со своим кривым поделием, того и TAP-ки. Компилир z88dk так себе, я рассматривал его для своей работы, даже С хотел выучить наконец, но забраковал из-за крайне неэффективного кода. Но лучше пока нет.
    Второй вариант - делай Оберон для себя, для фана, как ты хочешь. Тогда и спорить тут ни с кем смысла нет. Спектрум с точки зрения здравого смысла - бесперспективная платформа для большинства народа. Оберон - не взлетел. Паскаль и Делфи для коммерческих разработок умерли. И спорить про вакансии смысла нет. Хочешь зарабатывать денег на программировании, учи C++ и Java (и чё там еще щас). С этим мирком бороться бесполезно, пусть бегают как белка в колесе, а мы с попкорном понаблюдаем, писия на старом добром Паскале.

  4. #234
    Veteran Аватар для Kakos_nonos
    Регистрация
    26.12.2010
    Адрес
    Кубань
    Сообщений
    1,154
    Спасибо Благодарностей отдано 
    33
    Спасибо Благодарностей получено 
    39
    Поблагодарили
    23 сообщений
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

  5. #235
    Veteran Аватар для Oleg N. Cher
    Регистрация
    24.08.2007
    Адрес
    Днепропетровская обл.
    Сообщений
    1,610
    Спасибо Благодарностей отдано 
    2,182
    Спасибо Благодарностей получено 
    140
    Поблагодарили
    106 сообщений
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Andrew771 Посмотреть сообщение
    наличие необходимых библиотек (этого пока нет).
    Нельзя говорить, что библиотек нет совсем. Смотрите что есть:

    Доступные библиотеки
    ====================

    Basic - Sinclair ZX Spectrum Basic для Ofront/SDCC
    Best40 - "40 лучших процедур" от SerzhSoft. На самом деле меньше.
    Console - консольный ввод-вывод
    Graph - графическая библиотека, совместимая с Turbo Pascal
    Input - ввод с клавиатуры
    GrFonts, GrPixel, GrScr, GrTiles - кроссплатформенная графика XDev
    Laser - Laser Basic для Ofront/SDCC
    Math - вещественная математика, генерация случайных чисел
    Mega - Пара процедур из Mega Basic
    Platform - платформенно-зависимые возможности
    Strings - работа со строками
    Timer - задержка времени
    TrDos - работа с функциями TR-DOS

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

    Цитата Сообщение от Andrew771 Посмотреть сообщение
    А медленно - не нужно, не работоспособно. Как ты сделал "Дурака" без библиотек, я не знаю.
    См. выше. Для Дурака, собственно, хватает библиотек Laser и Basic. Для него они начаты, уже не для него продолжены.

    Цитата Сообщение от Andrew771 Посмотреть сообщение
    Поэтому, займись сейчас сам встраиванием библиотек в среду, я тебе могу подкинуть некоторые процедуры уже сейчас.
    А подкинь-ка плиз. А то я уже года три как среду делаю сам. И вынужден отстаивать идеи высокоуровневой разработки для Спека, хотя такие игры давно делаются на z88dk. И идеи Паскаль-языков. Хотя у языков данного семейства есть свои ценители.

    Цитата Сообщение от Andrew771 Посмотреть сообщение
    Также рекомендую выкинуть из языка ненужные для Спека элементы, если они существенно займут время твоей разработки - действительные числа, многомерные массивы и др.
    Ничего специально выкидывать не буду - они достались мне даром. То есть уже реализованы в Ofront'е и SDCC. Я могу рассказать что я вижу мешающим и как вижу дальнейшее усовершенствование, но не путём отбрасывания этих средств конечно. Не нужны - не пользуйся. А кому-то могут понадобиться. Более того, достигается какая-то доля портабельности, но она возможна только за счёт набора библиотек с одинаковой логикой и интерфейсами, которые мне тоже приходится разрабатывать одному, притом для разных платформ.

    Цитата Сообщение от Andrew771 Посмотреть сообщение
    И, ИМХО, хоть Оберон и "красивее" Паскаля, но для имеющихся спектрумистов лучше всё же Паскаль, т.к. его многие уже знают, у них и в сети есть куча исходников на Паскале. На Обероне почти нет.
    Готовые исходники на Паскале очень слабо подойдут для Спека, так что это не аргумент. Их приходится модифицировать. Более того, "вещи в себе" можно за пять минут переписать на Оберон, а серьёзные вещи с TurboPascal'я на Спек не перепишешь, не хватит ресурсов.

    Благодарю за "красивее". Он действительно красивее. Например за счёт отказа от лишних BEGIN'ов. Не стоит за них держаться.

    Цитата Сообщение от Andrew771 Посмотреть сообщение
    Переводить в Оберон никто не захочет.
    Ты рассуждаешь так, будто в сети полно исходников на Паскале без вещественной арифметики и многомерных массивов, и их только скопипастить - и будет работать под Спеком. А реальная проблема в головах, которые не согласны считать Оберон хорошим Паскалем.

    Цитата Сообщение от Andrew771 Посмотреть сообщение
    Второй вариант - делай Оберон для себя, для фана, как ты хочешь. Тогда и спорить тут ни с кем смысла нет.
    ZXDev вообще появился по просьбам трудящихся спектрумистов, и мне жаль, что они не хотят поддерживать это направление, часто предпочитая этому кодирование слабых игрушек. Наверное не могут разглядеть потенциала. Так что, получается, для себя и делаю.

    Цитата Сообщение от Andrew771 Посмотреть сообщение
    Оберон - не взлетел. Паскаль и Делфи для коммерческих разработок умерли.
    Погоди, нельзя так говорить. Дельфи жив, вон ввели поддержку C++ для Андроида. FreePascal жив и для коммерческих разработок, вообще очень интересная среда, я хотел бы видеть в итоге с XDev что-то похожее, только на базе Оберона.

    И к Оберону в научных кругах интерес огромный. Этот язык не имеет аналогов в качестве простого современного императивного языка для публикации алгоритмов и т.п.

    Цитата Сообщение от Andrew771 Посмотреть сообщение
    С этим мирком бороться бесполезно, пусть бегают как белка в колесе, а мы с попкорном понаблюдаем, писия на старом добром Паскале.
    Или на улучшенном Паскале. Согласен.

    P.S. Ты если с кодом решишься помогать, то делай это тоже не для меня, а для себя, для своей будущей игры, а я тебе всячески помогу, т.к. понимаю как непросто решиться вкладывать свой труд в ZXDev. Но это в общем то же направление, что и твоё, и, хотя для многих это неочевидно, я просто предлагаю собрать ZX-библиотеки в одном месте, снабдить их высокоуровневыми интерфейсами, возможностью смарт-линковки и возможностью вызывать их не только из Оберона, но и из Си и асма. Что здесь не так, что никто не поддержал это начинание?

    ---------- Post added at 11:42 ---------- Previous post was at 11:39 ----------

    Цитата Сообщение от Kakos_nonos Посмотреть сообщение
    Для того, чтобы среда пошла в массы надо сделать туториалы и хорошо её описать, как начать, как закончить, что писать и т д.
    Kakos_nonos, собственно, что мог сделать один человек - он делает. См. на форуме Пристанище Спектрум-кодера. Дальше - люди берут и пользуются этим, задают наводящие вопросы, помогают. Или критикуют конструктивно. Либо же нет.

  6. #236
    Veteran
    Регистрация
    29.12.2010
    Адрес
    Москва
    Сообщений
    1,858
    Спасибо Благодарностей отдано 
    131
    Спасибо Благодарностей получено 
    104
    Поблагодарили
    62 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Oleg N. Cher Посмотреть сообщение
    Ничего специально выкидывать не буду - они достались мне даром.
    Тогда да, лучше оставить. Если время на их разработку уже не нужно. Единственное, из-за них могут быть универсальные излишества в генерируемом коде для целочисленных типов, надо смотреть.

    Цитата Сообщение от Oleg N. Cher Посмотреть сообщение
    Готовые исходники на Паскале очень слабо подойдут для Спека, так что это не аргумент. Их приходится модифицировать. Более того, "вещи в себе" можно за пять минут переписать на Оберон, а серьёзные вещи с TurboPascal'я на Спек не перепишешь, не хватит ресурсов.
    Ну если там нет действительных типов, то не так сложно. Скорректировать только координаты вывода на экран. Я вот здесь для примера посмотрел исходники, реально: http://pascal.proweb.kz/index.php?page=127

    Цитата Сообщение от Oleg N. Cher Посмотреть сообщение
    А подкинь-ка плиз. А то я уже года три как среду делаю сам.
    Цитата Сообщение от Oleg N. Cher Посмотреть сообщение
    P.S. Ты если с кодом решишься помогать, то делай это тоже не для меня, а для себя, для своей будущей игры, а я тебе всячески помогу, т.к. понимаю как непросто решиться вкладывать свой труд в ZXDev.
    Выкладываю текущий свой проект Паскаля, библиотека процедур там в файле libasm.lib - это обычный текстовый файл с процедурами на асме. Некоторые надёргал из разных источников, некоторые сам написал. До спрайтов пока не дошел. Можешь себе брать.
    А еще можешь поюзать сам Паскаль. Уже поддерживаются:
    - переменные типов byte и word;
    - одномерные и двумерные массивы типа ArrayWord[i,j];
    - операторы: begin-end, :=, write(ln), if-then, for-to, while, repeat-until, pause, clrscr, gotoxy;
    - математические и логические выражения; арифметические знаки + - * / % (целочисленные); скобки и приоритет операций поддерживаются;
    - процедуры без параметров;
    - нестандартные операторы: color(attr) - установка байта атрибутов; window(x,y,width,height) - установка и очистка окна в знакоместах.
    - шрифт используется пока только 4х8 (64 символа в строке).

    Оптимизации кода пока нет. Но буду делать по навету ZEKа - оптимизировать сгенерированный код - распознавать шаблонные комбинации команд и заменять оптимальными.
    Планируется куча встроенных команд вывода спрайтов, вывода и обработки карт/лабиринтов, скроллингов и отражений окон. Часть процедур уже написана за предыдущие игры. Сейчас я занят поддержкой символьных переменных и массивов (помимо игры на конкурс "Твоя игра", но ей уже почти конец).
    Вложения Вложения
    Последний раз редактировалось Andrew771; 30.05.2014 в 14:46.

  7. #237
    Veteran Аватар для Oleg N. Cher
    Регистрация
    24.08.2007
    Адрес
    Днепропетровская обл.
    Сообщений
    1,610
    Спасибо Благодарностей отдано 
    2,182
    Спасибо Благодарностей получено 
    140
    Поблагодарили
    106 сообщений
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Andrew771 Посмотреть сообщение
    Тогда да, лучше оставить. Если время на их разработку уже не нужно. Единственное, из-за них могут быть универсальные излишества в генерируемом коде для целочисленных типов, надо смотреть.
    Я смотрел. Ни вещ. арифметика, ни многомерные массивы при их неиспользовании не утяжеляют целевой бинарник. Ни одного байта лишнего кода.

    Но если вдруг (ну вдруг) кому-то понадобится в твоём Паскале трёхмерный массив, придётся вычислять координаты вручную. SDCC же это делает эффективно автоматически.

    Цитата Сообщение от Andrew771 Посмотреть сообщение
    Ну если там нет действительных типов, то не так сложно. Скорректировать только координаты вывода на экран. Я вот здесь для примера посмотрел исходники, реально: http://pascal.proweb.kz/index.php?page=127
    Реально, но после неизбежной модификации. Куча готовых исходников на ТурбоПаскале - это работа с портами, векторами прерываний и с библиотеками, которые физически нельзя портировать на Спек, с большими массивами и ещё много чем. В случае с Дельфи случай ещё тяжелее, там потоки, сокеты и gui. Найди хотя бы десять исходников на Паскале, которые ты копипастой соберёшь для Спека. И даже если ты их найдёшь, это будет всего десять исходников. А тех, которые не соберутся - миллион. Это что, тоже аргумент за Паскаль вместо Оберона?

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

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

    Самая интересная критика моего направления разработок заслуживает самого пристального внимания. Но даже более бездарной критики я очень редко удостаиваюсь, в основном, как видишь, это предвзятые придирки при полном нежелании даже скачать и опробовать среду. А к тебе в ветку ещё не приходили сравнивать твою кодогенерацию с SDCC? Значит придут. Или, например, человек не посмотрел библиотеки, но вовсю кричит о "дичайшем отставании по библиотекам". А сам хоть бы процедурку адаптировал, например, из своей игры.

    Цитата Сообщение от Andrew771 Посмотреть сообщение
    Некоторые надёргал из разных источников, некоторые сам написал. До спрайтов пока не дошел. Можешь себе брать.
    Спасибо, гляну. Но насколько я понимаю, вкладываться в ZXDev, адаптируя процедуры самолично, ты не хочешь. Что ж, но даже такая рутинная работа требует усилий, хотя время от времени я ею занимаюсь.

    Цитата Сообщение от Andrew771 Посмотреть сообщение
    А еще можешь поюзать сам Паскаль.
    Мне есть смысль юзать его только в том случае, если он будет иметь серьёзные преимущества по сравнению с ZXDev. Пока же ZXDev:

    • выглядит более готовым;
    • позволяет использовать при разработке язык Си наряду с Обероном;
    • имеет оптимизирующую кодогенерацию; и побольше библиотек;
    • имеет все предпосылки для кроссплатформенной разработки. Притом данный подход соединяет даже такие несоединимые вроде бы вещи как Z80 и JavaME в возможности разрабатывать игру для этих двух платформ с одного листа на одном языке. И хотя у него хватает и недостатков, и достоинств здесь чувствуется огромный потенциал;
    • ну и, наконец, я предпочитаю продукты с открытыми исходниками.

    Открытость + кодогенерация это особая проблема. Открыв продукт, ты успокоишь пользователей твоего Паскаля, которых предвидится не так много. Но этим ты не обеспечишь того, что все кинутся тебе помогать разрабатывать Паскаль. Даже если договоришься с кем-то по языку и стилю разработки, сама задача высокоэффективной оптимизирующей генерации кода слишком сложна для одного человека и очень плохо поддаётся декомпозиции. Её вообще крайне сложно разделить на маленькие кусочки, которые накопительно и последовательно могут разрабатываться несколькими людьми со своим видением проблемы. Пожалуй, лучше всего в плане декомпозиции компилятора преуспел Вирт. Его интерфейс к бэк-энду весь занимает всего 14 процедур.

    Цитата Сообщение от Paul Reed
    7. Writing a New Code Generator

    The general method which we found extremely helpful when developing a new code generator is the same as that explained in Project Oberon [1]. Before describing his compiler in detail, Wirth first lists fifteen sample 'code patterns' (we added a sixteenth for our open-array operations), showing what machine code should be output for a particular set of sample Oberon statements and expressions.

    These patterns are far from working programs, but as Wirth points out, the discipline of deciding which code should be output (usually with a paper and pencil in our case) is a prerequisite, before discovering how best to design the generator. Working our way through the patterns kept the complexity of the task in check.

    Each code-generation procedure has a standardised interface, and there are 14 procedures in all:

    Released () Move () Addr() Index () MonOpO BinOpO Branch () JumpO Trap () Case () PrepCallO Call() Enter () Return ()
    Это кроссплатформенный компилятор.

    И если бы удалась примерно такая же декомпозиция оптимизирующей кодогенерации на простые и инкрементально поддающиеся доработке различными заинтересованными людьми части, было бы просто замечательно. Но увы. Решение этой задачи лежит в слишком сложной плоскости. Ты его коснулся только слегка. Дальше будут такие дебри, что ой. Так что мы сможем собрать со всего форума претензии к коду, выданному SDCC, и применить их к твоему Паскалю в ещё большей степени. Не думай, что злорадствую. Я сочувствующий.

  8. #238
    Veteran
    Регистрация
    26.11.2013
    Адрес
    г. Новосибирск
    Сообщений
    1,042
    Спасибо Благодарностей отдано 
    934
    Спасибо Благодарностей получено 
    227
    Поблагодарили
    122 сообщений
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Сделал первый "продукт" в среде ZXDev.
    Иллюстрация окружностей и работы EORFill.
    Первоначальный алгоритм рисования окружности
    где-то нарыл denpopov, потом его исправляли, в основном Titus.
    За основу взял пример с цветочком. Flower.Mod

    Скрытый текст


    Текст на обероне:
    Код:
    MODULE Circl;
    IMPORT G := Graph, Basic;
    
    VAR
      KD, MD, x0, y0, R, i: INTEGER;
    
    PROCEDURE Circ (x, y, Radius: INTEGER);
    VAR
      X,Y,A:INTEGER;
    
    	PROCEDURE Plot4;
    	VAR
    	  ty:INTEGER;
    	BEGIN
    	  ty:=(y+Y);
    		IF ty<0 THEN ty:=0 ELSIF ty>G.GetMaxY() THEN ty:=G.GetMaxY() END;
    		G.PutPixel(x +X,ty);
    		IF X#0 THEN G.PutPixel(x -X,ty); END;
    	  ty:=(y-Y);
    		IF ty<0 THEN ty:=0 ELSIF ty>G.GetMaxY() THEN ty:=G.GetMaxY() END;
    		G.PutPixel(x +X,ty);
    		IF X#0 THEN G.PutPixel(x -X,ty); END;
    	END Plot4;
    BEGIN
    (*This is the entire algorithm:*)
    
    	Y:= Radius;
    	X:=0;
    	A := Radius DIV 2;
    	REPEAT
    			(*;Could just use Plot8*)
    		Plot4;X := X + 1;
    		A := A - X;
    		IF A<0 THEN A:=A+Y ; Y:=Y-1 END;
    	UNTIL X >= Y;
    
    (*; Now more or less reverse the above to get the other eighth*)
    
    	A := -(Radius DIV 2) - 1;
    	Plot4;
    	REPEAT
    		A := A + Y;
    		Y := Y - 1;
    		IF A>0 THEN X:=X+1;A:=A-X;Plot4; END;
    	UNTIL ~(Y>=0);
    	
    END Circ;
    
    
    BEGIN (*$MAIN*)
      KD := G.ZX;
      MD := G.ZXMono;
      G.InitGraph(KD, MD, "");
      G.SetBkColor(G.Green); G.SetColor(G.Black); G.ClearDevice;
      Basic.OVER(1);
    (*  x0 := (G.GetMaxX() + 1) DIV 2;
      y0 := (G.GetMaxY() + 1) DIV 2;*)
    	FOR i:=0 TO 20 DO
    	  x0 := Basic.RND(-60,G.GetMaxX()+60);
      	y0 := Basic.RND(-60,G.GetMaxY()+60);
    	  
    		FOR R:=20 TO 60 BY 20 DO
      		Circ(x0, y0, R);
    	  END;
      END;
      (*Flower(x0, y0, y0 DIV 2 * 3, 5, 1.0, 0.25, 0.1);*)
      Basic.PAUSE(0);
    	G.EORFill;
      G.CloseGraph
    END Circl.
    Текст EORFill, которую я наглым образом добавил в модуль Graph :
    Код:
    /*--------------------------------- Cut here ---------------------------------*/
    export void Graph_EORFill (void)
    {
    __asm
      LD   L,#0X20
    loop1$:
      DEC L
      LD   H,#0X40
      XOR A
      LD   C,#3
    loop2$:
      LD   B,#8
      LD   DE,#32-7*256
    loop3$:
      XOR (HL)
      LD (HL),A
      INC H
      XOR (HL)
      LD (HL),A
      INC H
      XOR (HL)
      LD (HL),A
      INC H
      XOR (HL)
      LD (HL),A
      INC H
      XOR (HL)
      LD (HL),A
      INC H
      XOR (HL)
      LD (HL),A
      INC H
      XOR (HL)
      LD (HL),A
      INC H
      XOR (HL)
      LD (HL),A
      ADD HL,DE
      DJNZ loop3$
      LD DE,#8*256-8*32
      ADD HL,DE
      DEC C
      JR NZ,loop2$
      DEC L
      INC L
      JR NZ,loop1$
      RET
    __endasm;
    } //Graph_EORFill
    [свернуть]


    Вложения

  9. #239
    Banned
    Регистрация
    12.02.2014
    Адрес
    г. Арзамас
    Сообщений
    6,123
    Спасибо Благодарностей отдано 
    0
    Спасибо Благодарностей получено 
    1
    Поблагодарили
    1 сообщение
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    исподники зажал?

  10. #240
    Veteran
    Регистрация
    26.11.2013
    Адрес
    г. Новосибирск
    Сообщений
    1,042
    Спасибо Благодарностей отдано 
    934
    Спасибо Благодарностей получено 
    227
    Поблагодарили
    122 сообщений
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от denpopov Посмотреть сообщение
    исподники зажал?
    Исходники что-ли? Все что были, все под спойлер запихал.

Страница 24 из 91 ПерваяПервая ... 202122232425262728 ... ПоследняяПоследняя

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

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

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

Похожие темы

  1. мощная игрушка
    от ZEman в разделе Игры
    Ответов: 129
    Последнее: 23.03.2024, 17:05
  2. Ответов: 5
    Последнее: 20.06.2011, 03:18
  3. Видеоконтроллер из пяти микросхем
    от zx-kit в разделе Изображение
    Ответов: 20
    Последнее: 31.03.2011, 14:48

Метки этой темы

Ваши права

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