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

Цитата:

---

Сообщение от Oleg N. Cher

А то в Обероне я привык перечислять в секции импорта модули в любом порядке, и считаю это удобным.

---

Это препроцессор фигней страдает. Можно посмотреть что на вход компилятора попадает.

Цитата:

---

Сообщение от Oleg N. Cher

Это к вопросу о том, что Си ну вот нисколечко ещё не протух на сегодняшнее время. И дизайн в нём прекрасный, и всё прозрачно. А для больших программных систем - так вообще не жисть, а рай сущий.

---

А кто-то такое утверждал? Чем более низкоуровневый язык, тем ниже потолок сложности создаваемых систем.

Цитата:

---

Сообщение от Oleg N. Cher

Console.c:17: error: incompatible types for redefinition of 'Console_WriteStrLn_WinAPI'

А то в Обероне я привык перечислять в секции импорта модули в любом порядке, и считаю это удобным.

---

Боже мой, ну при чём тут импорт модулей или символов из модулей?

Вы ещё ничего и никуда не импортируете, и, возможно, вообще этот ваш Console_WriteStrLn_WinAPI не линкуете.

(Подразумевая, что Console_WriteStrLn_WinAPI - callable entity), вы в Обероне, что, можете объявить её signature, потом переобъявить её signature другими другими типами (ещё параметров добавьте-уберите) и не посыпаться в рантайме? Вас ведь компайлер умный предупреждает. Зря, наверное.

Если sizeof() типов одинаковый и возможен type-to-type mapping, отключите strong type checking и поглядите, скомпилит-ли.

Ну а так - бага в одном из .h файлов, который windows.h не включает, но переопределяет уже объявленные там типы. Только не надо говорить, что windows.h это должет делать - это MS API, они имеют полное право introduce свои типы без учёта, что кто-то уже WINAPI или что-нибудь определил.

Цитата:

---

Сообщение от Oleg N. Cher

Это к вопросу о том, что Си ну вот нисколечко ещё не протух на сегодняшнее время. И дизайн в нём прекрасный, и всё прозрачно.

---

При чём тут дизайн в C, и что непрозрачно?

Цитата:

---

Сообщение от Oleg N. Cher

P.S. Вообще-то работает и без этого

---

Естественно, типы возможно аллокируют одинаковое количество байт (или даже используют один-и тот-же базовый тип) на платформе под которую вы компилитесь. Как и сказал, отключите strict type checking, если ваш код не предполагает быть portable.

Олег, как переделать sdcc-шные либы под ZXDev? Сразу говорю, пример на твоём сайте я не понял.

Sergey, если для Вас это ещё актуально, дайте знать. Я просто свернул это направление как неприоритетное.

Что конкретно непонятно? Там всё очень чётко расписано. Если я и собирался что-то добавить, то только как проецировать сишные типы на обероновские.

P.S.

• Резон появления и смысл среды XDev
  
• ZXDev + TR-DOS
  
• Компактная вещественная арифметика для Спектрума
  
• Демо-версия рогалика для ZX на Обероне. С критикой, пожалуйста, не ко мне. Неинтересно.
  
• Прогресс разработки порта игры “Dark Woods”

Портировал с Turbo Pascal на Оберон для ZX Spectrum простенькую консольную игру «Кости».

https://github.com/Oleg-N-Cher/Dice

Попутно ещё хочу рассказать г-ну introspec'у, что в его родном Лондоне функционирует фирма Padded Cell Software Ltd, PO Box 1880, London NW6 1BQ, United Kingdom, которая активно использует язык Оберон для разработки программного обеспечения повышенной надёжности для своих клиентов, среди которых — государственные организации Англии. Об этом говорит Пол Рид в своих статьях Building Your Own Tools - An Oberon Industrial Case-Study и An Oberon Linker for an Imperfect World – More Notes on Building Your Own Tools

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

Цитата:

---

Сообщение от Paul Reed

Summary: Our experience creating custom application software has taught us that total control over our development tools is a necessity. Project Oberon provided an excellent starting point for us to build our own cross-platform application programming environment. Our adaptation of Wirth's compiler is re-targetable at run-time via a small set of installable up-calls, enabling a single machine-specific code-generation module of typically less than a thousand lines of code. The only significant additions to the original Oberon language are floating-point binary-coded decimals and open-array variables with string concatenation (e.g. s := "Error: " + t). Accompanying run-time libraries, written in Oberon, for operating systems such as Microsoft Windows (32-bit) and MS-DOS have been developed. Several systems created using the new tools have been in use by customers for some time.

1. Introduction

We present an industrial application of Niklaus Wirth's and Jiirg Gutknecht's research project [1], the programming language [2] and operating system Oberon, which aims to retain the original's simplicity, clarity and reliability. First the motivation for developing the software is explained, and the occasionally roundabout route which led to it is described in some detail. The particular design aspects of our version of the Oberon compiler and its target run-time environment are summarised, and finally we outline the steps involved in writing a new code generator for a given machine. In publishing these experiences, we hope that others may be encouraged to take Wirth's blunt attitude to 'bells and whistles', and enjoy reliable software as a natural result.

2. Motivation

Providing working software for real customers is in most cases hard work, yet despite warnings [3] the complexity involved continues to be underestimated by the industry's practitioners. Many large, high-profile software projects fail completely - and 'small' software is often unreliable. Critics often contrast this with civil engineering, where (on the whole) bridges do not tend to collapse during construction. Considering that in software we have far more control over the properties of our tools and materials than in other branches of engineering, the phenomenon is all the more surprising.

We reject the argument that computing is still in its infancy and therefore that such failures are only to be expected - consider aviation, where through great effort and the will to create a safety culture, passenger flights were made acceptably safe by the 1930's and fatality rates were improved again by an order of magnitude by the late 1950's.

In our experience, the biggest obstacle to providing finished software is finding the time to write it. Analysing our past projects, which used the complex development tools available commercially, it dawned on us that a frightening proportion of intellectual effort and time was being wasted on installation, configuration and debugging of these tools - we estimated in one extreme case as much as eighty percent of the entire project time.

We feel that it is partly because software offers the freedom to design ridiculously over-featured compilers and other development tools (most of which are far from bug-free) that the complexity of projects can get out of hand. Wrestling with the unpredictable properties of a fault-ridden programmer's tool may be stimulating, but it is distracting, and leaves less of our mental capacity available to solve the problems in the customers' domain.

Creating simple, single-purpose tools is unfashionable because it restricts scope and flexibility; but this can sometimes actually be beneficial, reducing the sheer number of decisions to be made along the way. An example of this is the software running the tiny computer fitted to the Voyager 2 space probe, whose outstandingly successful mission inspired Wirth to begin the original Oberon project [1].

The concept of providing just enough is expounded repeatedly in Project Oberon. But what makes it unique is the presentation of the entire source code of the operating system and compiler, and extremely lucid descriptions of their design and construction, all in a single compact volume. Many excellent expositions of compiler design and compiler-writing toolkits exist, for example [4], [5]; but the emphasis is often on a general approach. Attention in the literature tends to be focused on writing a 'front-end', where statements formulated in the source language are parsed, whereas actual code-generation (the 'back end') is sometimes even left as an exercise to the reader.

Knowing that we could fall back on the source code and explanations in the book, at the beginning of 1997 we decided to start a project to build some new in-house development tools based around the hand-crafted, single-pass, recursive-descent Oberon compiler designed by Wirth.

3. Objectives

The goal of our project was a simple, portable application programming environment gained in a reasonably short time scale.

Simplicity was essential in order to ensure a complete understanding of the tool on which we were totally reliant. This avoids being in the position, when developing software systems for customers, of blaming tools like bad workmen. There is also usually a need to maintain and adapt software long after it has been created, and our compiler tool would not be exempt from this.

Several different machines and operating systems, including at least Microsoft Windows (32-bit) and Apple Macintosh, would need to be supported. So the compiler would need to be portable, generating code for more than one processor chip (at least Intel 80386 and Motorola 68000 respectively).

The third requirement was that the programming of the tools should not be an undue distraction - either during their construction or afterwards. We had no intention of becoming a development tools company, spending large amounts of time on the maintenance of our compiler for each machine platform - we wished actually to use the tools.

---

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

Я могу продолжить этот список, который конечно никак не убедит г-на introspec'а, его вообще не прошибёшь ничем. Есть безпилотные летающие аппараты, есть софт для публичной библиотеки и железнодорожных линий метро, медицинского оборудования и даже для управления реакторами АЭС. Всё на Оберонах. Оберон — это такая компактная, простая и надёжная Ада. По крайней мере, в той же нише.

Или г-н introspec считает: что хорошо и весьма актуально для структур государственного значения в Англии и Швейцарии, плохо для русских спектрумистов? ;) Так тогда это вообще диверсия против русских. ;)

P.S. Никто не пробовал работать с Mira Modula-2? А то я смотрю, тут библиотеки есть. Можно на ZXDev портировать.

Спасибо, интересно. :)

Мой вариант "С чего начать":

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

1.

Цитата:

---

Сообщение от Oleg N. Cher

Скачать: https://github.com/Oleg-N-Cher/XDev/zipball/master

---

2. Распаковать.
3. Запустить BlackBox.exe
4. Открыть в нём TourRu.odc
5. Изучать.
6. Почитать файл ZXDev\Docu\ZXDevRus.txt
7. Позапускать примеры из папки ZXDev\Mod\
8. Почитать ZXDev\Docu\obe_faq2.htm

[свернуть]

Моё "ЧаВо":

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

1. Файлы примеров бывают *.Mod и *.Odc. В чём их различия?
odc - это сложный документ, может быть с картинками или с гиперссылками и т.д. Mod - простой текст.

2. При нажатии F11 возникла ошибка "command error: object OfrontOPM.MaxStruct inconsistently imported from OfrontOPC" Что это?
Такое может случится от внутреннего несоответствия модулей подсистемы Ofront, (они рассинхронизировались).
Чтобы исправить откройте XDev/Ofront/Docu/Rebuild-Ofront.odc (двойным щелчком по имени этого файла или через File -> Open) и кликните по чёрному кругляшику (коммандеру) для пересборки подсистемы.

3. Когда я выделяю в тексте название модуля, давлю правой кнопкой мыши, выбираю "Interface", то ничего не происходит :(
Дело в том, что эта возможность предусмотрена только для модулей, собранных самим BlackBox Component Builder, его подсистемой Dev, которая компилирует модули в 32-битный код процессора 80x86.
Разработка же для Спектрума ведётся с помощью другой схемы. И, соответственно, посмотреть интерфейс можно, выделив в тексте название модуля и выбрав из меню XDev -> Show Definition. Притом в меню Ofront тоже есть пункт "Show Definition", но он не всегда будет корректно срабатывать, и я планирую убрать его.

ЧаВо по Оберону от "Информатика21"
ЧаВо по Оберону от oberoncore.ru

[свернуть]

Что ж, TourRu.odc это конечно интересное чтиво, но, пожалуй, оно имеет не так много отношения к Спектруму. Хотя как сказать. :)

Спасибо за Ваш пост! Очень важно видеть живой отклик.

Цитата:

---

Сообщение от Oleg N. Cher

Попутно ещё хочу рассказать г-ну introspec'у, что в его родном Лондоне функционирует фирма Padded Cell Software Ltd, PO Box 1880, London NW6 1BQ, United Kingdom, которая активно использует язык Оберон для разработки программного обеспечения повышенной надёжности для своих клиентов, среди которых — государственные организации Англии.

---

Клиентов, как я посмотрю, настолько много, что у фирмы нет даже денег на собственный офис. PO Box 1880 - это примерно как почтовый ящик до востребования.

Спасибо, посмеялся.

Цитата:

---

Сообщение от introspec

Клиентов, как я посмотрю, настолько много, что у фирмы нет даже денег на собственный офис. PO Box 1880 - это примерно как почтовый ящик до востребования.

Спасибо, посмеялся.

---

:v2_dizzy_facepalm:

Цитата:

---

Сообщение от introspec

Спасибо, посмеялся.

---

Не знаю что там с почтовым ящиком, возможно, фирма, получающая государственное финансирование, не желает светить свой адрес. У таких фирм совсем другое отношение и к рекламе. Но я точно знаю, что софт, написанный на Обероне, находится в активной эксплуатации в гос. структурах Англии. И его поддержкой занимается фирма Padded Cell Software Ltd. Мне об этом написал Рид.

Цитата:

---

Сообщение от Paul Reed

Dear Mr. Cher,

Thank you for your request. Unfortunately we have no plans to release the
compiler covered by my papers under an open source licence. It's still a
tool used commercially on an everyday basis by us and some of our clients;
it's a non-standard implementation of Oberon; and there are not currently
enough resources available to manage an effective publication to our
satisfaction.

The papers, which themselves entailed a considerable amount of work to get
to a usable and helpful state, were intended to provide aid and
encouragement to people thinking of taking the step I made, from compiler
user to compiler user and maintainer. This is what I would like to see
more of, not a simple copy of what we did.

Prof. Wirth does the real work, however, in keeping the compilers simple
enough to be understood in their entirety. Open source projects do not
have a very good track record in this direction.

Currently, I am currently helping revise the Project Oberon book and
system, using an FPGA to implement Wirth's RISC processor from the
Compiler Construction book (rather than the defunct NS32032). This
project, although underway for some time, has no firm publication date yet
because there is still much work to do. But I hope it will provide an
alternative route to some of your desires below.

For some more information, please see our talk at last year's 25th
Anniversary Oberon Day celebration:

http://www.oberonday2011.ethz.ch/

Best regards,
Paul Reed

---

Сам же Пол Рид по сей день активно занимается научной деятельностью и Оберон-технологиями. В этом можно убедиться, почитав рассылки ETH.

Цитата:

---

Сообщение от Oleg N. Cher

Во упырюга. Кола осинового на тебя нет, засланец. :)

---

Oleg, а не нужно поминать меня в буквально каждом вашем посте, глядишь, и полегчает. Не я к вам сюда в тред пришёл, а вы меня призвали, в довольно гнусной форме, кстати. Я понимаю, что у Оберона на спектруме осталась всего одна большая проблема - Враг в Лондоне, но попробуйте всё же немного сдерживаться с тоном ваших остроумных высказываний, тем более что по сути вам возразить, очевидно, нечего.

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

Цитата:

---

Сообщение от Reobne

2. При нажатии F11 возникла ошибка "command error: object OfrontOPM.MaxStruct inconsistently imported from OfrontOPC" Что это?

---

Данную ошибку в репозитории я уже починил, а заключалась она в том, что я увеличил константу - максимальную длину идентификатора, но не пересобрал модули, которые зависели от этой константы. BlackBox такую ошибку легко определяет и очень часто это помогает экономить время.

Как именно происходит разработка XDev.

Тот вариант, который скачивается из ветки master, - не тот же, который крутится у меня на машине. Бывает так, что я обкатываю какую-то фишку, но не заливаю её пока не убежусь, что всё работает стабильно.

Так что повторение именно этой ошибки маловероятно.

Когда именно планируется выпуск релиза XDev. Меня уже критиковали на WoS (да и здесь по-моему тоже) за "большую кучу файлов", бОльшая половина из которых действительно не нужна для разработки под Спектрум. Поэтому в планах есть выпуск XDevLite. Это будет минималистическое IDE + к нему в дополнение подсистемы для разработки под разные платформы: ZXDev, WinDev, LinDev, JmeDev. Возможно, ещё какие-то, например ZXEvoDev или NesDev - если сумеем освоить это направление. Я хотел бы покодить для NES, но не знаю её асма.

Вопрос сроков релиза XDevLite + ZXDev упирается в незаконченную утилиту MakeZX для создания TAP'ок, которую я планировал включить в первую версию. И ещё в одну проблемку с подсистемой раскраски синтаксиса. А также в желающих поучаствовать в бета-тестинге. Вернее, в их практически полном отсутствии. Окончательный размер всего набора утилит планируется такой (в zip архиве):

XDevLite = ~1,5 Mb
ZXDev = ~3,5 Mb

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

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

Люди, которые предпочитают "не маргинальные" средства разработки, вообще не воспринимают их недостатков, т.к. ослеплены их достоинствами. С ними безполезно говорить о том, что C# плох для риэлтайма или микроконтроллеров, что это язык одной фирмы и его будущее зависит от этой фирмы. И ещё кучу всего. Точно также в штыки они воспринимают достоинства других средств, с которыми не планируют работать.

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

А фраза про упырюгу предназначалась крыске. И когда это он успел удалить свою мессагу. Я щас ту тогда тоже отредактирую.

Цитата:

---

Сообщение от Oleg N. Cher

Делу распространения Оберона мешают не засланцы из Лондона, а принцип "своя рубашка ближе к телу", которого мы все аккуратно придерживаемся.

---

Так точно. Это форум про ретро-компьютеры. Местным обитателям в большинстве своем ближе то, что было во времена их увлечения. Оберона не было. Все логично.

Цитата:

---

Сообщение от Oleg N. Cher

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

---

Олег, не надо тут сравнивать интеерс нашего увлечения с пускающими слюни дитем-олигофреном. Это форум не про лучший язык программирования. Это форум про компьютеры, которые были популярны 20 +- лет назад. Попытки настойчивого продвижения таких вот "гениев математики" всегда будут восприниматься тут именно так.

Цитата:

---

Сообщение от Oleg N. Cher

Люди, которые предпочитают "не маргинальные" средства разработки, вообще не воспринимают их недостатков, т.к. ослеплены их достоинствами. С ними безполезно говорить о том, что C# плох для риэлтайма или микроконтроллеров, что это язык одной фирмы и его будущее зависит от этой фирмы. И ещё кучу всего. Точно также в штыки они воспринимают достоинства других средств, с которыми не планируют работать.

---

Ну да, тут, кончено,все подряд только и делают, что сравнивают Spectrum Basic с C#, ассемблер Z80 и современного PIC и выбирают на чем из этого завтра начать коммерческий стартап или новый проект на работе :) Это была ирония, если что.

Цитата:

---

Сообщение от Oleg N. Cher

Но в отношении моего детища (ZXDev) ты выступил разрушителем, хотя может и нечаянно.

---

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

Цитата:

---

Сообщение от Alex Rider

Олег, задумайся еще раз о способе подачи информации здесь.

---

Вот тут я пожалуй скажу, что с этим то проблем нет.
Разве Олег не свою тему создал внутри "Программирование" ?
Это его авторская тема, мне (к примеру) его посты и не только его очень даже
интересно почитать, ПКМ на форуме есть что почитать в принципе
(свежий воздух как бы + не хилый такой вызов для завуалированного сайбернетика
где-то глубоко внутри меня), пока в разделе ДВК\УК-НЦ и эмуляторов затишье (но это временно).
Плохо то, что некоторые товарищи не могут мимо пройти,
молча в смысле. Что то им мешает. (вот не дождётесь перехода на личности!).
Хорошо то, что есть люди кому интересно и которые тоже пишут
свои мысли.

У меня слегка не по теме вопрос, просто связан с Модулой2, нет ли среди участников тех кто работал\пользовался компилятором языка на ЭВМ ДВК? Нужна помощь пока официального описания нет, по правильной настройке и использованию компилятора? Советы какие нибудь и примеры простых программ - всё вместе )
http://zx-pk.ru/showthread.php?t=20444 - pascal+macro11
http://zx-pk.ru/showthread.php?t=22278 - modula2

Спасибо.
:wink:

Цитата:

---

Сообщение от Alex Rider

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

---

Давай не будем считать твоё мнение всеобщим, ладно?

Это во-первых. Во-вторых, мы с тобой знаем отчего именно у тебя возникло такое неприятное отторжение. Оттого что я критиковал твою предвзятость. А каким ещё словом, кроме "предвзятость" можно назвать высказывание в стиле "я думаю, тут надо подкрутить миллион конфигов и оно всё равно не запустится", вместо того чтобы просто взять и попробовать.

В-третьих, я могу даже убраться отсюда, раз так уж сильно мешаю и выбиваюсь из общей струи. Всегда есть форум zx.oberon2.ru/forum. А данный форум будет ещё более кошерным для тебя и твоих сотоварищей.

Скачал среду, изучаю. Протестуещие пусть идет лесом, хорошая вешь. Это ж практически паскаль.

Цитата:

---

Сообщение от Kakos_nonos

Скачал среду, изучаю. Протестуещие пусть идет лесом,

---

квартира готова?:)

Цитата:

---

Сообщение от Oleg N. Cher

Сообщение от Reobne
2. При нажатии F11 возникла ошибка "command error: object OfrontOPM.MaxStruct inconsistently imported from OfrontOPC" Что это?
Данную ошибку в репозитории я уже починил, а заключалась она в том, что я увеличил константу - максимальную длину идентификатора, но не пересобрал модули, которые зависели от этой константы. BlackBox такую ошибку легко определяет и очень часто это помогает экономить время.

---

Я тоже пробовал ZXDev на днях, но эта же ошибка выскочила. Опять буду пробовать.

---------- Post added at 10:24 ---------- Previous post was at 10:23 ----------

Если разберусь, то библиотеки на асме могу потом делать потихоньку

Цитата:

---

Сообщение от denpopov

квартира готова?

---

Одну уже TS-Labs'у подарил, сейчас в поиске другой. Кстати, если скрестить ТСконфу и эту среду, думаю крутотень выйдет. Отрисовкой спрайтов будет не тормознутый код занимться а железо, а логику игры в оберон (или модулу, она мне как-то больше приглянулас)

Цитата:

---

Сообщение от Andrew771

Если разберусь, то библиотеки на асме могу потом делать потихоньку

---

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

Цитата:

---

Сообщение от Andrew771

Вопрос пока, как будут передаваться параметры процедур из Оберона в асм

---

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

Во, наконец получилось скомпилить файл ASCII.mod.

Исходный Оберон:

Код:

---

MODULE ASCII; (*$MAIN*)
IMPORT Console;
VAR
        n: INTEGER;
BEGIN
        FOR n := 32 TO 127 DO Console.WriteCh(CHR(n)) END;
END ASCII.

---

Скомпилировалось в:

Код:

---

        .area _GSINIT
;--------------------------------------------------------
; Home
;--------------------------------------------------------
        .area _HOME
        .area _HOME
;--------------------------------------------------------
; code
;--------------------------------------------------------
        .area _CODE
;ASCII.c:14: export main(int argc, char **argv)
;        ---------------------------------
; Function main
; ---------------------------------
_main_start::
_main:
;ASCII.c:20: ASCII_n = 32;
        ld        iy,#_ASCII_n
        ld        0 (iy),#0x20
        ld        iy,#_ASCII_n
        ld        1 (iy),#0x00
;ASCII.c:21: while (ASCII_n <= 127) {
00101$:
        ld        a,#0x7F
        ld        iy,#_ASCII_n
        cp        a, 0 (iy)
        ld        a,#0x00
        ld        iy,#_ASCII_n
        sbc        a, 1 (iy)
        jp        PO, 00114$
        xor        a, #0x80
00114$:
        jp        M,00103$
;ASCII.c:22: Console_WriteCh((CHAR)ASCII_n);
        ld        iy,#_ASCII_n
        ld        h,0 (iy)
        push        hl
        inc        sp
        call        _Console_WriteCh_COMPACT
        inc        sp
;ASCII.c:23: ASCII_n += 1;
        ld        iy,#_ASCII_n
        inc        0 (iy)
        jr        NZ,00101$
        ld        iy,#_ASCII_n
        inc        1 (iy)
        jr        00101$
00103$:
;ASCII.c:25: __FINI;
        ld        hl,#0x0000
        ret
_main_end::
        .area _CODE
        .area _INITIALIZER
        .area _CABS (ABS)

---

Это оптимально?
И что за строки типа .area _CODE?
Это не будет работать на асме.

Цитата:

---

Сообщение от Andrew771

cp a, 0 (iy)

---

что это? оО

Цитата:

---

Сообщение от Andrew771

Это оптимально?

---

Нет.

Цитата:

---

Сообщение от denpopov

что это? оО

---

Код:

---

cp (iy+0)

---

Ну да SDCC дает не самый оптимальный код. мягко говоря.
О чем и писалось в соседних ветках.

я бы использовал

Код:

---

cp (hl)

---

но код портировали с 6502 потому и IX и IY

ну и то что он использует WORD вместо CHAR тоже неправильно.

ну и смысл всё это использовать?

---------- Post added at 13:34 ---------- Previous post was at 13:32 ----------

или там где-то опять настройками sdcc играться? :)

Цитата:

---

Сообщение от jerri

Ну да SDCC дает не самый оптимальный код. мягко говоря.

---

SDCC может и такой код выдать:

Код:

---

;main.c:15: for(n=32;n<128;n++)
        ld        h,#0x20
00106$:
;main.c:16: Console_WriteCh(n);
        push        hl
        push        hl
        inc        sp
        call        _Console_WriteCh
        inc        sp
        pop        hl
;main.c:15: for(n=32;n<128;n++)
        inc        h
        ld        a,h
        sub        a, #0x80
        jr        C,00106$

---

Цитата:

---

Сообщение от Blade

SDCC может и такой код выдать

---

это где опции крутить?

У меня получилось так:

Исходный Оберон:

Код:

---

MODULE ASCII; (*$MAIN*)
IMPORT Console;
VAR
        n: SHORTINT;
BEGIN
        FOR n := 32 TO 127 DO Console.WriteCh(CHR(n)) END;
END ASCII.

---

Скомпилировалось в:

Код:

---

_main_start::
_main:
        push        ix
;ASCII.c:20: ASCII_n = 32;
        ld        hl,#_ASCII_n + 0
        ld        (hl), #0x20
;ASCII.c:22: ASCII__for__1 = (ASCII__for__1 - ASCII_n) + 1;
        ld        hl,#_ASCII__for__1 + 0
        ld        (hl), #0x60
;ASCII.c:23: do {
00101$:
;ASCII.c:24: Console_WriteCh((CHAR)ASCII_n);
        ld        a,(#_ASCII_n + 0)
        push        af
        inc        sp
        call        _Console_WriteCh_ROM
        inc        sp
;ASCII.c:25: ASCII_n += 1;
        ld        hl, #_ASCII_n+0
        inc        (hl)
;ASCII.c:26: ASCII__for__1 -= 1;
        ld        hl, #_ASCII__for__1+0
        dec        (hl)
;ASCII.c:27: } while (!(ASCII__for__1 == 0));
        ld        a,(#_ASCII__for__1 + 0)
        or        a, a
        jr        NZ,00101$
;ASCII.c:28: __FINI;
        ld        hl,#0x0000
        pop        ix
        ret
_main_end::

---

Немножечко "догнал" опцией --oldralloc, немножечко можно попробовать реализацией FOR от Saferoll (впрочем, прироста именно в этом случае не даёт). Немножечко отказом от OUTPUT_COMPACT в пользу OUTPUT_ROM. Итоговая TAP'ка весит 198 байт.

Цитата:

---

Сообщение от Andrew771

И что за строки типа .area _CODE?

---

Директива секции кода, встроенная в SDCC-асм.

Цитата:

---

Сообщение от Andrew771

ну и смысл всё это использовать?

---

Сделай лучше. Потихоньку. ;)

Цитата:

---

Сообщение от Kakos_nonos

(или модулу, она мне как-то больше приглянулас)

---

Чем планируем транслировать Модулу в код Z80?

Как мне избавиться от индексного регистра iy и скомпилировать, как у тебя, с регистром hl :)

---------- Post added at 13:55 ---------- Previous post was at 13:54 ----------

и чтобы бредятина типа .area сама выкидывалась

Жосткая оптимизация - 192 байта. ;)

Код:

---

MODULE ASCII; (*$MAIN*)
IMPORT Console;
VAR
        n: SHORTINT;
BEGIN
        n := 3*32; REPEAT Console.WriteCh(CHR(3*32-n+32)); DEC(n) UNTIL n = 0;
END ASCII.

---

Можно и ещё меньше конечно.

---------- Post added at 13:02 ---------- Previous post was at 12:57 ----------

Цитата:

---

Сообщение от Andrew771

Как мне избавиться от индексного регистра iy и скомпилировать, как у тебя, с регистром hl :)

---

Сам не пойму, то с hl компилит, то с iy. Попробуй поиграться с опцией --reserve-regs-iy

--reserve-regs-iy This option tells the compiler that it is not allowed to use register pair iy.The option can be useful for systems where iy is reserved for the OS.

However in general, the use of ix may depend on --reserve-regs-iy: sdcc should try to generate good code. And sdcc might decide whether using ix is a good idea depending on whether iy is available: When there are few accesses to the stack, sdcc might decide to not use ix, and instead access the stack using hl and iy only. But if iy is not available, sdcc will be more likely to decide to use ix for accessing the stack. The option for forbidding the use of ix is --fomit-frame-pointer (which in your case might be a usable workaround for the issue).

Цитата:

---

Сообщение от Andrew771

и чтобы бредятина типа .area сама выкидывалась

---

Да не надо её выкидывать, она не мешает. Это асм такой. Разве только прикрутить к SDCC другой асм, но смысл?

а .Mod файлы в архиве это не модула?

Нет, это тоже Оберон. Придумаем как транслировать Модулу - будет поддержана и Модула.

Цитата:

---

Сообщение от Blade

SDCC может и такой код выдать:

Код:

---

;main.c:15: for(n=32;n<128;n++)
        ld        h,#0x20
00106$:
;main.c:16: Console_WriteCh(n);
        push        hl
        push        hl
        inc        sp
        call        _Console_WriteCh
        inc        sp
        pop        hl
;main.c:15: for(n=32;n<128;n++)
        inc        h
        ld        a,h
        sub        a, #0x80
        jr        C,00106$

---

---

Круто, чо.
весь вопрос КАК?

---------- Post added at 14:20 ---------- Previous post was at 14:13 ----------

Цитата:

---

Сообщение от Oleg N. Cher

У меня получилось так:

Исходный Оберон:

Код:

---

MODULE ASCII; (*$MAIN*)
IMPORT Console;
VAR
        n: SHORTINT;
BEGIN
        FOR n := 32 TO 127 DO Console.WriteCh(CHR(n)) END;
END ASCII.

---

---

объявление переменной вижу я :)

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

denpopov, его не надо причесывать, его надо использовать.
тут сам принцип - не писать на асме а программировать на ЯВУ.
но конечно для начала надо настройки выставить чтобы SDCC создавало что-то приемлемое. раз уж автор за этим не следил.