Неееет..:v2_crazy:
Дружище, не торопись, сядь и спокойно во всём разберись. (с) pr-mex
imho, для разработки на спектрум любой ЯВУ использовать не эффективно.
Неееет..:v2_crazy:
Дружище, не торопись, сядь и спокойно во всём разберись. (с) pr-mex
imho, для разработки на спектрум любой ЯВУ использовать не эффективно.
Не только. :)Цитата:
Сообщение от Oleg N. Cher
http://techtinkering.com/2013/03/12/...ula-2-for-cpm/
Смотря что писать. Пошаговки, квесты, логика и двумерные лабиринты можно на ЯВУ.Цитата:
Сообщение от SaNchez
Ответственно заявляю, господа, что я окончательно решил забить на идею превратить Оберон в Модулу-2 добавлением беззнаковых типов и т.п. CP/M-ная Модула конечно хорошо, но наверное лучше будет найти транслятор Модулы-2 в Си и пойти стопами ZXDev. Но это для гурманов. Я же решил выпилить рудиментарную поддержку беззнаковых типов в Ofront'е (они всё равно глючат) и перевести ZXDev в статус исследовательского проекта. Вы же уже убедились, что своими скромными силами сделать продвинутые библиотеки я не смогу. Также забиваю на юзеров ZXDev, их всё равно нет, продолжу проект чисто для себя.
Вот это поворот! Прогрессивнейший, мощнейший язык и тут такой прокол...Цитата:
Сообщение от Oleg N. Cher
Тем более чудесен факт создания этой мощной среды. Не отчаивайтесь.Цитата:
Сообщение от Oleg N. Cher
Какой смысл превращать Оберон в Модулу, ведь это всё равно не Си, на котором можно писать как на асме. На ZX ниша Оберона такова - ни больше, ни меньше:
Цитата:
Сообщение от boo_boo
Взял в твоем дистрибутиве демо-программу Kubik и переписал на Паскале. Выкладываю обе в архиве: исходники, асмы и скомпилированные в ZXDev и ZX Like Pascal, сравниваем.Цитата:
Сообщение от Oleg N. Cher
Andrew771, чота как то неравномерно.
там просто считалка с простым выводом
а тут и на скорость наворочено и фонт добавлен на 64.
по видимому, в ZXDev используются подпрограммы из ПЗУ или из отдельной библиотеки, в тексте асма их нет.Цитата:
Сообщение от jerri
Этот Kubik построен на выводе, реализованном в библиотеке Basic (исходник лежит в ZXDev/Lib/C/Basic.c). По умолчанию используется стандартный вывод (RST #10) - для экономии памяти. Чтобы увеличить скорость вывода, закомментируем в ZXDev/Lib/BasicCfg.h:
//#define ROM_OUTPUT
( каждый модуль, не использующий общий конфигуратор, может иметь свой собственный - в папке Obj/ИмяМодуля )
Теперь достаточно пересобрать (F12).
Отчасти заметил, что ZX-like Pascal иногда даёт более эффективный код, чем SDCC, и с этим не собираюсь спорить. Браво.
Вывод разными шрифтами я не реализовал, как-то не понадобилось.
Кстати, в этой программе kubik неэффективно сделан вывод на экран, зачем-то каждая строка выводится отдельными операторами. Можно было в цикле. Но зато выявилось преимущество SDCC - он не повторяет в данных одинаковые строки, а ZX Like повторяет. В общем, доработаю это у себя.
Надо отдать должное, - у ZX Like Pascale код гораздо чище, чем у SDCC.Цитата:
Сообщение от Andrew771
Kubik написан (под моим руководством конечно) моей племянницей, отсюда неоптимальности.
Андрей, чтобы не было вот такого:
советую сделать “слово состояния процессора”. И вот ещё идеи по оптимизации.Код:ld hl,0
ld (_ONE),hl
ld hl,0
ld (_TWO),hl
ld hl,0
ld (_THREE),hl
Ну что, Олег, - навостряй лыжи прикручивать к ZXDev ZX Like Pascal ;)Цитата:
Сообщение от Oleg N. Cher
Если видите какие-то преимущества слияния проектов, возражений нет, однако я предпочитаю открытый софт - его легче сопровождать и дорабатывать.
Замечу, что в SDCC реализованы более сложные оптимизации, чем в ZX-Like Pascal.
Sergey, накопились вопросы по HiTech C, если можно.
- Не нашёл откуда качать HiTech C v3.09 для DOS.
- Есть ли какие-либо преимущества от использования DOS-версии перед CP/M-версией? (например, можно ли задавать пути? - ведь в CP/M нет каталогов и всё должно быть свалено в одну кучу).
- Тестировались ли более свежие (хоть и платные) версии HiTech C для Z80? (у них может быть ещё более качественный кодогенератор).
Забудь, версии под дос не существует.Цитата:
Сообщение от Oleg N. Cher
Ввиду отсутствия первой - никаких. Да, в в CP/M я храню исходные тексты на одном диске с дистрибутивом HiTechC. Скорее всего, можно разнести на разные "диски" - не пробовал пока. Можно скриптами перед компиляцией копировать к файлам проекта эмулятор CP/M и необходимые cp/m-программы и др.файлы, а после компиляции - удалять их.Цитата:
Сообщение от Oleg N. Cher
Я не тестировал, т.к. ничего недоступно.Цитата:
Сообщение от Oleg N. Cher
Глазок оптимизатор, который поставляется с SDCC является достаточно мощным и может быть использован для улучшения вывода SDCC в значительно.Цитата:
Сообщение от Oleg N. Cher
SDCC имеет ряд недостатков: он не может справиться с статика, длинных или плавает эффективно. Статика особенно важно, потому что лучшее исполнение Z80 происходит от их использования в предпочтении к локальным переменным, когда разумно. Но это не случай с SDCC - использование статики приводит к плохой код. Во всяком случае, эти проблемы могут быть решены с помощью щелевого оптимизатора, и мы делали, что в z88dk. Если вы используете SDCC через z88dk качество кода гораздо лучше.
Другая проблема SDCC имеет это относится к z80 как чистый 8-битный процессор и, в основном игнорирует свои 16-битные инструкции. Опять мы можем попытаться исправить, что в peepholer но мы не всегда можем это сделать. SDCC иногда меняет порядок байт в коде, который не легко исправить.
Посмотрите на состояние вещей в настоящее время при использовании SDCC через z88dk:
https://drive.google.com/file/d/0B6X...ew?usp=sharing
Эта программа вычисляет пи до 800 знаков после запятой, и мы используем его для сравнения 32-битной целочисленной арифметики. Оба выходной файл ASM были составлены с использованием SDCC z88dk библиотеки. "пи-sdcc.opt" код, который генерирует SDCC сам по себе. "пи-z88dk.opt" это код после z88dk применяет свои правила, чтобы улучшить его. Это гораздо лучше, и это почти все из щелевого оптимизатора SDCC в.
Кроме стороне генерации кода, нет никакой другой компилятор Z80 С, что делает столько оптимизации в переднем конце. Это только генерацию кода и библиотек (написанный на C), которые весом вниз SDCC.
Скрытый текст
The peephole optimizer that comes with sdcc is quite powerful and can be used to improve sdcc's output considerably.
sdcc has a number of weaknesses: it can't deal with statics, longs or floats efficiently. Statics are especially important because the best z80 performance comes from using them in preference to local variables when reasonable. But that's not the case with sdcc -- use of statics leads to poor code. Anyway, these problems can be fixed by the peephole optimizer and we've been doing that in z88dk. If you use sdcc through z88dk the code quality is much better.
The other problem sdcc has is it treats the z80 like a pure 8-bit processor and mostly ignores its 16-bit instructions. Again we can try to fix that in the peepholer but we can't always do that. sdcc sometimes swaps endianness in code which is not easy to fix.
Have a look at the state of things now when using sdcc through z88dk:
https://drive.google.com/file/d/0B6X...ew?usp=sharing
This program computes pi to 800 decimal places and we use it to benchmark 32-bit integer arithmetic. Both asm output file were compiled with sdcc using the z88dk libraries. "pi-sdcc.opt" is the code that sdcc generates by itself. "pi-z88dk.opt" is the code after z88dk applies its rules to improve it. It's much better and this is almost all due to sdcc's peephole optimizer.
Apart from the code generation side, there is no other z80 C compiler that is doing as much optimization in the front-end. It's just the code generation and libraries (written in C) that are weighing down sdcc.
[свернуть]
Hitech С v3.09 еще, кажется, отстают в бенчмаркинга:Цитата:
Sergey, накопились вопросы по HiTech C, если можно.
- Не нашёл откуда качать HiTech C v3.09 для DOS.
http://www.z88dk.org/wiki/doku.php?i...#dhrystone_2.1
Там не было более поздней версии V7 для DOS, но я не могу найти его, и это больше не продается, насколько я знаю.
Скрытый текст
Hitech C v3.09 still seems to fall behind in benchmarking:
http://www.z88dk.org/wiki/doku.php?i...#dhrystone_2.1
There was a later version v7 for dos but I cannot find it and it's no longer being sold as far as I know.
[свернуть]
Исходник ZX Like Pascal положил тутЦитата:
Сообщение от Oleg N. Cher
Чем Компонентный Паскаль отличается от Оберона-2?
КП позиционируется как диалект (фактически надмножество) Оберона-2 для промышленного применения. Прикладному программисту КП покажется более удобным и фичастым. Некоторые приятные мелочи, как: IN/OUT параметры процедур, расширенная работа с битами. Главная фича КП, отсутствующая в О2, - реализация абстрактных интерфейсов.
Имеется 2 реализации КП: BlackBox Component Builder (Windows/Linux) и GPCP (.NET/JVM). Последний ещё более расширен: добавлена обработка исключений, новые типы и т.д. Также в XDev реализованы некоторые возможности языка КП.Цитата:
Сообщение от wikipedia
Рекомендую относиться к О2/КП как к "ассемблеру ООП", т.е. с точки зрения фичь они проигрывают C#/Java. Среды разработки на О, О2, AO, КП - чаще всего не классические IDE + отладчик (хотя встречаются и такие), и с этой точки зрения тоже проигрывают.
А ещё есть Модула-2 и Модула-3. Тоже хорошие языки. Даже несколько больше и фичастее Оберона, но намного меньше Ada/C++.
Андрей, благодарю, что ты решился.Цитата:
Сообщение от Andrew771
Практика показывает, что страх потерять контроль над разработкой, открыв исходники, - неоправдан. Честно. Взамест проект может приобрести более конструктивную и качественную критику (уже на основе взгляда на код), новых участников и новую жизнь. А может и не приобрести. Как повезёт. У наший с тобой проектов потенциальная аудитория маловата, увы. Мои самые лучшие юзеры, как правило, уходили непонятно куда. Вот и Руслан в теме испрашивал что-то вроде лазер бейсик, а что может быть ближе к Laser Basic, чем ZXDev + библиотека Laser? Я ему даже засмартлинковал (порезал на части) библиотеку Laser, потратил на это несколько дней. Очень кропотливая работа. Хотя по-честному его целиком переписывать надо. С учётом новых достижений кодерской мысли. Но то мечты, а это уже реальная отлаженная библиотека. Но, упс, получается, зря делал.
мх.. станное понятие абстрактный интерфейс, есть понятие интерфейс, синоним абстрактноного класса.Цитата:
Сообщение от Oleg N. Cher
Но! реальная польза от него появляется при наличии множественного наследования, речь не о множественном наследовании реализации как в с++ а именно множественное наследование интерфейсов
Т.е. я могу пометить класс что он IComparable и реализовать это поведение и у меня автоматом, разного рода сортируемые коллекции смогут работать с моим классом
Могу так же сказать что этот же класс является наследником интерфейса IPersistentObject, говоря тем самым что мой объект умеет сохранять состояние, в довесок еще помечаю его интерфейсом, IGrantedAccess который говорит к примеру что при показе юзеру этого объекта, нужно проверять права доступа.
Т.е. нет сложного момента как множественного наследования поведения, но в тоже время, могу описывать классу разное поведение, причем не кучу поведения от сложного супер класса, а разного рода мелкие поведеня
- - - Добавлено - - -
в zonnon такое поведение реализовано, но мотив скорее всего, что бы можно было нормально .net библиотеку юзать
ОК, предположим, я неверно выразился.
Абстрактный интерфейс — т.е. оторванный от реализации. Может иметь одну или несколько реализаций. "Класс" говорим по аналогии, потому-что в Обероне это всё-таки запись (RECORD). Поэтому я говорю не "класс", а "интерфейс" [модуля]. Можно "абстрактная запись".
- Что такое компонентно-ориентированное программирование (краткая справка)
Цитата:
Можно сказать, что КОП — это такое ООП, которое подчинено требованиям безопасности "старого" структурного и модульного программирования примерно в том виде, в каком эти требования были реализованы в классической Модуле-2 (в отличие от языков типа Smalltalk, в которых ООП является основным механизмом, который применяется без ограничений).
Краткое обсуждение компонентно-ориентированного программирования дано в http://www.oberon.ch/resources/compo...tware/cop.html (эту статью надо бы перевести на русский язык). Из статьи следует примерно такая формула для КОП:
КОП = ООП
+ модульность (включая упрятывание информации и позднее связывание модулей, т.е. возможность подгружать необходимые модули в процессе выполнения программы, а не заранее, как это обычно делается в старых системах программирования)
+ безопасность (статический контроль типов переменных и автоматическое управление памятью)
- наследование реализации через границы модулей.
Последняя строчка означает, что в КОП запрещено наследование от типов, реализованных в других модулях; наследовать можно только абстрактным, чисто интерфейсным типам (помеченных атрибутом ABSTRACT в Компонентном Паскале).
Между прочим, Оберон-2 не удовлетворяет в полной мере требованиям КОП: в нём любой тип может быть расширен. Это делает программы, написанные на нём, уязвимыми для проблемы хрупких базовых классов. Именно для устранения этой "дыры" в системе безопасности Оберона-2 и были в первую очередь предприняты модификации языка, реализованные в Компонентном Паскале.
В классическом Обероне тоже можно расширять любой тип, но там нет методов, так что и проблема менее остра.
- https://ru.wikipedia.org/wiki/Компонентно-ориентированное_программи ование
Цитата:
Сообщение от wikipedia
Новости по проекту.
1. ZXDev окончательно решено перевести на z88dk-SDCC. Это придаст ему ряд дополнительных возможностей, особенно в плане использования z88dk’шных библиотек (Hello, Alcoholics Anonymous!).
2. Раз уж все разобрались, чем отличается Компонентный Паскаль от Оберона-2, сообщаю, что мне удалось достать фирменный транслятор КП-в-Си от Oberon microsystems (на базе Ofront’а), и теперь основным языком разработки в XDev будет Компонентный Паскаль. Оберон-2 также будет в списке поддерживаемых языков.
Разумеется, это не настолько важно именно для ZXDev — для Z80 Оберон-2 будет даже предпочтительнее, ибо в КП фиксированная арифметика (все вычисления производятся в 32 бит/64 бит, и потом только приводятся к требуемому типу), т.е. на О2 складывание чисел типа SHORTINT — задача вполне в рамках SHORTINT. КП же считает, что возможно переполнение и требуется бОльшая разрядность. Поэтому результат — типа INTEGER, и уже потом приводится к SHORTINT, если требуется.
3. Сообщаю, что от души наигрался с компиляторами типа tcc/DJGPP и теперь окончательно перевожу WinDev на GCC/MinGW. GCC тоже умеет делать компактные exe/dll (для этого следует использовать свой crt1) — и Hello World получается 1,5 кб. На сегодняшний день в WinDev есть биндинги к WinApi, SDL, SDL 2, LibC. Можно успешно делать проекты типа небольших утилит. Пример сделанного в WinDev:
С этими изменениями XDev начинает приобретать качества промышленного продукта, хотя ему по-прежнему очень не хватает систематичного подхода к разработке. Просто много рутины, которая делается в “ленивом” режиме по мере надобности.
4. XDev для Linux. Может быть получен на основе Freenix, вышеупомянутого транслятора КП-в-Си и GCC. С помощью подсистемы Master будет доступна раскраска синтаксиса. Толковый программист при соответствующей мотивации собрал бы всё это воедино за очень небольшой срок. Проблема с мотивацией — мне вполне хватает XDev для Windows. К тому же я взялся и так за слишком большой проект, и мэйнтейнить две версии, вторая из которых мне напрямую не нужна, представляется излишней роскошью. Но всё возможно, требуются лишь энтузиасты, чтобы продвигать это направление.
https://msdn.microsoft.com/en-us/vst...netnative.aspxЦитата:
Сообщение от MS
У меня вопрос к дотнетоведам. Риторический. Если у технологии .NET всё так замечательно, то какой смысл в такого рода приблудках как эта? Сначала создали себе сложность в виде VM, но потом её героически преодолели? ;)
VM у явы, дотнет с рождения JITЦитата:
Сообщение от Oleg N. Cher
.net native для игрушек и телефонов, там где побочка управляемого кода особенно заметна, производительность транслированного и обычного приложения в среднем одинакова, но для PC лишние 20Ватт энергии и лишние 20% обычно незаметны
Сделать побыстрее запуск на медленных устройствах. Кроссплатформенность бинарника при этом теряется, но остальные фишки .NET - безопасность кода и, собственно, библиотека классов остаются. Исходный код также остается кроссплатформенным.Цитата:
Сообщение от Oleg N. Cher
Насколько я понимаю, безопасность кода и натив аж никак не мешают друг другу существовать вместе. И для этого не нужны никакие VM.
Исходный же код - не кросс, а именно моноплатформенный (.NET only), и никак иначе. Да, это можно сэмулировать на других платформах, но толстым способом.
Правильно. VM нужны для кроссплатформенности (целевой) на этапе исполнения. .NET помимо этого дает еще много плюшек, например, безопасность, библиотеки, многоязычность, популярность (в частности, довольно мощное комьюнити). .NET Native отбирает у скомилированного бинаря только целевую кроссплатформенность, оставляя все остальные плюшки. Это неплохо.Цитата:
Сообщение от Oleg N. Cher
Олег, с тобой бесполезно спорить. Не выставляй себя недалеким - ты же прекрасно знаешь, что не существует платформы .NET, и что сборки .NET не эмулируются, правда?Цитата:
Сообщение от Oleg N. Cher
CoreCLR, уже работает на маках, линухах итд, от MS
Можно сказать это еще один Mono но от MS
А именно это и не замечательно. JIT-компилятор в дотнете слабый и тупой. Вот, скажем, 10 лет назад все плевались и от Java-, и от .NET-экзешников, когда они стартовали целую минуту и еле ворочались. Сейчас джава это практически полностью преодолела за счет крутого интеллектуального JIT. Дотнет же как тормозил при старте, так и тормозит. Просто на современном железе это однократное торможение при первом запуске практически незаметно, а вот на задачах, для которых создан .NET Native, разница, видимо, есть.Цитата:
Сообщение от Oleg N. Cher
Что же тогда .NET если не платформа? Фреймворк? Набор классов?Цитата:
Сообщение от Alex Rider
И я не говорил, что сборки эмулируются. Программная платформа .NET эмулируется поверх аппаратной (Windows, Linux, Mac etc). И даже после трансляции в натив приходится таскать с собой всю платформу - её классы, метаинформацию, нужную для их работы, и т.д.
Ещё непонятно:
А я считал, что .NET это тоже VM, а у JVM тоже есть JIT-компилятор. И вот приходится блуждать в таких высказываниях людей, которых я считаю опытными дотнетовцами и джавистами.Цитата:
Сообщение от s_kosorev
В общем, что ни говори, подход Slim Binaries выглядит технологически совершеннее. Но по факту ещё долго будут доминировать плохие реализации древнего пи-кода. Придуманного, кстати, проф. Виртом для его Паскаля.
Олег, Windows и Linux - это программные платформы. Аппаратные - это ARM, x86, x64. На аппаратной платформе исполняются ОС, в которые может быть установлен набор библиотек и специальная среда исполнения, которая компилит сборки .NET в нативный исполняемый код целевой аппаратной платформы.Цитата:
Сообщение от Oleg N. Cher
Некоторые программно-аппаратные платформы, например, носимые устройства, имеют производительность, недостаточную для комфортного запуска .NET приложений с предкомпиляцией впервые исполняемого кода. Для решения этой проблемы был придуман .NET Native. И не более.
- - - Добавлено - - -
По поводу VM - не VM. Как сейчас дела у Java обстоят, я не в курсе, но .NET никогда не эмулировал IL-код сборок на целевой платформе, он его всегда компилировал (JIT-компилятором) в нативный код и исполнял непосредственно на процессоре. За это в .NET отвечает CLR - Common Language Runtime (программная среда исполнения .NET-кода).
в .net штатно можно работать с памятью, указатели, запрос памяти у операциоки итд, т.е. после jit будет не JNI шлюзы а очень часто обычный callЦитата:
Сообщение от Oleg N. Cher
тобиш результат дотнета это не процес в какой то виртуальном окружении, а обычный процесс ну с библиотечками разными, ну проверок больше чем хотелось бы
на C#
листинг на ассемблереКод:class Program
{
[DllImport("kernel32.dll")]
static extern IntPtr GetConsoleWindow();
[DllImport("user32.dll")]
static extern bool ShowWindow(IntPtr hWnd, int nCmdShow);
const int SW_HIDE = 0;
const int SW_SHOW = 5;
static void Main(string[] args)
{
var handle = GetConsoleWindow();
ShowWindow(handle, SW_HIDE);
Console.Read();
}
}
если пошагать, то вызов нативных методов как раз в ядро винды уходят после линковкиКод:var handle = GetConsoleWindow();
00000000 push ebp
00000001 mov ebp,esp
00000003 sub esp,14h
00000006 xor eax,eax
00000008 mov dword ptr [ebp-0Ch],eax
0000000b mov dword ptr [ebp-10h],eax
0000000e mov dword ptr [ebp-14h],eax
00000011 mov dword ptr [ebp-4],ecx
00000014 cmp dword ptr ds:[0215C730h],0
0000001b je 00000022
0000001d call 5DD39FEF
00000022 xor edx,edx
00000024 mov dword ptr [ebp-8],edx
00000027 call FFFFF8B0
0000002c mov dword ptr [ebp-0Ch],eax
0000002f mov eax,dword ptr [ebp-0Ch]
00000032 mov dword ptr [ebp-8],eax
ShowWindow(handle, SW_HIDE);
00000035 mov ecx,dword ptr [ebp-8]
00000038 xor edx,edx
0000003a call FFFFF8BC
0000003f mov dword ptr [ebp-10h],eax
00000042 nop
Console.Read();
00000043 call 5D1EF8EC
00000048 mov dword ptr [ebp-14h],eax
0000004b nop
}
У нас тут со Smalovsky случился приватный разговор, в котором от утверждает, что:
На что я хочу ответить публично, вдруг кто-то тоже так думает.Цитата:
Сообщение от Smalovsky
Oxygene - наследник Delphi и наследует его традиции, в т.ч. и сложность. Это большой современный язык, на который оказали влияние C# и другие новые языки. То есть шаг в сторону усложнения. И попытка "из коробки" дать юзеру мощный инструмент для разработки под актуальные платформы.
Компонентный Паскаль - напротив, очень маленький и простой язык. С поддержкой новых платформ у него туго. Фактически есть всего два компилятора КП - BlackBox Component Builder (в код x86-32) и Gardens Point Component Pascal (в байт-код JVM и .NET). Если хочется современных фич и плюшек, 64-битности, то упс. Впрочем, наш Оберон-клуб в этом смысле впереди планеты всей, и у нас есть транслятор КП в Си, сделанный фирмой Oberon microsystems на базе того же Ofront. Пользуйтесь. Если разберётесь.
Дайте угадаю. Вы считаете, что Оберон - это такой старый архаичный язык, который умер 30 лет назад. А КП - это что-то современное. Спешу обрадовать. Знаете чем отличается Component Pascal от Oberon-2 ? Я не поленюсь перечислить. Атрибутами процедур NEW/ABSTRACT/LIMITED/EXTENSIBLE, модификаторами параметров IN/OUT, дополнительной операцией $ для строк, парочкой новых типов, функцией BITS() и ВСЁ. Извините, если чего упустил. Компонентный Паскаль - это очень слегка прилизанный Оберон-2. Подчёркиваю: очень слегка.
Кстати, я в трансляторе Ofront+ использую фичи из КП.
Можно ли программировать на КП для Z80? Можно. На подмножестве. Транслятор КП в Си добавляет слишком много мета-информации к модулям, это нужно для фишек, к которым привыкли юзеры C#, таким как: узнать на лету типы и поля структуры и т.п. Так что для Z80 видится разумным использовать не КП, а именно тот самый Oberon-2 с некоторыми фичами из КП, реализованный в трансляторе Ofront+.
Чтобы ещё раз подчеркнуть минимальность различий КП и Оберона-2 я покажу вам два исходника, которые написаны так, что собираются как компилятором GPCP (Gardens Point Component Pascal) для JavaME, так и транслятором ZXDev/Ofront+ для Спектрума:
• https://github.com/Oleg-N-Cher/Dash/...d/Labirint.Mod
• https://github.com/Oleg-N-Cher/DarkW.../DarkWoods.Mod
Я вклинюсь в разговор. Оберон на xilinx 2016г
http://www.astrobe.com/RISC5/default.htm
и поддержка виндовс 10
Reobne давно критикует XDev за то, что для сборки нужно писать батники, а для него это неподъёмный барьер. ;-) Посему наконец предприняты шаги для упрощения написания этих самых нехороших батников. Я исхожу из того, что хранить настройки проекта всё равно где-то нужно, поэтому мы будем хранить их в удобных для редактирования текстовых файлах, т.е. в батниках. ;-) Но упрощённых. Теперь у нас есть много опций, которые мы можем задавать, не опасаясь запутаться в тонкостях вызова SDCC и линковки. Конечно всё это ещё нужно тестировать. Но зато:
- поддерживаются многомодульные проекты;
- поддерживается хранение символьных файлов в папке /Obj (без отдельной папки /Sym);
- поддерживается хранение модулей в папке проекта (без отдельной папки /Mod).
Читать дальше...
Именно! Спасибо, что пытаешься понять меня, но всё-таки не только "писать батники", но и "думать про батники", и "помнить о батниках". Я хочу вообще о них забыть как о страшном сне. Пусть будет форма, вызываемая из меню среды ZX-dev, где всё что нужно для проекта можно установить. Пусть эта форма меняеться от версии к версии ZX-dev, а не:
Вот ZX-dev. А это новые версии ZX-dev-а. А это фишки программирования ZX-dev, и новые фишки для новых версий ZX-dev. А это батник, который в тёмном чулане хранится, со своими фишками, и новыми фишками для новых версий ZX-dev. А вот и грабли, которые в старых фишках батника и в новых фишках батника, и по дороге к чулану, и в фишках проекта, и в новых фишках проекта, для очередной версии ZX-Dev. А вот и зашуганый кот, который приходит програмить в ZX-dev, которого бьют по лбу грабли в чулане, при поиске чулана, при узнавании что чулан существует, при узнавании, что у батников свои фишки, при узнавании про новые версии ZX-dev, с новыми фишками и новыми граблями. А это старый пёс без хвоста, который за шиворот треплет кота, за то что тот морщится и мяукает, когда его по лбу бьют все эти грабли. А вот и доильница строгая, которая бранит трусость всех котов мира, которые не идут читать форум, и узнать наконец про правила, как избегать некоторых из граблей.
А как же ты хотел, дарагой? Если таки не веришь мне про грабли, то возьми, что ли, Дельфи 3 и попробуй им собрать проект для Дельфи 5. Но там контора солидная была, а ZXDev - самопал. Однако ты верно заметил, фишек много! Да... ;-)
- - - Добавлено - - -
Вот такое годится? Учти, это не избавляет от необходимости понимать логику опций SDCC. По крайней мере, для продвинутых применений. Но для быстрого старта такого меню конечно с головой, практически все поля можно оставлять дефолтными.
Вложение 58024
P.S. В SDCC появилась возможность задавать для ф-ций список регистров, которые они гарантированно не портят. Я только заметил. Выглядит так:
Безкрайнее поле для оптимизации всего, чего придётся. ;-)Код:extern void Laser2_PTBL (signed char col, signed char row, unsigned char spn) __preserves_regs(b, c, d, e, iyl, iyh);
а среда под какие ОСи?
Под Windows 32/64 бит. От XP и до 10'ки. На последней не тестился, но должен работать.
Транслятор Оберона в Си - Ofront+ (сама суть XDev) для командной строки работает под Linux 32/64 и Windows 32/64 бит. Наверно легко собрать и под какой-нить ARM/Raspberry Pi (я не пробовал).
То есть берёшь транслятор командной строки, какой-нить подходящий текстовый редактор, дёргаешь библиотеки из ZXDev, пишешь свои bash-скрипты для сборки и вызова Ofront+/SDCC и юзаешь. Так я себе это представляю.
А правду говорят, Raydac, что ты там визуальные среды разработки на базе языка Дракон у себя в блоге критикуешь? Кошка на усах принесла. ;-)
Reobne, погоди, доделаю, отпишусь. В связи с очень плохим знанием BlackBox API и его средств построения форм, мне постоянно приходится доставать глупыми вопросами Ивана Кузьмицкого. Вот такой я не гордый. ;-)
Процесс визуальной разработки в BlackBox имеет свою собственную красоту, но сильно отличается от Delphi'шного.
- - - Добавлено - - -
Да и форумы читать приходится, прикинь? ;-)
Reobne, я давно хотел составить FAQ по разным тонкостям ZXDev, но не для себя же мне его писать? Где люди, которые задают вопросы? Я пока видел только критиканство в стиле "фи, это не Си, не асм и не Паскаль".
А не делал поддержку мастера для сохранения настроек не потому, что очень ленился, просто не сформировалось понимание как именно ему надлежит выглядеть. Да и сейчас нет. Например, ещё не придумал как защитить написанные вручную батники от переписывания автоматически сгенерированными в результате нажатия на кнопку Save. Ну и не спрашивай, где будут храниться настройки. ;-) Сам скажу. В Project/Rsrc/Strings.odc, но, правда, прозрачно для юзера, т.е. он не должен вникать во внутреннюю структуру этого файла, хоть он и текстовый.
.c-файлы будут тереться вообще (кроме главного для многомодульных проектов) процедурой уборки (Clean), так что знание языка Си для работы в ZXDev не требуется, достаточно минимального знания ZX-Basic.
- - - Добавлено - - -
И ещё не придумал где хранить название подсистемы. Ведь файла свойств проекта может и не быть. В батнике? В каком? В отдельном или в тех же compile.bat/build.bat? Но если мы будем знать название подсистемы, мы можем обойтись и без батников. Директивой (*$ZXDev*) прямо в тексте модуля? Но тогда придётся в тексте каждого модуля. А без знания, какой подсистемой собирается проект, откуда мы знаем какие символьные файлы использовать? И где именно они хранятся. В общем, одни сплошные вопросы, Reobne. А ты вместо того, чтобы помочь, испугался и убежал. ;-)