Просмотр полной версии : Разработка программ и игр для ZX Spectrum на языках Оберон-семейства
Oleg N. Cher
03.03.2012, 13:08
Здравствуйте, уважаемые спектрумисты.
Хочу поведать вам об одной интересной возможности – разработке для Спека на императивном языке высокого уровня Оберон-2.
Я занимаюсь Оберон-технологиями уже много лет, и довольно долго варился в собственном соку, тем интереснее будет найти здесь единомышленников, которых заинтересует связка “Оберон + ZX”. Язык ведь очень заслуживающий внимания. Он – собрание здравых и эффективных языковых решений, не мотивированных коммерческими выгодами и сиюминутными платформами. Абстракция от платформы там весьма чувствуется. Я не буду утверждать, что надо всё разрабатывать на Обероне. Нет. Но в качестве минимальной языковой базы, чтобы прочувствовать какие возможности языка незаменимы, а какие от лукавого (хотя мы к ним и привыкли), Оберон чудесно подходит. Он не идеален. Его можно и нужно совершенствовать. Но он уже лучше Си более правильной модульностью (хотя, строго говоря, в Си модульности нет) и автоматической генерацией интерфейсных файлов (аналог *.h). И лучше Паскаля отсутствием лишних BEGIN и более серьёзной кроссплатформенностью (в Обероне системо-зависимые низкоуровневые модули должны быть помечены импортом модуля SYSTEM, предоставляющего набор низкоуровневых возможностей, о модулях на Паскале такого сходу не скажешь). И лучше Delphi отсутствием необходимости дублировать в интерфейсе заголовки процедур. Лучше C++ и Modula-2 наличием сборки мусора и компактной концепцией ООП – расширяемыми записями, защитой динамических типов. Лучше Явы более продуманной модульностью, не ставящей во главу угла классы, а оставляя модули модулями. И лучше C#/Java отсутствием привязки к виртуальной среде с жирными рантаймами и более высокой наглядностью текстов программ. Оберон унаследовал наглядность Паскаля, текст программы на нём очень понятен и не засорён не слишком явными сокращениями.
Я не собираюсь спорить с теми, кто не согласен с данными определениями и готов развязать священную войну за любимый язык, мне давно это неинтересно. Можете принять моё мнение как субъективное. Существование языков Оберон-семейства и почитателей их достоинств никак не мешает продолжать решать свои задачи на своих любимых языках и средствах разработки. Хотелось бы увидеть обсуждение по теме вопроса, а не похвалы другим языкам, вовсе не обиженным недостатком внимания.
Оберон – современный язык. Поддерживает такие парадигмы программирования как процедурное, модульное, расширяющее (extensible), объектно-ориентированное, компонентное, системное и рефлективное (reflective programming). Крайне прост в изучении и освоении. Легко воспринимается теми, кто знаком с Паскалем (Информация взята из статьи Р.Богатырёва "Язык Оберон. Краткий путеводитель" http://www.oberon2005.oberoncore.ru/paper/obe_exp.pdf).
Оберон – это самый маленький и простой язык высокого уровня из всех имеющихся. Уже поэтому он интересен. Но разработка на нём не выглядит такой уж ущербной или извратной, как это можно было бы подумать. Правда, переход с Дельфи или Си на Оберон не столь гладок и предполагает определённую ломку мышления. Это не всегда безболезненно и приятно. Но я, пройдя через этот этап, оцениваю изменения моих качеств, как разработчика, в положительную сторону.
Судите сами. Полное описание диалекта Оберон-2, например, занимает приблизительно от 16 до 30 страниц (с примерами). (Java – 200 страниц, C# – 1500 страниц; за точность цифр не ручаюсь – только что нагуглил). Он очень хорош для обучения, ибо платформенно и корпоративно нейтрален. Малоизвестность Оберона вызвана не его недостатками, а скорее тем, что классический подход при разработке на Обероне – это не привычная IDE с раскраской синтаксиса + компилятор/линкер, а Оберон-система, которая не вписывается в устоявшиеся стереотипы и которой надо научиться пользоваться, а поскольку выглядит это не так уж и просто и явно, то это серьёзная для многих преграда. Сейчас же такой проблемы нет. Хотя есть много Оберон-систем, работающих как на голом железе, так и поверх других ОС, можно найти компиляторы для различных платформ. Если интересно, расскажу подробнее о средах разработки и компиляторах, с которых стоит начать.
Упомяну об интересной возможности получить из Оберон-2 программы текст программы на Си или Ява автоматически. Т.е. работая на Си будут трудности с переносом на Яву. Работая на Яве – те же трудности с переносом на Си. Работая на Обероне, мы можем или остановиться на трансляции в компактный нативный код для Win32/Linux, или в текст на Ява/Си, или в .NET CLR. Это тоже возможно. Как видите, современная линия развития ЯВУ это не сверхоптимальная кодогенерация в натив, а наслоение оптимизиторов поверх байт-кода внутри толстых виртуальных машин. Оберон не требует VM, но и может работать поверх неё. Такую кроссплатформенность я считаю настоящей, в отличии от поддельной кроссплатформенности дотнета и явы. Дотнет и Ява для Спека безполезны. Оберон же очень возможен.
Я знаю, что здесь полно хакеров, которые обожают работу с битами и портами. Что ж, это тоже хорошо, но Оберон силён не этим. Также я предчувствую выкрики, что правильные Z80-кодеры всё делают на асме. Тут тоже не поспоришь. Я не против использовать Оберон в качестве клея к подпрограммам на асме. Это направление тоже интересует. Но больше интересует разработка ровно как алгоритмов, так и приложений независимых, междуплатформенных. Но которые удастся развернуть и на Спеке с его скромными ресурсами.
Оберон в мире языков высокого уровня напоминает мне Спек в мире компьютеров. Такой же небольшой и малоизвестный для широких масс, но конструктор из него просто замечательный. А языки Оберон-семейства – как клоны Спектрума. Каждый из них чем-то интересен.
Итак, интересует разработка на Обероне любых вещей, связанных со Спеком. Может кому-то будет интересно разработать на языке из Оберон-семейства эмулятор? Или что-то для самого Спека? Я готов консультировать по Оберон-технологиям. :v2_dizzy_king: Можете попробовать предложить мне совместный проект (для Спека, или нет) на Обероне. Например, кроссплатформенную игру (включая реализацию для ZX). Если меня это заинтересует, поучаствую.
О недостатках Оберон-языков. Нету накатанных дорожек, мало готовых решений, средств и главное – массового коммьюнити. Инструментарий для Оберон-разработки не такой проработанный и обжитый, часто приходится допиливать. Если не настроены на это дело и обожаете Visual Studio или Eclipse, видимо, Обероны лучше не пробовать. В применении Оберона к Z80 первым делом может показаться неудобным отсутствие беззнаковых типов. Это верно, их нету. Но это не мешает ими пользоваться. Могу потом рассказать подробнее об этом. Есть множества – это удобное средство для работы с отдельными битами. Рантаймы Оберона? Не нужны и не используются. Динамическая загрузка-выгрузка модулей? Полагаю, это решаемо, хотя часто попросту не нужно. Сборка мусора в пределах 48-64 кб? Нет, в Оберонах её непременное использование не является обязательным. Чаще динамическую память можно не использовать. Если же нужна, построение собственного менеджера памяти с явным выделением и освобождением памяти кажется разумным. Минимальная программа на Обероне для ZX? Можно собрать в несколько сотен байтов размером. Идеально, почти без накладных расходов подходит в качестве структурно-модульного клея между ассемблерными вставками и каркаса для наработки удобных библиотек (вплоть до кроссплатформенных между ZX и другими платформами).
Чтобы подогреть интерес и показать на что способны Оберон-технологии в применении к ZX предлагаю посмотреть скриншот игры Dash, порта с версии DOS/CGA (Си) на язык Оберон для платформ MS-DOS, Win32, Linux и ZX Spectrum. Также есть ещё идеи и наработки в данной области.
http://zx.oberon2.ru/dash.htm
вопрос то в плане ZX всегда прост, тривиален и немногословен и сводится к утверждению - "есть кросс-компилятор или нет кросс-компилятора", по ссылке я увидел что есть компилятор под x86 но не нашел ничего кроме скриншота относящееся к Z80
Oleg N. Cher
03.03.2012, 13:25
Если кратко, то кросс-компилятора из Оберона в код Z80 нет. Разработка производится через Си связкой: фронт-энд BlackBox/Ofront -> бэк-энд SDCC. Но его можно разработать.
Если подробно, то тут надо писать целую статью. Вот поэтому и дайте мне понять, стоит ли её писать.
Если подробно, то тут надо писать целую статью. Вот поэтому и дайте мне понять, стоит ли её писать.
имхо - надо садиться и писать не спрашивая, так как если будете тут спрашивать, то разочаруетесь в спектруме, спектрумистах, идее, себе и окружающем мире, это русскоязычный форум со своим суверенным подходом, поэтому лучше спрашивать тут когда уже сделано
Oleg N. Cher
03.03.2012, 13:38
Ага, Raydac (Игорь Мазница, если не ошибаюсь?) Знаю-знаю. И про Ваш Laser Basic для Вашего клона Си тоже слышал. Кстати, и для Оберона его заточил. Почти.
Но я не согласен с Вами насчёт всего законченного. Есть недоделанный Dash, согласны подождать ещё лет 10 пока его закончу? А если не закончу?
Тогда, получается, зря я сюда вылез, раз Вы такой требовательный. :-P
Тогда, получается, зря я сюда вылез, раз Вы такой требовательный. :-P
не зря, но вопрос "надо ли это делать?" тут обычно порождает массу флейма и массу вопросов от "специалистов" "а нафига?!", идей как правило дается мало и все силы уйдут на то что бы отбиваться, поэтому лучше выходить сразу с каким то черновиком что бы дать тему для обсуждения имхо
Oleg N. Cher
03.03.2012, 15:52
Статья по мере написания будет выкладываться здесь: http://zx.oberon2.ru/zx-dev.htm
А пример кода можно?
Все графические возможности - вывод спрайтов и т.п. - они тоже на обероне написаны?
Если подробно, то тут надо писать целую статью. Вот поэтому и дайте мне понять, стоит ли её писать.
Лучше компилятор напишите.
---------- Post added at 17:13 ---------- Previous post was at 17:12 ----------
Упомяну об интересной возможности получить из Оберон-2 программы текст программы на Си или Ява автоматически. Т.е. работая на Си будут трудности с переносом на Яву. Работая на Яве – те же трудности с переносом на Си. Работая на Обероне, мы можем или остановиться на трансляции в компактный нативный код для Win32/Linux, или в текст на Ява/Си, или в .NET CLR. Это тоже возможно. Как видите, современная линия развития ЯВУ это не сверхоптимальная кодогенерация в натив, а наслоение оптимизиторов поверх байт-кода внутри толстых виртуальных машин. Оберон не требует VM, но и может работать поверх неё. Такую кроссплатформенность я считаю настоящей, в отличии от поддельной кроссплатформенности дотнета и явы. Дотнет и Ява для Спека безполезны. Оберон же очень возможен.
Товарищ форумом не ошибся?
Мы тут о спектруме разговариваем, а значит предполгается что мы кодим на Асме и Бейсике. Какие нафиг Явы, СИ и Дельфи?
Оберон в мире языков высокого уровня напоминает мне Спек в мире компьютеров. Такой же небольшой и малоизвестный для широких масс,
Чего курил? Спектрум второй в мире по известности 8-битный комп.
Oleg N. Cher, а что там еще есть по оберону?
исходники своей программы дадите?
ну и ссылку на те 30 страниц описания языка тоже не помешают
Oleg N. Cher
03.03.2012, 18:53
Кажется, я понимаю, о чём Raydac.
Eltaron, можно многое делать на Обероне. Не исключаю для эффективности асм.
jerri, гуглируйте. Всё есть. Исходники тоже дам. В статье.
newart, компилятор пишите сами. Не спрашиваю во сколько человеко-лет Вы оцениваете качественный генератор кода для Z80. И сколько у Вас знакомых кодеров, способных довести на одной внутренней мотивации такого масштаба проект до ума.
И сколько у Вас знакомых кодеров, способных довести на одной внутренней мотивации такого масштаба проект до ума.
А как же:
Оберон – это самый маленький и простой язык высокого уровня из всех имеющихся.
Или это ценой мозголомного компилятора?
Oleg N. Cher
03.03.2012, 19:11
newart, конечно. Фронт будет простой. Бэк сложный. Для качества кода. Или ж заплюётесь от сгенеренного кода, и снова будет у Вас повод быть недовольным.
Реально лучший генератор кода для Z80 это SDCC. Надо быть скромным. Я его не переплюну.
Oleg N. Cher, исходников пока не увидел
по вашим ссылкам с вашей страницы пара примеров на срр
гуглить я буду как заинтересуюсь пока вижу не очень качественное предложение с вашей стороны.
надо больше информации
вот тут (http://purebasic.ru/) пример качественного предложения
Oleg N. Cher
03.03.2012, 19:22
Чтобы заинтересоваться и почувствовать возможность, информации было достаточно. Чтобы начать разбираться - тоже. Для грамотного человека. Я же пишу талмуд что за чем ставить и как тыкать. Это требует времени. Или я запостил большой кусок текста, полдня просидел за ним, а от меня требуют ещё большего, и срочно.
Чтобы заинтересоваться и почувствовать возможность, информации было достаточно.
Не было. Я так и не понял, для чего нужен этот Oberon в современном мире?
И в частности на спектруме.
ZEK, а по нему есть на русском?
Oleg N. Cher
03.03.2012, 19:59
Нежелание гуглировать поражает.
http://ru.wikipedia.org/wiki/Оберон_(язык_программирова ия)
http://ru.wikipedia.org/wiki/Active_Oberon
Насчёт AO согласен. Только вот кто этим займётся?
Сравнение Оберона с Бейсиком в пользу Бейсика считаю дремучим невежеством.
Чтобы заинтересоваться и почувствовать возможность, информации было достаточно. Чтобы начать разбираться - тоже. Для грамотного человека. Я же пишу талмуд что за чем ставить и как тыкать. Это требует времени. Или я запостил большой кусок текста, полдня просидел за ним, а от меня требуют ещё большего, и срочно.
не вижу пока у оберона преимуществ перед асмом или с.
также не вижу чем оберон лучше хаскеля.
пример с пуребасиком очень важен
большинство программ для спека пишется сейчас кросс-средствами
используя пуребасик за счет его простоты, я не зная срр и иже с ними могу не напрягаясь сваять себе какой-то инструмент.
если для оберона есть простой способ получения обьектного кода вида (оберон >> exe) а не как сейчас (оберон >> (cpp)о(asm) >> exe)
то его следует применить и для спека, а не городить огород из фронтэндов и sdcc, тогда да от оберона будет толк. тем более если он кроссплатформенный
большего и срочно никто не требует. просто ты в своей статье упомянул что пишешь некий DASH на обероне и предьявил странный скриншот. этого явно недостаточно, хотелось бы видеть это все в движении
Разработка производится через Си связкой: фронт-энд BlackBox/Ofront -> бэк-энд SDCC.
Интересует возможность поюзать Оберон для работы с объектами ООП. Насколько вообще хорош Си код, который генерит транслятор.
(Смысл в том, чтобы не имитировать ООП на голом Си, что довольно занудно.)
Статья по мере написания будет выкладываться здесь: http://zx.oberon2.ru/zx-dev.htm
Почитаем.
Нежелание гуглировать поражает.
гуглируют когда хотят что-то доказать
так что я гуглирую когда хочу дать человеку ссылку
про оберон я нашел вот такое (http://www.rsdn.ru/forum/philosophy/889247.1.aspx) у нас же с вами разный гугл ;)
Насчёт AO согласен. Только вот кто этим займётся?
тот кому станет интересно. я пока не вижу как это применить на спек
Сравнение Оберона с Бейсиком в пользу Бейсика считаю дремучим невежеством.
почему?
Oleg N. Cher
03.03.2012, 20:39
Потому что это разные весовые категории. Если брать Спектрум Бейсик и Компонентный Паскаль? Или если брать Visual Basic и Oberon-2? Это равнозначно по-вашему? Оберон, разрабатываемый в неспешных условиях умнейшими и опытными людьми под 30 лет, предоставляющий возможность конструировать любые структуры данных, удобную работу с объектами, и гибридный Бейсик, байстрюк мелкософта, при ознакомлении с которым возникает чувство, что от Бейсика там осталось одно название.
Бейсику посвящено много тем, даже здесь. Оберону только эта. Давайте не будем её засорять Бейсиком.
Valen, код довольно неплох, как для автоматики. Не так хорош как ручной, однако если кроссплатформенность и удобство работы важнее, чем оптимизация, то с помощью хруста + SDCC удаётся получить гораздо быстрее (по времени разработки) почти тот же объём кода, что и с помощью асма и ручной оптимизации.
Kakos_nonos
03.03.2012, 20:43
Поддерживаю создание компилятора Оберон'а для спектрума.
Valen, код довольно неплох, как для автоматики. Не так хорош как ручной, однако если кроссплатформенность и удобство работы важнее, чем оптимизация, то с помощью хруста + SDCC удаётся получить гораздо быстрее (по времени разработки) почти тот же объём кода, что и с помощью асма и ручной оптимизации.
Прикрепите плиз файлы исходника dash и файл сгенеренного Си кода.
Нужна ли доработка Си файла напильником для компиляции в SDCC ?
и гибридный Бейсик, байстрюк мелкософта, при ознакомлении с которым возникает чувство, что от Бейсика там осталось одно название.
А кто говорил про VisualBasic? Упоминался PureBasic, который "разрабатываемый в неспешных условиях умнейшими и опытными людьми под 30 лет" из Франции.
Потому что это разные весовые категории. Если брать Спектрум Бейсик и Компонентный Паскаль? Или если брать Visual Basic и Oberon-2? Это равнозначно по-вашему? Оберон, разрабатываемый в неспешных условиях умнейшими и опытными людьми под 30 лет, предоставляющий возможность конструировать любые структуры данных, удобную работу с объектами, и гибридный Бейсик, байстрюк мелкософта, при ознакомлении с которым возникает чувство, что от Бейсика там осталось одно название.
при чем здесь visual basic?
здесь речь про pure basic - реальный качественный инструмент для быстрого создания кроссплатформенных приложений.
про оберон я пока не увидел исходников и готового кода чтобы оценить качество и удобство разработки.
Бейсику посвящено много тем, даже здесь. Оберону только эта. Давайте не будем её засорять Бейсиком.
Oleg N. Cher
03.03.2012, 23:17
Нужна ли доработка Си файла напильником для компиляции в SDCC ?
Как правило не нужна, но SDCC пока не умеет компилить вот такой код присвоения структур: http://sourceforge.net/tracker/?func=detail&atid=350599&aid=3452891&group_id=599
А Ofront такой код создаёт. Обещают в SDCC фичу эту добавить. Даже приоритет повысили несколько раз.
Для желающих советовать сделать компилятор. Если не просто компилятор, а хороший компилятор с нормальной кодогенерацией. Зайдите на данный трекер, и если у Вас не отпадёт охота это советовать делать, то тут не только я со своими Оберонами, а вообще медицина бессильна.
Обновил страничку http://zx.oberon2.ru/dash.htm. Выложил демку и фрагмент кода. Исходники недоделанного Даша, по крайней мере в полном объёме, шарить пока не намерен. Возвращаться к вдумчивой доработке Даша сейчас по Вашему тебованию не считаю нужным, поэтому поругивайте что увидите.
Просьба к тем, кто заинтересовался: не торопитесь. Что-то очень быстро и легковесно наполняется ветка. Закончу статью. Доработаю Laser Basic для Оберона. Всё выложу и пропиарю. Добавляйте меня в ICQ, будем общаться и развивать Оберон-направление для Спектрума. Для остальных: уважайте моё и своё время. Испытываю большое нежелание непродуктивных меряний писками.
Для тех, кто настолько недалёк, что не видит пользы не только от Оберона для Спектрум-разработки, но и от Оберона вообще, сообщаю, что я портировал на Оберон игру Дурак от CopperFeet и получил значительное ускорение работы. Это не для сравнения скорости работы интерпретатора Laser Basic и цепочки трансляторов Ofront/SDCC. Это как факт в пользу Оберонов на Спеке. Код открыть не просите, не дам. Годы моей жизни, девелоперского становления и варки в своём соку. Может стоило вариться и дальше? Уж больно здесь агрессивно реагируют на непривычное. Я пытаюсь сделать что-то полезное, что умею. А вы заметили агрессию в моих постах? Нет, вместо этого я оправдываюсь, будто я кому-то чего-то должен или пытаюсь навязать. Я хочу напомнить, что я Вам ничем не обязан и ничего не должен. Я не майкрософт. Не нравится Оберон – юзайте качественно предложенный Бейсик.
P.S. Дурак также недоотлажен. Отлаживать по Вашему требованию сейчас не буду, занят другими делами.
В исходниках не увидел ООП.
Какой асм такое кушает: ld -3 (ix),#0x02 ?
---------- Post added at 23:30 ---------- Previous post was at 23:29 ----------
if (__ODD(x)) - что значит двойное подчеркивание?
Oleg N. Cher
03.03.2012, 23:37
В исходниках не увидел ООП.
Какой асм такое кушает: ld -3 (ix),#0x02 ?
---------- Post added at 23:30 ---------- Previous post was at 23:29 ----------
if (__ODD(x)) - что значит двойное подчеркивание?
1) В игре Dash ООП не применяется
2) Используемый в SDCC sdasz80
3) Это так Ofront делает, наверное для удобства, чтобы имена не наложились.
Oleg N. Cher
03.03.2012, 23:43
Ладно, делайте компилятор с хорошей кодогенерацией, коли охота. Смысл в нём будет, если достигнется качество кода лучшее, чем у SDCC. Я давно решил этим не заниматься. Ограничился связкой. Выбирать направления деятельности, отсеивая дурь, тоже талант.
Выбирать направления деятельности, отсеивая дурь, тоже талант.
ну вот, когда вкусил российский форум, теперь можешь для интереса инфу о проекте перевести на английский и запостить на world of spectrum или linkedin :) что бы почувствовать разницу
чисто имхо насчет кстати кода и потраченных лет, один из неочень, но известных людей сказал "Не беспокойтесь, что ваши идеи украдут. Если эти идеи хороши, вы должны вбить их людям в глотки." (С) Говард Айкен
Для желающих советовать сделать компилятор. Если не просто компилятор, а хороший компилятор с нормальной кодогенерацией. Зайдите на данный трекер, и если у Вас не отпадёт охота это советовать делать, то тут не только я со своими Оберонами, а вообще медицина бессильна.
никто от тебя не требовал компилятор
интересовал сам факт таких компиляторов
Обновил страничку http://zx.oberon2.ru/dash.htm. Выложил демку и фрагмент кода. Исходники недоделанного Даша, по крайней мере в полном объёме, шарить пока не намерен. Возвращаться к вдумчивой доработке Даша сейчас по Вашему тебованию не считаю нужным, поэтому поругивайте что увидите.
другое дело :) есть на что посмотреть
так значит полностью законченных проектов на обероне в наличии нет?[COLOR="Silver"]
Oleg N. Cher
04.03.2012, 01:45
так значит полностью законченных проектов на обероне в наличии нет?
Для Спека нет, за большое всё брался, и побольше платформ покрыть хотелось.
Но демку сваяю законченную, если никто не сделает её раньше. Есть не ленивые? :v2_dizzy_step:
moroz1999
04.03.2012, 02:41
Уж больно здесь агрессивно реагируют на непривычное. Я пытаюсь сделать что-то полезное, что умею. А вы заметили агрессию в моих постах? Нет, вместо этого я оправдываюсь, будто я кому-то чего-то должен или пытаюсь навязать.Послать всех скептиков и делать то, что нравится - тоже талант.
Оберон система как бы подразумевает нативный компилятор, в этом фишка оберона, когда каждый компилируемый модуль становится частью системы,
А что мешает кидать свои модули рядом с системными и использовать на ряду с ними?
Oberon этот как язык ничем особенным не привлек меня, какой-то он эквивалентный object pascal-ю. Сразу видно что его сделали чтоб он БЫЛ (и было чем парить моск студентам и манагерам) а не чтоб использовать самим для написания скажем ядра линукса. В этом плане у меня есть непонятки только с google go, сначала я подумал что это будет реальная замена для С/С++ (так как видно что язык сделан для программистов самими программистами а не для манагеров академиками), а теперь сомневаюсь.
Что непонравилось, так это приколы типа - язык С умер :) и т.д.
Олег, сто лет тебя не видел!
Для Спектрума проблема не кодогенерация, а распределение памяти.
Почему именно Оберон? Там даже условной компиляции нет. У тебя же был свой язык, где всё переопределялось? Или он не был допилен?
Для Спека нет, за большое всё брался, и побольше платформ покрыть хотелось.
Но демку сваяю законченную, если никто не сделает её раньше. Есть не ленивые? :v2_dizzy_step:
не надо ёрничать, спектрум мертв и заниматься им - фанбойство
потому все что делается здесь - делается для удовольствия
и про лень это туда ==>:v2_dizzy_wall:
farewell
04.03.2012, 15:38
А вот мне оберон (да и все остальные паскали) не нравится тем, что переменные процедуры нужно в отдельной секции описывать. На процедурах размером по 400+ строк, имеющих несколько десятков переменных удобнее концепция фрейма.
SpecialistMK87
04.03.2012, 22:12
синтаксис просто ужасен и архаичен, особенно
VAR, BEGIN, END, присвоение :=
На процедурах размером по 400+ строк, имеющих несколько десятков переменных удобнее концепция фрейма.
Что это за концепция?
farewell
05.03.2012, 09:05
int a = 10; // фрейм 0
if (true) {
int b = 10; // фрейм 1
}
// здесь переменные фрейма 1 уже не видны.
Надеюсь, понятно объяснил. Не совсем по науке, но суть такая.
Как правило не нужна, но SDCC пока не умеет компилить вот такой код присвоения структур:
Как сейчас эту проблему обходите ?
Ofront для linux поставил, работает из коммандной строки.
Тестовый исходник оберона-2 транслировал в Си, код довольно чист, видал я и по хуже трансляцию. ООП ещё не пробовал.
Oleg N. Cher
07.03.2012, 15:20
Олег, сто лет тебя не видел!
Для Спектрума проблема не кодогенерация, а распределение памяти.
Почему именно Оберон? Там даже условной компиляции нет. У тебя же был свой язык, где всё переопределялось? Или он не был допилен?
Здравствуй, Дима! Необычайно рад тебя здесь увидать.
Мой язык Coloss был допилен до известного состояния, что сделано, то можно увидеть здесь: http://colossoft.anarxi.st/?go=coloss. На нём (полностью без асма) была сделана игра Sea Fight, скриншоты можно увидеть здесь: http://colossoft.anarxi.st/?go=seafight. Я интересуюсь языками давно, знаю их даже не два десятка, а гораздо-гораздо больше, поэтому слушать про сравнение Оберона с Хаскеллем или про архаичность VAR туточки меня умиляет. Но, тем не менее, Оберон-технологии – это то, к чему в итоге я пришёл. О проблемах распределения памяти знаю, и согласен. Условная компиляция видится мне вцелом нежелательной. Но и эта задача решаема в разных Оберонах разными средствами. Ссылка по теме: http://forum.oberoncore.ru/viewtopic.php?f=29&t=2062 (возможно, понадобится регистрация).
Oleg N. Cher
07.03.2012, 16:02
Oleg N. Cher, а что там еще есть по оберону?
исходники своей программы дадите?
ну и ссылку на те 30 страниц описания языка тоже не помешают
Надо думать, Оберон-исходников в инете если не тонны, то хотя бы килограммы. Вобщем, есть что найти. А поучениями по Си и асму я вообще боюсь обидеть бывалого спектрумиста.
ну вот, когда вкусил российский форум, теперь можешь для интереса инфу о проекте перевести на английский и запостить на world of spectrum или linkedin :) что бы почувствовать разницу
Тут не помешала бы помощь, не насколько хорош мой английский.
А может буржуи ещё учатся, а наши уже всё знают? :mad:
"Не беспокойтесь, что ваши идеи украдут. Если эти идеи хороши, вы должны вбить их людям в глотки." (С) Говард Айкен
Точно-точно. Сами не понимают своего счастья. А счастье-то совсем рядом, вот оно, в паре кликов мышкой.
была сделана игра Sea Fight, скриншоты можно увидеть здесь: http://colossoft.anarxi.st/?go=seafight.
На картинках красиво, а скачать где?
Oleg N. Cher
07.03.2012, 18:26
Как сейчас эту проблему обходите ?
Здесь видится несколько решений. В порядке повышения сложности где-то так.
1. Не использовать присваивания вида:
TYPE
Card = RECORD suit*, rank*: INTEGER END;
VAR (* Do not use Oberon, it’s archaic! *)
a, b: Card;
BEGIN
a := b;
Обойдясь таким поэлементным присваиванием:
a.suit := b.suit; a.rank := b.rank;
2. Использовать автоматическую обработку промежуточного Си-файла, заменив в нём подходящим инструментом указанные присваивания “a := b” на “a.suit := b.suit; a.rank := b.rank”
Это решение не очень красивое, но его плюс в том, что Оберон-исходник остаётся красивым.
3. Ждать пока в SDCC добавят нужную нам рюху. Я посмотрел http://sourceforge.net/tracker/index.php?func=detail&aid=1710546&group_id=599&atid=350599 – ещё не добавили.
4. Наиболее правильным видится доработать Ofront, чтобы сам генерировал поэлементное присваивание записей (или что-то вроде
memcpy(a, b, sizeof(Card))) [опционально включаемое]. Это вполне возможно, правда, я не понял, разрешает ли лицензия его доработку. Надо уточнить у Джозефа Темпла.
Ofront для linux поставил, работает из коммандной строки.
Тестовый исходник оберона-2 транслировал в Си, код довольно чист, видал я и по хуже трансляцию. ООП ещё не пробовал.
Чудно. Наконец-то кто-то чего-то пробует сам, а не только кричит как ему Оберон не ндравица. А ООП в Обероне красивое.
Я так и не понял, для чего нужен этот Oberon в современном мире?
И в частности на спектруме.
Примерно затем же, что и лопата в современном мире экскаваторов и бульдозеров.
Чего курил? Спектрум второй в мире по известности 8-битный комп.
Угу, интересно узнать который был первый, не РК-86 ли? Очень его известность, использование и уважение всё шире во всё более узких кругах. С молодёжью давно общались? Они не то что Exolon, R-Type и Elite, они не знают даже уже Аллоды, Quake-3 и StarCraft. А массы всё появляющегося нового софта и железа для столь известной марки? Вы не к словам придирайтесь, а между строк читайте.
другое дело :) есть на что посмотреть
так значит полностью законченных проектов на обероне в наличии нет?
jerri, а насколько, по Вашему опыту, целесообразно открыть здесь на форуме темы для разрешения возникших у меня в процессе портирования игр трудностей? Не погрязнет в обсуждениях типа “выкинь все свои игры нафиг и лучше сделай [подставить нужное]”? :v2_dizzy_tired2:
ну я ММА знаю больше его нельзя сьесть
ему просто результаты нужны а здесь он их не дождался
потому и ушел
А остальные, получается, результатам предпочитают старое доброе околоспектрумное чесание языков? :mad:
А пример кода можно?
Можно. Держите. Как раз на Обероне и как раз для Спека. Потрошка Дурачка-с.
Oleg N. Cher
07.03.2012, 18:34
Ух ты, блин, как разрешение покорёжило. Не мелковато ли? Приложить оригинальные картинки в архиве?
Сразу видно что его сделали чтоб он БЫЛ (и было чем парить моск студентам и манагерам) а не чтоб использовать самим для написания скажем ядра линукса.
Что, однако, не помешало на нём сделать ядро систем ETH Oberon и A2 (Active Oberon System), тако же, как и BlackBox Component Builder.
Насчёт конфликтов между адептами языков. Это не стычки, по задумке это война. А ещё желание возводить вредные привычки в культ. Вы согласитесь, что популярность певицы или актёра в современном мире мало коррелирует с её/его талантом? Аналогию не продолжаю.
Что непонравилось, так это приколы типа - язык С умер :) и т.д.
А это не прикол, это статья такая есть, заслуживающая ИМХО внимания, извольте полюбопытствовать:
http://primat.org/news/2010-11-06-352.
На картинках красиво, а скачать где?
А действительно, где?
Oleg N. Cher
07.03.2012, 19:31
Выложил скриншоты процесса портирования игры Durak от CopperFeet на язык Оберон: http://zx.oberon2.ru/durak.htm
Это хобби такое. И чтобы взрастать как девелопер. И теперь я могу сказать, что уж в языках – разбираюсь. И перестаньте, пожалуйста, придираться.
А действительно, где?
Кажется где-то тут даже исходник сохранился: http://stef.anarxi.st/ru/portfolio.php
А готовая игра была сделана с учётом модели памяти Орель БК-08 (Днепропетровский вариант Спектрум-совместимой машины), на оригинальном Спеке 48 кб оно конечно будет работать, но слегка не так как задумано. Кроме того, там турбозагрузчик с кассеты. Давнее было дело. Может в эмуле не пойтить.
Чтобы sdcc скомпилил Си файл (сгенеренный ofront) нужен SYSTEM.h для спектрума и вероятно ещё кое-какие системные функции. Это будет выложено ?
А готовая игра была сделана с учётом модели памяти Орель БК-08 (Днепропетровский вариант Спектрум-совместимой машины), на оригинальном Спеке 48 кб оно конечно будет работать, но слегка не так как задумано. Кроме того, там турбозагрузчик с кассеты. Давнее было дело. Может в эмуле не пойтить.
Ну, а где готовая игра-то? Эмулей много, может и пойдёт.
Oleg N. Cher
07.03.2012, 19:45
Чтобы sdcc скомпилил Си файл (сгенеренный ofront) нужен SYSTEM.h для спектрума и вероятно ещё кое-какие системные функции. Это будет выложено ?
Да.
SYSTEM я получил из готового от Linux. Будьте готовы к тому, что его наверняка придётся дорабатывать.
Oleg N. Cher
07.03.2012, 19:55
Ну, а где готовая игра-то? Эмулей много, может и пойдёт.
Инструкция. Нужен режим 48 BASIC. Любуемся заставкой. Жмём Reset.
CLEAR 23999: LOAD ""CODE
RANDOMIZE USR 25e3
После вызова пункта "Инструкция" появятся цветные квадратики. Это экран был сохранён в доп.памяти "Орели" и "восстановлен". Жмите 2.
Условная компиляция видится мне вцелом нежелательной. Но и эта задача решаема в разных Оберонах разными средствами. Ссылка по теме: http://forum.oberoncore.ru/viewtopic.php?f=29&t=2062 (возможно, понадобится регистрация).
Посмотрел. Внятного решения там не предложено. Проблема остаётся. Любой более-менее сложный проект имеет условную компиляцию, и в ветках далеко не константы.
alone, там же предлагают для разных версий держать наборы зависимых модулей - чем не вариант?
Тем, что разница обычно не в модулях, а в кусках процедур.
Тем, что разница обычно не в модулях, а в кусках процедур.
ну так разбросай процедуру по модулям :)
Oleg N. Cher
09.03.2012, 13:46
используя пуребасик за счет его простоты, я не зная срр и иже с ними могу не напрягаясь сваять себе какой-то инструмент.
Оберон-2 тоже простой, я уверен, что проще Вашего PureBasic'а.
Р.П.Богатырёв. Оберон как эсперанто программирования
http://www.computer-museum.ru/histsoft/ober_esp.htm
http://oberon2005.oberoncore.ru/paper/obe_esp.pdf
С.З.Свердлов. Арифметика синтаксиса
http://uni-vologda.ac.ru/cs/syntax/index.html
http://uni-vologda.ac.ru/cs/syntax/ariphm.htm
http://oberon2005.oberoncore.ru/paper/arith.pdf
Да, простота языка не только в синтаксисе, она в также минимально необходимой целесообразности. Считать Бейсик простым – можно, если это старый добрый Спектрум-Бейсик. Visual Basic уже не так-то прост. Pure – не знаю.
если для оберона есть простой способ получения обьектного кода вида (оберон >> exe) а не как сейчас (оберон >> (cpp)о(asm) >> exe)
то его следует применить и для спека, а не городить огород из фронтэндов и sdcc, тогда да от оберона будет толк. тем более если он кроссплатформенный
Давайте создадим такой способ, и будет. Или подождём пока кто-то создаст.
синтаксис просто ужасен и архаичен, особенно
VAR, BEGIN, END, присвоение :=
Ага, значит “:=” это уродство, а “==” – признанная всеми и щедро во многих языках одобренная мэйнстримом эстетика.
Трудно считать иначе, когда десяток лет парил себе моск "достоинствами" Си++
Ну а Ваши public static extern __cdecl и всеми любимый #include не устарели нисколько и актуальны хоть даже сейчас?
А между тем всё давно разложено по полочкам, где, что и зачем. Ага, не встречали. Значит не там читаете.
Стало модным относиться к нотации как ко вторичному аспекту, целиком зависящему от личных вкусов. Это отчасти верно, хотя выбор нотации не должен быть случайным. У этого выбора имеются последствия, обнаруживаемые в общем облике языка.
Общеизвестным плохим примером является выбор знака равенства для обозначения присваивания, восходящий к языку Fortran в 1957 г. и слепо повторяемый до сих пор массой разработчиков языков. Эта плохая идея низвергает вековую традицию использования знака "=" для обозначения сравнения на равенство, предиката, принимающего значения true или false. Но в Fortran этот символ стал обозначать присваивание, принуждение к равенству. В этом случае операнды находятся в неравном положении: левый операнд, переменная, должен быть сделан равным правому операнду, выражению. Поэтому x = y не означает то же самое, что y = x. В языке Algol эта ошибка была исправлена путем простого решения: присваивание обозначили через ":=".
Программистам, привыкшим к использованию знака равенства для обозначения присваивания, это может показаться придиркой. Но смешивание присваивания и сравнения действительно является плохой идеей, поскольку в этом случае требуется другой символ для того, что традиционно выражает знак равенства. Сравнение на равенство стали обозначать двумя символами "==" (впервые в языке C). Это является отвратительным последствием, приведшим к аналогичным плохим идеям использования "++", "--", "&&" и т.д.
В языках C, C++, Java и C# некоторые из этих операций вызывают побочные эффекты, известный источник ошибок программирования. Например, можно было бы принять "++" для обозначения увеличения значения на единицу, если бы то же самое не обозначало само увеличенное значение, что позволяет писать выражения с побочными эффектами. Неприятность состоит в удалении фундаментального различия между оператором и выражением. Оператор - это инструкция, подлежащая выполнению, выражение - это значение, которое надлежит вычислить.
Уродство конструкции обычно проявляется в комбинации с другими средствами языка. На языке C программист может написать конструкцию x+++++y, загадку, а не выражение, представляющую проблему даже для сложного синтаксического анализатора. Равняется ли значение этого "выражения" значению ++x+++y+1? Верны ли следующие соотношения?
x+++++y+1==++x+++y
x+++y++==x+++++y+1
Так можно было бы постулировать новую алгебру. Я нахожу совершенно удивительной невозмутимость, с которой мировое сообщество программистов приняло этого нотационного монстра. В 1962 г. установившиеся традиции аналогичным образом подорвало постулирование правой ассоциативности операций в языке APL. Тогда x+y+z неожиданно стало обозначать x+(y+z), а x-y-z - x-y+z.
У условного оператора языка Algol, представляющего пример неудачного синтаксиса, а не только плохого выбора символов, имелось две формы (S0 и S1 обозначают некоторые операторы):
if b then S0
if b then S0 else S1
Это определение порождает очевидную двусмысленность, получившую название проблемы "висящего else". Например, оператор
if b0 then if b1 then S0 else S1
можно интерпретировать двумя способами, а именно,
if b0 then (if b1 then S0 else S1) и
if b0 then (if b1 then S0) else S1,
возможно, приводящими к совершенно разным результатам. Следующий пример еще более серьезен:
if b0 then for i := 1 step 1 until 100 do if b1 then S0
else S1,
поскольку он может быть синтаксически разобран двумя способами, приводящими к совершенно разным вычислениям:
if b0 then [for i := 1 step 1 until 100 do if b1 then S0
else S1]
и
if b0 then [for i := 1 step 1 until 100 do if b1 then S0]
else S1
Однако выйти из положения здесь достаточно просто: нужно использовать явный символ end в каждой конструкции, являющейся рекурсивной, и начинать с явного стартового символа, такого как if, while, for или case:
if b then S0 end
if b then S0 else S1 end
Источник: http://citforum.ru/programming/digest/wirth/
P.S. Опять иду на флейм. У Вас имя Вирта, надеюсь, позывов не вызывает? Боже, как всё запущено. :mad:
Pure – не знаю.
Pure не сложнее ZX бейсика, сужу об этом написав десяток игр на том и другом.
Pure просто чуток современнее, со всеми этими Case, структурами, локальными/глобальными переменными, списками, картами...
Но прелесть в том, что перелезая со спектрума, можно все это не юзать, а писать старинке с goto/gosub и забыв о навязчивых let/then.
Oleg N. Cher
09.03.2012, 14:16
Посмотрел. Внятного решения там не предложено. Проблема остаётся. Любой более-менее сложный проект имеет условную компиляцию, и в ветках далеко не константы.
Ты согласился бы со мной, что ifdef это частный случай if? :smile:
Господа.
Даже без наличия ifdef’ов в базовой поставке Оберона-2 “из коробки” мощности различных Оберон-диалектов хватает для написания ОС, компилятора, браузера (чему в инете много примеров, даже с исходниками), сетевых сервисов и динамических веб-сайтов, работы с БД, сяк-так GUI-приложений (хотя решений для традиционных ОС ощутимо меньше, чем для Оберон-ОС) и даже бортовой системы для управления безпилотным вертолётом. Я-то и занялся им чтобы понять пределы возможностей этой крохотульки. Но тут ещё невспаханное поле работы, есть к чему приложить усилия.
Мы пока ищем, исследуем. Как обходиться без препроцессора. Но заметьте, есть “Дубовые требования” для Oberon-2, в них предусматривается препроцессор и условная компиляция. Никто вобщем-то не мешает реализовать в нашем компиляторе Оберона даже столь любимый ifdef.
Я буду говорить о метасреде BlackBox Component Builder. В ней уже наблюдаются некоторые направления, позволяющие несколько отойти от чисто текстового представления программ. Вы наверное уже видели скриншоты процесса портирования Дурака на Спектрум? Там уже представление программы не чисто текстовое. И можно щас тут разтеять флейм, охаивая и поругивая недостатки такого подхода, но, как любое друге направление, облечающее софтостроение, оно имеет право на жизнь. Вообще тут наблюдается постепенное совершенствование подхода: сначала был просто текст программы, потом кто-то придумал его раскрасить. Не сразу придумал, но получилось красивше и более выразительно. Сейчас в моде фолдинг – сворачивание части кода внутри, так скажем, BEGIN и END. Тоже шаг. Далее, видимо, ещё что-нибудь придумают. Но в BlackBox кое-что уже есть. Но это сразу не видно, когда новоскачавший BlackBox Component Builder видит "Меню+лог". Это надо разбираться. Вникать. А зачем, если линукс всё равно мощнее. Примерно так думают.
Помимо механизма слотов, в которые могут включаться различные реализации одного модуля, есть механизм, называемый селекторы (DevSelector), это вкладки в тексте, куда можно помещать какой-либо другой текст (или внедряемые объекты, например, рисунки) с неограниченной вложенностью. Помимо этого, есть возможность пометить любую вкладку меткой, скажем, ZxSpec, Win32 или Linux, и открывать все нужные нам вкладки (или ветвь) с выбранной меткой одномоментно. Скажем, открыли вкладку ZxSpec и сделали реализацию процедуры для Спека, открыли Win32 – и сделали её же реализацию для Win32. В свете такого решения потребность в ifdef’ах значительно уменьшается, если не исчезает совсем. Но это мы коснулись только Оберон-системы BlackBox.
В далёких 90-х мне доставляло большое удовольствие писать на Hisoft Pascal. Компилятор, правда, занимал почти всю память, кодогенерация была ужасная, а строчный редактор – жутко неудобный. Но всё это затмевалось красотой языка. Чувствовалась мощь, солидность эдакая, уверенность что написанное заработает. И работало. Сегодня я уверенно утверждаю, что Оберон значительно красивее Паскаля, а уж если его усовершенствовать. Как сказал оберонщик Илья Ермаков: “Каркас идеального минимального императивного языка высокого уровня уже есть, можно спокойно сосредоточить все усилия на проблемах вышележащего уровня”. За точность цитаты не ручаюсь, но где-то так. C#-то чем берёт? Тем, что бухгалтерии клепать легко и быстро.
А почему Оберон такой минималистичный? Видите ли, мэтр Вирт считает, что добавить новые средства в язык всегда можно и никогда это не поздно, а вот добавленное изъять – нельзя уже никогда. Отсюда появление таких монстров как Delphi, Ada и C#. А куда движется вообще мэйнстрим? Ну не надо быть высоким профессионалом, чтобы узреть в Java кастрированный C++. А ведь сколькими эпитетами её восхваляли сие новейшее слово в девелоперском деле, да и продолжают это делать. А Java – это испоганенный Оберон с сишным синтаксисом.
Кстати, как правило, критики Си его как минимум использовали и хорошо знают, критики же Оберона все на одно лицо: “А, так в Обероне нельзя аггрегировать перегрузку шаблонов дружественного виртуального метода класса? Фтоппку! А ещё и нельзя написать a-=--(**c*(**a++)*--&b--)*(**c++)++ ? Фи, негибко получаецца. А ещё и ифдефов нет! Так это вообще капец! Так вы, наглецы, ещё и забыли, что такая серьёзная штука как ядро линукса написана не на вашем Обероне, так что выбросьте-ка его вы наффих и идите парить себе моск в универ и читать “Just for Fun”. Тьху, а тут ещё и устаревшие архаичные BEGIN и VAR? Это вообще плевок в лицо, ибо Паскаль умер миллион лет назад”. А вы разве не знали? Ага, мы тоже не знали. И умирал он долго и тяжело, и по сей день умирает. Сродни Спеку. А те, кто помогают его хоронить, могильщики от науки и искусства, сначала похоронив кроссплатформенное программирование (такого мощного разгула UNIX-подобных систем никакой майкрософт не предполагал), потом высчитывают сверхприбыли, не считая троллей, которые гнут ель, ибо тот, кто выбирает на чём и под что будут программировать, тот и имеет. Всех остальных. “Что у вас сегодня в меню, официант?” “Андроид, сэр!”
Ещё замечу чистого любопытства ради, что серьёзные разработчики, даже не зная Оберона, в отличии от неофитов вовсе не спешат его огульно хулить. “Этта сделано капустными академическими головами шобы парить моск и шобы было, а не шобы делать ядро линуха”. Примеры навскидку. Sam Lantinga, автор библиотеки libSDL. Andreas Schiffler, автор SDL_gfx, а также Philipp Klaus Krause, мэйнтенер SDCC-кодогенератора для Z80. Люди достаточно далёкие от Оберонов. Но они разрабатывали. Много и долго. Поэтому научились уважать чужие идеи и любые средства разработки. Ибо если их зачем-то разрабатывали, значит зачем-то они нужны. Это вопрос личностного и профессионального роста. Я не жду этого от всех, ибо наивно.
Мы тут о спектруме разговариваем, а значит предполгается что мы кодим на Асме и Бейсике. Какие нафиг Явы, СИ и Дельфи?
Если смущает факт разработки для Спека на чём-то ещё, кроме асма и Бейсика, то лично мне (как, надеюсь, и вам) никак не претит с удовольствием поиграть в ускоренного Дурака от CoppeFeet, Moggy или Phantomas Saga – Infinity или (вы удивитесь!) Cauldron. Мне кажется, отрицать пользу высокоуровневой разработки для Спека – это сознательно сужать область его применения. Для хорошо реализованных кросскомпиляторов с языков высокого уровня польза для Спека – для быстрого макетирования, в банальном облегчении трудоёмкости при создании утилит и кроссплатформенной (Спектрум в связи с другими платформами) разработки, создании обёрток с нижайшим оверхедом вокруг асм-библиотек, с последующей разработкой на них в качестве структурно-модульного клея. А может этот барьер умов в неприятии ЯВУ для Спектрум-разработки – хороший повод пойти покодить на асме, оставив высокоуровневое направление для тех, кому оно интересно? Всё же лучше, чем забить тем и другим на Спек вообще.
Ещё меня привлекает возможность, как и 15 лет назад (а помнишь, Alone, как ты меня упрекал в желании скрестить ПЦ и Спек? :smile:), разрабатывать на одном языке для Спектрума тако же, как и для других платформ. Уникальные алгоритмы, реализованные на Спеке, красивейшие по задумке и блестящие по реализации игры. Всё это можно и нужно использовать на других платформах. Но Бейсик и асм тут вряд ли годятся. А в эмуле кодить – это вы уж извольте. Да, на Си тоже можно, но Оберон лучше. Более высокий уровень. В связке Оберон + Си + асм, впрочем, можно получить лучшее от каждого из этих средств, то, в чём их сила. Асм – низкоуровневые подпрограммы для скорости и мощности, сама реализация, уровень “КАК это реализуется на Спеке”, Си – … гм, ну, применение найдётся. Например, в качестве связующего звена между Обероном и асмом. Ну и его величество – Оберон (уровень “ЧТО надо сделать”). Прошу любить и жаловать. Заметьте, уровень не подразумевает лишь только Спек. Мне удалось настолько хорошо абстрагировать Даш от платформы, что уши Спека из основного алгоритма, сердца и логики, не торчат аж вообще никак. Без ifdef'ов. Вот-с. Да вы можете это заметить хотя бы по исходнику процедуры Play.
Если смущает факт разработки для Спека на чём-то ещё, кроме асма и Бейсика
Смущает необходимость изучать новый язык и среду разработки.
Я на пц обхожусь PureBasic / PHP / JS / C, на спектруме Ассемблером.
Куда логичнее перенести на спектрум, что то из перечисленного чем изучать новое.
не хотелось бы вдаваться в палемику, но всё же:
#include не устарели нисколько и актуальны хоть даже сейчас?
не устарели и ещё долго не устареют, т.к. другого способа включить в собираемый проект какие то нужные части пока не придумали. если в оберне нельзя делать подгрузку таких кусоков, зачем он тогда нужен?
Ага, значит “:=” это уродство, а “==” – признанная всеми
нет не всеми. в том же пуре бесике или в том же blitz basic`е оператор сравнения не отличается от оператора присвоения. на си его отделили. теперь уже поздно говорить о том, что верно это было решение или нет.
языке C программист может написать конструкцию x+++++y, загадку, а не выражение
не может. такие конструкции являются особенностями отдельных компиляторов.
А ещё и ифдефов нет!
ифдефы очень помогают, когда нужны условия компиляции или сделать макросы. очень жаль временами бывает, что в том же блице нет таких штук.
устаревшие архаичные BEGIN и VAR? Это вообще плевок в лицо
какие плевки, вы о чём? товарищ кроме бегловго взгляда смотрел ещё на какие то языки? конструкции с участием бегинов и варов существует великое множество. причём не только в языках программирования, но и в отдельных скриптовых языках. например в том же lua, например в том же папирусе..да много где. загляните в игры, таже серия игр от бетезды - фаллауты (3 и нью вегас), обливион, скайрим. можно заглянуть в в язык mel который используется в autodesk maya.
языков существует привеликое множество. мне вот например импонирует отдельно блиц за его простоту, си за возможности...ну пожалуй луа за унивирсальность. любой язык можно применить к спектруму и любой другой платформе. что, точнее чем так выделяется оберон, пока не понял. по виду типичный бейсик, судя по синтаксису,с примесью паскаля/дельфи.
Oleg N. Cher
09.03.2012, 18:22
А вот мне оберон (да и все остальные паскали) не нравится тем, что переменные процедуры нужно в отдельной секции описывать. На процедурах размером по 400+ строк, имеющих несколько десятков переменных удобнее концепция фрейма.
Вряд ли Вам щас понравится, если я начну про засратые сями и явой мозги парить, правда? :wink: То-то же.
int a = 10; // фрейм 0
if (true) {
int b = 10; // фрейм 1
}
// здесь переменные фрейма 1 уже не видны.
Надеюсь, понятно объяснил. Не совсем по науке, но суть такая.
Такие вещи в Виртовской линейке языков обычно решаются вложенными процедурами, что примерно то же, но Ваш "фрейм" штука анонимная, а процедура позволяет показать что Вы имели ввиду, решив построить код именно таким образом.
PROCEDURE A;
VAR
z, x: INTEGER; (* Это общие для "фреймов" переменные *);
PROCEDURE Frame1; VAR a, b (* Это личные переменные "фрейма" Frame1 *)
END Frame1;
PROCEDURE Frame2; VAR a, b (* Это личные переменные "фрейма" Frame2 *)
END Frame2;
BEGIN ...
END A;
Интересует возможность поюзать Оберон для работы с объектами ООП.
Оберон-2:
TYPE
ElemType = INTEGER;
Stack = RECORD
a, b ... (* это внутренняя реализация, снаружи не видно – инкапсуляция *)
END;
PROCEDURE (VAR s: Stack) Push* (elem: ElemType);
...
PROCEDURE (VAR s: Stack) Pop* (): ElemType;
(* Здесь s – это поименованный self, снова не анонимный. Это удобно *)
...
VAR
stack1, stack2: Stack;
BEGIN
stack1.Push(123); stack2.Push(stack1.Pop());
В Active Oberon малость посложнее, там есть милые сердцу OBJECT и SELF, но принцип в целом тот же.
А вот наследование:
TYPE
ExtendedStack = RECORD (Stack)
(* Запись унаследована от расширяемой записи Stack *)
a, b, c: SomeType; (* Это дополнительные поля *)
END;
PROCEDURE (VAR es: ExtendedStack) SomeProc1 ...
PROCEDURE (VAR es: ExtendedStack) SomeProc2 ...
(* Это доп. методы *)
http://forum.oberoncore.ru/viewtopic.php?f=8&t=2121
http://forum.oberoncore.ru/viewtopic.php?f=29&t=2125
Я на пц обхожусь PureBasic / PHP / JS / C, на спектруме Ассемблером.
Куда логичнее перенести на спектрум, что то из перечисленного чем изучать новое.
Перенести на Спек PHP или JS? Ор-ригинально, батенька. Уже кажется Java переносили, тока 32-битность помешала. Но попробуйте, чего ж. А раз освоили PHP (и особенно JS), то Обероны пустячок, уверяю-с. :wink:
А Вы вот это видели?
ZX BASIC compiler v1.2.5, by Jose Rodriguez.
Allows you to write a BASIC program on your PC and convert it to TZX to run on your real Speccy/emulator. The compiler works in all of PC/Windows, Linux and Mac OS X.
http://www.boriel.com/software/the-zx-basic-compiler/?lang=en
Z80 Advanced Forth Compiler build 8 (PC/Windows), by Dumitru Florin Gabriel.
http://www.worldofspectrum.org/utilities.html (оф.сайт не открылся)
The ccz80 language
CCZ80 v2.0.5 (PC/Windows), by Emilio Guerrero.
The ccz80 language has a syntax based on the C language and produces assembler code - an assembler is integrated in the compiler.
http://www.telefonica.net/web2/emilioguerrero/ccz80/ccz80.html
Вобщем, осталось только Обероны освоить. И сделать компилер. Всё остальное для Z80 уже есть. :wink:
Поддерживаю создание компилятора Оберон'а для спектрума.
Oberon который чистый практически полностью ложится LL1 грамматики (там одно или два исключения, не помню уже), Active Oberon чуть хуже ложится на LL1 из за "атрибутов", но все равно на порядок лучше чем тот же С.
Значит этот язык естественным образом ложится за один проход на стековую машину (скорость компиляции!), а ей не присущи проблемы планирования ресурсов как в компиляторах под регистровые машины, в итоге код сгенеренный в лоб под стековую машину и разложенный на регистры Z80 (тож в лоб), будет если не быстрее, то уже точно не будет катастрофически отставать от цепочки oberon->ofront->C->sdcc->z80, sdcc тож не подарочек в кодогенерации
Не подарочек, однако его достоинство в том, что он есть! И развивается.
Господа, прошу покорнейше в ветке http://zx.pk.ru/showthread.php?t=18387 раскрыть своё видение каким по-Вашему должен быть компилятор Оберона для ZX.
---------- Post added at 16:22 ---------- Previous post was at 16:11 ----------
не хотелось бы вдаваться в палемику, но всё же
Не хочется впадать в маразм, но всё таки… Вы про модульность когда-нибудь слышали? Хорошо, посмотрим на проблему по-иному. ЗАЧЕМ включать кусок текста программы в кусок текста программы?
Реальный пример из реальной жизни. У меня в проекте Дурак есть тип BOOLEAN, внутри SYSTEM.h, не то что мне так захотелось, так по задумке создателей Офронта назван стандартный тип. Теперь мне понадобилось при портировании под Win32/GCC подключить другой стандартный "модуль" windows.h, в нём тоже есть тип BOOLEAN. При инклюживании они оба накладываются друг на друга, #undef’ить один из них нельзя, так как это не #ifdef’ное определение, а тип. Вот Вам пагубность включения плоского куска текста в плоский кусок текста, без учёта накладок. Какая там к чёрту модульность. Но однако же вбилось в голову как шило, что никак иначе нельзя. Без этого сыр не настолько остр. Sayman, подобны же и Ваши другие претензии. Мы уже давно всё это обсосали на форуме OberonCore, я с Вами теряю время.
в том же пуре бесике или в том же blitz basic`е оператор сравнения не отличается от оператора присвоения. на си его отделили. теперь уже поздно говорить о том, что верно это было решение или нет.
Сравнение и присваивание это всё-таки разные вещи? В классическом Бейсике они помечались одинаковым "=", но отличались LET или IF.
Плевок тут в том, что Вы сразу схватились за клавиатуру охаить малонравящуюся Вам Дельфи-подобную муть, малопохожую на ту муть, в которой варитесь Вы, и подобные Вам идут за Вами, попирая Ваш шаг; имя им легион.
я вижу что с языками вы слабо знакомы, особенно с языком си.
так как это не 3ifdef’ное определение
#ifndef __BOOL
typedef unsigned int bool;
#define __BOOL
#endif
соответственно никто вам не мешает и инклуды в линухах подправить аналогичным образом. но только зачем, ведь проще обоSрать, чем понять.
вы даже не понимаете разницу между синонимом и макросом. почитайте внимательно мануал и тогда поймёте.
Плевок тут в том
плевок тут в том, что человек купив книгу и прочитав 10 или 20 страниц понимает, что такое ему не асилить и начинает на одном и другом и т.д. форумах громогласно возмущаться сложностью и навороченностью того или иного языка.
я не противник дельфи, когда то пробовал понять и изучить и паскаля и дельфи. но понял что асилить не смогу. переехал на си. однако то что изучил, помогло в дальнейшем понимать чужие исходники на паскале.
кроме того, есть ещё один момент - если нельзя "ундефить" тип, значит можно использовать тот что уже есть на той платформе, под которую портируете свой проект. в крайнем случае, никто не мешает создать свой, например uboool. это плата за портируемость. если язык не позволяет делать кроссплатформенные программы (пусть даже с какими то переделками),то у такого языка мало шансов на выживание. если, например, у такого типа как int на пц разрядность 32 бита, то на спектруме у него 16 бит разрябность и при портировании это учитывается. очень сомневаюсь что в обероне такие детали учтены.
могу привести пример - я взял исходники программы mkfs под мсхдос и портировал под профи. пришлось поработать над библиотекой, избавиться от функционала мсх, однако сама прога собралась замечательно, даже фирменные баги перешли на профика. единственное, я там убрал одну единстенную функцию, которая делал обращение к мсхдос и вызывала низкоуровневое форматирование. а вот fsck вапще не меняя просто скомпилил и она сразу заработала. я лично сомневаюсь в том, что можно взять исзодники под оберона и собрать так же просто на нашем брате. но спорить не буду. удаляюсь...
SpecialistMK87
09.03.2012, 18:57
для хобби синтаксис наверно и не важен :)
для серьезной работы важно:
время выполнение работ по разработке ПО;
надежность кода;
сопровождаемость кода ( уволился программист или в отпуск пошел ).
наличие излишеств вроде VAR, BEGIN, END и т.п. уже сами по себе
для большинства программистов снижают читаемость кода, ухудшают сопровождаемость, увеличают сроки разработки. А все это - стоимость... Более длинный код тяжелее проверить.
:= почему плохо?
большинство программистов уже привыкло ставить '=' и '=='. И уже неважно 'правильно' это или нет. Это уже есть. Применив в разработке язык с присвоением ':=' получишь сразу увеличение сроков и стоимости. Только за счет такой мелочи!
Правда, бывает другая крайность - например, Perl. Исходники совсем короткие, пишешь быстро, зато даже самому потом нелегко разобраться
На мой взляд, оптимум с точки зрения синтаксиса сейчас Python 2.x. Заодно заставляет программистов аккуратно исходник форматировать. И большие проекты на нем очень хорошо делать - быстрее в 2-3 раза чем аналогичный код на C/C++.
Порой деваться некуда и приходиться писать программы на том языке, который есть под конкретную аппаратуру. Но когда есть возможность выбора - зачем создавать себе ненужные проблемы?
Такое хобби как oberon-2 можно уважать, но БОЛЬШИНСТВУ программистов-профессионалов его синтаксис не понравится. Можно порассуждать и обосновать с 'научной' точки зрения почему они дураки, а Вирт умный но это будет уход от реальности
мое мнение - Вирт с самого начала разрабатывал языки, с удобным для него лично синтаксисом. Он ведь много их разработал (в том числе Algol W, Pascal, Modula, Oberon ), широко применялся только Pascal, причем его основное назначение - обучение студентов. Лично я вздохнул с облегчением, когда перешел с него на C. Уже за одни фигурные скобки спасибо Ричи можно сказать. И я не один такой. Т.е. Вирту удобно, мне нет. И большинству - нет.
PS ' ; ' - это тоже архаизм и излишество :v2_dizzy_snowball:
Alex Rider
09.03.2012, 19:18
Ветка превратилась в очередное соревнование "язык, который я удосужился выучить, лучше, чем тот, который знаете вы" (фаллометрию). Мне приходилось по жизни писать на 36 разных языках (включая диалекты, правда). Язык что выучить, что использовать - это сущие пустяки. Основная трудность - набор библиотек к ним. Язык выбирается исходя из простоты решения задачи на нем. Мой любимый яхык - это тот, с помощью которого я зарабатываю деньги. В остальном все языки одинаковы. Не зависимо от == и :=, например. Я этого просто не замечаю, автоматичемки использую нужные конструкции где надо. Так что учите языки (это, повторюсь, пустячная задача), используйте их на практике, и переставайте наезжать на VAR, ';' или #define - это смешно.
Oleg N. Cher
09.03.2012, 19:47
#ifndef __BOOL
typedef unsigned int bool;
#define __BOOL
#endif
Я вижу, Вы слабо вникли в высказанную мною проблему. Я ещё раз повторюсь: оба "модуля" – стандартные, править их крайне дурной тон. Я просто хотел бы воспользоваться ими одномоментно, включить их в один свой модуль сразу оба, как библиотечные, но они мешают друг другу, потому что не знают ничего друг о друге. Тут же умники придумали затычку – пространства имён. И тут же возвели её в культ. А другие умники потихоньку к ней привыкли и разучились видеть какие-то другие решения.
никто не мешает создать свой, например uboool.
Эхехе. Меня кажется не слышали. Эгей, товарищ! Оба "модуля" стандартные!!!
Наверное Вы просто больших программ не писали, и привыкли пользоваться затычками. Это очень плохо.
если язык не позволяет делать кросскак int на пц разрядность 32 бита, то на спектруме у него 16 бит разрябность и при портировании это учитывается. очень сомневаюсь что в обероне такие детали учтены.
О, представьте себе, в Обероне сделано ещё лучше, в нём при написании одних модулей разрядность платформы можно учитывать, а при написании других – игнорировать.
Всё же мне кажется, на Обероны Вам не хватит терпения.
Ладно, продолжаем ликбез.
В Оберонах уже довольно давно вместо тупого включения куска текста в кусок текста программы, порождающего массу проблем зависимости между разными частями программы, предусмотрена модульность, и даже не только статическая, но и динамическая. Ближайший аналог этой концепции – механизм .SO/DLL в Linux/Windows.
Осмелюсь утверждать, что Оберон-концепт более совершенен, ибо динамические Оберон-модули не зависят от базовой платформы и хост-системы, оставаясь Оберон-модулями, они – возможность языковая, не имеющая аналога на уровне языка ни в Си, ни в Паскале, кроме того, в отличии от .SO/DLL модули могут включать, помимо процедур, ещё и типы, константы и переменные.
Особенности поддержки концепции модуля
в языках Delphi (Object Pascal), Modula-2 и Оберон
http://www.oberon2005.oberoncore.ru/qa261005.html
Динамическая модульность в BlackBox - OberonCore
http://oberoncore.ru/wiki/динамическая_модульность
Модульное программирование: Terra Incognita
http://oberon2005.oberoncore.ru/qa191005.html
могу привести пример - я взял исходники программы mkfs под мсхдос и портировал под профи. пришлось поработать над библиотекой, избавиться от функционала мсх, однако сама прога собралась замечательно, даже фирменные баги перешли на профика. единственное, я там убрал одну единстенную функцию, которая делал обращение к мсхдос и вызывала низкоуровневое форматирование. а вот fsck вапще не меняя просто скомпилил и она сразу заработала. я лично сомневаюсь в том, что можно взять исзодники под оберона и собрать так же просто на нашем брате. но спорить не буду. удаляюсь...
Вероятно, готовые программы, содержащие ошибки проектирования, будет переносить так же непросто, как и программы на Си, если модули очень плотно к платформе приклеены, буквально в каждой процедуре подразумевается, что платформа именно такая. Обероны же могут помочь в получении более чисто спроектированной программы. Кстати, выработать кроссплатформенную логику библиотек, достаточно экономичную для разворачивания как на Спеке, так и на других платформах, ИМХО достойная задача. Можно поработать в этом направлении.
Oleg N. Cher
09.03.2012, 20:04
Я бы предпочёл более осмысленно вести диалог, помогая желающим научиться писать проги на Обероне для Спека. И только это. Но увы. Обсуждение вылилось в то, во что оно вылилось.
Если возник вопрос – зачем программировать на Обероне для Спека, если можно на Си? Си популярен. Оберон малоизвестен. Си опробован. Оберон наверняка содержит подводные камни. Когда-нибудь я опишу, возможно, здесь на форуме, как я пришёл к Оберонам, однако пока могу только попросить желающих программировать на Си вместо Оберона не уподобляться господину, который Толстого не читал, но произведения оного ему определённо не нравятся.
Если сомневаетесь в моей квалификации, надо вспомнить, что моя первая игра для Спека – Tiny Tetri$ на Бейсике и асме – разработана в 1995 году. Это, наверное, должно значить, что Бейсик и асм для меня давно не являются чем-то новым, а раз так, то, наверное, если я говорю о преимуществах Оберона перед Бейсиком, то есть смысл прислушаться, тако же когда я буду говорить об Оберон-разработке для Спека. Хотя я не собираюсь ничего никому навязывать. Бейсик был хорош тем, что его интерпретатор влез в ПЗУ. Это от бедности. Форт там тоже бы красиво смотрелся. Наверно.
А ещё – есть люди-создатели и люди-потребители. И спектрумисты, как никто, должны понимать между ними разницу. При этом создатель создаёт и делает что-либо доступным, включая идеи, а потребитель обливает всё *****м и кричит ”давай ещё, и побольше”, угнетая и без того хрупкие и чувствительные натуры создателей.
Alex Rider
09.03.2012, 20:46
Если возник вопрос – зачем программировать на Обероне для Спека, если можно на Си?
Действительно. Да и на Си не зачем. Потому что язык должен быть эфективным. Я вот в первом своем посте в этой ветке запамятовал сказать, что не только язык, но и среда разработки должна быть эффективной. Для Спека пишут на всяких Бэйсиках и ассемблерах по причине того, что это отлаживать хоть как-то можно. Вроде как, Форт еще позволяет отлаживаться хоть как-то. А на Си и Паскале не пишут, а балуются. Потому что вот ну никак вот не получается отладить по шагам написанный код, посмотреть значения переменных на рантайме, глянуть, что нарисовалось на экране, что несерьезно в больших проектах. А связку Оберон - Си - ассемблер вообще не понятно как отлаживать на целевой платформе.
Oleg N. Cher
09.03.2012, 21:05
я вижу что с языками вы слабо знакомы, особенно с языком си.
Очень весело слышать это, в особенности от Вас, уважаемый.
Хорошо. Ладно. Допустим даже, что Ваш макрос “помог”. Мы влезли в оба заголовочных "модуля", Офронта и винды, и вставили туда наше рулезное дополнение. Ибо одним "модулем" тут правка, видимо, ограничиться не может. Если может, блесните умом.
Но ещё и представим себе довольно вероятную возможность, что тип BOOLEAN внутри SYSTEM.h у нас является типом signed char, а тип BOOLEAN внутри windows.h – типом usnigned int.
Итак. Внутри windows.h мы имеем нечто такое:
#ifndef __BOOL
typedef unsigned int BOOLEAN;
#define __BOOL
#endif
Внутри SYSTEM.h же мы имеем нечто такое:
#ifndef __BOOL
typedef signed char BOOLEAN;
#define __BOOL
#endif
Наш весёлый "модуль" SYSTEM.c, думая, что тип BOOLEAN является однобайтовым, хотя его подленько уже могли подменить инклюдом windows.h перед инклюдом SYSTEM.h (а Си-прога, которая так сделает, может строиться Офронтом автоматически) на четырёхбайтовый, начинает юзать его во всю его однобайтовую душу. И – понесла нелёгкая, перекорёжив разрядность типов.
А наша весёлая программа могла бы конечно учесть, что BOOLEAN в таком разе – штука непростая, и надо выкурить много бамбуку, чтобы получить хоть какую-то осмысленную пользу от его использования, а ещё оно сильно вообще зависит от порядка инклюдирования "модулей" SYSTEM.h и windows.h, что ещё полбеды, а основная беда начнётся когда "модулям", берущим тип из SYSTEМ.h и windows.h, неявно подпихнут другой тип, их это должно здорово взбодрить.
Хорошо если программа сразу вылетит, а если не заметишь, и вылеты с порчей памяти и загадочным залезанием в чужие области и желанием выслать отчёт к какой-то матери регулярно будут у заказчика через месяц после сдачи?
Я как раз – об ощутимой помощи от использования Оберон-технологий в как можно более скорейшем выявлении такого рода узких мест. И чтобы влияние как закрытой реализации, так и открытой интерфейсной части одного модуля на другой сводилось к минимуму.
насчет препроцессоров, уже прошли те времена когда препроцессор надо было иметь именно встроенном в языке, можно просто взять и заюзать внешний, например мой http://code.google.com/p/java-comment-preprocessor/
Alex Rider
09.03.2012, 21:13
Реальный пример из реальной жизни. У меня в проекте Дурак есть тип BOOLEAN, внутри SYSTEM.h, не то что мне так захотелось, так по задумке создателей Офронта назван стандартный тип. Теперь мне понадобилось при портировании под Win32/GCC подключить другой стандартный "модуль" windows.h, в нём тоже есть тип BOOLEAN.
А это вообще народная программерская забава такая - намешать в одном коде исходников несовместимых от разных комплектов библиотек, и объявить язык убогим за то, что он это позволил.
Oleg N. Cher
09.03.2012, 22:34
Действительно. Да и на Си не зачем. Потому что язык должен быть эфективным. Я вот в первом своем посте в этой ветке запамятовал сказать, что не только язык, но и среда разработки должна быть эффективной. Для Спека пишут на всяких Бэйсиках и ассемблерах по причине того, что это отлаживать хоть как-то можно. Вроде как, Форт еще позволяет отлаживаться хоть как-то. А на Си и Паскале не пишут, а балуются. Потому что вот ну никак вот не получается отладить по шагам написанный код, посмотреть значения переменных на рантайме, глянуть, что нарисовалось на экране, что несерьезно в больших проектах. А связку Оберон - Си - ассемблер вообще не понятно как отлаживать на целевой платформе.
Вопрос действительно очень интересный и не имеющий одного простого решения. С одной, впрочем, стороны поймём, что масштаб Оберон-проектов для ZX пока что ограничен 48кб памяти, поэтому говорить о реально больших проектах не приходится. С другой – взгляды Оберон-сообщества на отладку Вам вряд ли понравится.
Я использую для отладки ASSERT'ы, и debug-вставки с отладочной распечаткой.
MODULE Sets; (* portable *)
CONST
Debug* = TRUE;
END Sets.
MODULE Grx; (* portable *)
IMPORT Sets, Debug;
...
PROCEDURE PutSprite* (x, y: SpriteCoords; spr: Sprite);
BEGIN
IF Sets.Debug THEN (* Это прямой аналог ifdef'а, однако если Debug = FALSE, то никакого лишнего кода в прогу не вставится *)
CASE x OF 0..MaxX: CASE y OF 0..MaxY: ELSE Debug.Stop("Bad sprite coords!") END END;
END;
...
END PutSprite;
END Grx.
Для профилирования использую эмулятор Fuse. В качестве пошагового отладчика – эмулятор Владимира Кладова EmuZWin. Так и баги в кодогенераторе SDCC искал, так и свои проги дебажил. С третьей стороны, если создать Оберон-обвязку в стиле ZX, то появляется интересная возможность отлаживать кроссплатформенные Оберон-модули, подходящие и для ZX, внутри хост-Оберон-среды типа A2 или BlackBox. Это возможно. Надо разрабатывать инструментарий.
Я также не против иметь готовый пошаговый отладчик Оберон-программ чисто для Z80. Осталось его написать.
А ещё Вы удивитесь и не поверите, но на самом деле потребность в отладке в Оберон-программах не такая большая, значительно меньше, чем на Си. Помогает и охрана типов, и автоматическое управление памятью. Но это не про связку Ofront/SDCC.
А это вообще народная программерская забава такая - намешать в одном коде исходников несовместимых от разных комплектов библиотек, и объявить язык убогим за то, что он это позволил.
Угу, а кто их объявил несовместимыми друг с другом? Это же "модули"! :v2_dizzy_mutant:
насчет препроцессоров, уже прошли те времена когда препроцессор надо было иметь именно встроенном в языке, можно просто взять и заюзать внешний, например мой http://code.google.com/p/java-comment-preprocessor/
Именно!
Вот. Игорю тоже пришлось. :)
Raider, Raydac, можете поспособствовать регистрации на данном форуме ещё одного оберонщика и спектрумиста? Ибо он пробовал зарегистрироваться, но регистрация отключена администрацией. Типа намёк: не любят здесь неофитов. А я припёрся весь такой красивый. :)
Ибо он пробовал зарегистрироваться, но регистрация отключена администрацией. Типа намёк: не любят здесь неофитов.
prisekar - Регистрация: 07.03.2012
Alex Rider
09.03.2012, 23:13
Угу, а кто их объявил несовместимыми друг с другом?
Здравый смысл. Использование модулей из разных библиотек черевато неприятностями. Ты встретил такую неприятность.
Oleg N. Cher
09.03.2012, 23:39
Здравый смысл. Использование модулей из разных библиотек черевато неприятностями.
Сказано сильно. А в Оберонах модули и библиотеки – это одно и то же.
не имею желания с вами спорить. верьте во что желаете и считаете нужным. учите доки, читайте. я уже прошол через приведённые вами костыли и у меня это не вызывает проблем.
Sayman, мы с Вами говорим не только о разных языках, но и на разных языках. Я Вам про узкие места Си и про саму ущербность принятых там идеологических решений, с примерами, а Вы вроде даже не поняли примера. Начали мне тыкать костыль – эмулятор модульности ”#ifndef ___VARY_BAD #define ___VARY_BAD , надеясь меня этим удивить. Вы полагаете, что я не видел эдакого построения? Да нет же, и видел, и пользую. Даже выкладывал где-то тут SYSTEM.h, в котором применяется онная хрень. Однако Вы даже не предложили нормального способа решить обозначенную мною проблему, а просто послали меня учить матчасть. А я Вам – про идеологию, в которой таких проблем быть в принципе не может. В целях повышения образованности, как говаривал почтальон Печкин.
---------- Post added at 21:39 ---------- Previous post was at 21:30 ----------
prisekar - Регистрация: 07.03.2012
Я только что попробовал, и правда отключена.
CityAceE, агов! И где он бегает...
Black_Cat
09.03.2012, 23:44
И где он бегает...на другой стороне Земли во Владике, в будущем на девять часов :) , так что учитывайте разность времени, когда стучитесь :)
Alex Rider
09.03.2012, 23:45
Сказано сильно. А в Оберонах модули и библиотеки – это одно и то же.
Круто. Вот в Delphi можно сказать, что есть модуль Forms.pas библиотеки VCL. В Visual C++ есть библиотеки ATL, MFC с модулями внутри. А в Обероне не принято группировать модули (библиотеки?) по принципу разработки для совместного использования что ли? Каждый кусок кода в отдельном файле, разработанный кем-либо - он сам по себе, и все вместе попарно они всегда совместимы?
Что-то в пылу дискуссии подзабыли, что на Спектруме 3,5 МГц, а не 3,5 ГГц. И всё по возможности надо делать не в рантайме, а в компайл-тайме.
Oleg N. Cher
10.03.2012, 12:46
я вижу что с языками вы слабо знакомы, особенно с языком си.
Ну почему Raider’у хватило скромности притушить свой нимб и прийти спрашивать вопросы, а не выпячивать пиписку? Уже и newart, вместо критики, начинает подумывать об изучении Оберона. Значит моя цель достигнута.
Господа любители Си, особенно те, кто читает ветку с конца. Не надо, подобно Sayman'у, выпячивать грудь и кидаться сгоряча. Он хотел поучить зарвавшегося неофита, а на деле просто продемонстрировал свою некомпетентность. Понятно желание бывалого сишника заступиться за любимый язык. Но Си не поругаем, он просто сравнительно критикуем. Или вы считали его идеальным языком? А тут пришёл пиписькин сын неофит, который удосужился выучить что-то другое, но, кроме этого, не знает нифига языков, и теперь парит моск и всех свысока поучает, ибо ему больше некак самовыразиться? Я думаю, ситуация так выглядит не для всех, что всё-таки радует. Радует реакция Raydac, Valen и Alone.
Однако давайте всё-таки сделаем здесь “ловушку” для сишников. Господа сишники. Я понимаю, вам лень открывать и читать галимые ссылки, которые я даю, но всё-таки вот эту прочтите. Может желание облить меня помоями поутихнет? Негуманно всё-таки брата-спектрумиста так прокатывать. Или мне показать вам длинный список сделанных мною программ на Си? Там будет и графическая среда для смешивания лиц, и программа для сжатия почтового трафика VIPmail http://colossoft.anarxi.st/?go=vipmail, и сетевой многопоточный движок ROSE, и всякого рода системы для бухгалтерий и интернет-биллинга http://colossoft.anarxi.st/index.php?go=stefport. Так это уже то самое натуральное меряние пиписками, которого так не хотел я и, в особенности, Sayman. А как думаете. Си крут. Но бортовое п/о на всяческих вояджерах на Си писать не торопятся. Почему-то. Я упоминал о бортовом п/о для безпилотного вертолёта на Обероне. Это показательно. Упомяну ещё и о системе управления ГЭС на Амазонке, сделанной в среде BlackBox.
http://ru.wikipedia.org/wiki/Компонентный_Паскаль
http://oberoncore.ru/articles/gubanov
Модула-2 в российском космосе
http://www.kronos.ru/about/koltashev
Ну хорошо, хорошо. Я неофит, плохо знаю Си. Но вот есть капустная голова профессорская, привыкшая парить моск. Внимание, статья от Джозефа Темпла, автора транслятора Ofront. Это транслятор с языка Оберон-2 в Си. Это наверно подразумевает, что оный Темпл знает Оберон и знает Си вместе, в отличии от Sayman. И наверное показательно, что он написал такую статью, транслятор, и показательно, что он написал его с Оберона и на Обероне. Си-вариант получился “раскруткой”. Но зато теперь благодаря этой проделанной работе, мы с вами сейчас имеем удовольствие и общаться, и лицезреть нечто вот такое: http://norayr.arnet.am/weblog/?p=668 (ETH Oberon System, оттранслированная Ofront’ом и запущенная на интернет-таблетке Nokia N810).
Итак, господа.
Дж.Темпл. Oberon против C++
http://oberon2005.oberoncore.ru/paper/templ.pdf
И ещё интересненькое.
М.Франц. Java - критическая оценка
http://www.osp.ru/pcworld/1997/08/56.htm
http://oberon2005.oberoncore.ru/paper/obe_java1.pdf
И главное. Тут много об идеологических языковых маразмах. И автор умнейший. Кстати, автор компилятора с Оберона-2 в байт-код Java (JOB, Вологда. Гуглируйте).
С.З.Свердлов. Языки программирования и методы трансляции
http://uni-vologda.ac.ru/~c3c/landt/contents.htm
http://www.piter.com/book.phtml?978546900378
http://oberon2005.oberoncore.ru/book/ss2005a.pdf
http://progbook.ru/technologiya-programmirovaniya/798-sverdlov-yazyki-programmirovaniya-i-metody.html
Господа, не забываем читать. Я действительно интересные вещи даю.
Круто. Вот в Delphi можно сказать, что есть модуль Forms.pas библиотеки VCL. В Visual C++ есть библиотеки ATL, MFC с модулями внутри. А в Обероне не принято группировать модули (библиотеки?) по принципу разработки для совместного использования что ли? Каждый кусок кода в отдельном файле, разработанный кем-либо - он сам по себе, и все вместе попарно они всегда совместимы?
В различных Оберонах применяются разные решения данного вопроса. Вообще Оберон-1 – он очень маленький. В него вошёл только тот самый необходимый минимум средств, которого, тем не менее, достаточно для разработки на нём операционной системы (http://www.oberon.ethz.ch/). Оберон-2 – это правильное надмножество Оберона-1, абсолютно совместимое с ним сверху вниз; добавились связанные с типом процедуры (методы), но в целом язык такой же маленький и простой, и ничего особо для группировки модулей в нём не предлагается. Далее из Оберона-1 вырастает Active Oberon (также сохранивший полную совместимость сверху-вниз с Обероном-1), основной фишкой которого есть активные объекты, каждый из которых может исполняться в своём потоке. В Active Oberon System (AOS) схожие по назначению модули можно группировать с помощью дополнительного префикса в имени. Например:
Win32.Files, Win32.Console,
Linux.Files, Linux.Console
А из Оберона-2 вырастает язык Компонентный Паскаль (с некоторыми оговорками – практически надмножество Оберона-2). Но в него внесены, на мой взгляд, очень важные вещи, нужные для промышленного применения и серьёзного системного программирования. Они не настолько уж критичны и необходимы, но с ними удобнее, например, портировать библиотеку Кладова KOL (с Delphi на Component Pascal). Нет. :smile: ифдефы сюда не вошли. Ну так вот, в системе BlackBox Component Builder (там КП – основной язык разработки) схожие по назначению модули группируются в подсистемы. Например, подсистема Dev – для разработки. Внутри неё модули DevCompiler, DevLinker, DevElfLinker и так далее. Подсистема Form – для построения GUI. Можно сказать, что подсистемы – это и есть "библиотеки", но на деле это просто группы модулей, которые было удобно сгруппировать, ибо их что-то связывает вместе. Модули эти могут импортировать и использовать дружественные модули из своей же подсистемы или же из других, а могут абсолютно не знать ничего друг о друге.
тогда да от оберона будет толк. тем более если он кроссплатформенный
Золотые слова, jerri.
Но, повторюсь, инструментарий для Оберонов развит очень скромно. Тут есть над чем поработать. И я рад, если просто кого-то заинтересую. Среди спектрумистов много энтузиастов [было раньше]. А Оберон-технологии – это конструктор, а не супермаркет.
Что-то в пылу дискуссии подзабыли, что на Спектруме 3,5 МГц, а не 3,5 ГГц. И всё по возможности надо делать не в рантайме, а в компайл-тайме.
Так никто обратного и не говорил, Alone. Я привёл пример с Debug’ом, там лишний код в компайл-тайме отбрасывается. Тут вопрос не в том, что ифдефы это плохо. Вопрос в том, что головы одурели настолько, что ифдеф уже лепится вместо ифа на автомате, а всё, что сверх того, нарушение прав и ущемление свобод.
чисто имхо насчет владения компьютерными языками
лучший компьютерный язык это тот компьютерный язык который лучше всего знаешь, правило "10 лет" никто не отменял (это правило в отношении экспертов согласно которому человек так медленно накапливает знания, решения ирецепты, что может считаться полноценным экспертом только после 10 лет владения какой то технологией), так что спорить "что лучше" смысла нет
в отношении спектрума имхо, если появится целевой кросс-компилятор с языка АДА, Фортран или Рапира с удобным отладчиком и IDE в Z80 то он получит популярность
Alex Rider
10.03.2012, 14:07
Ситуация с #ifdef и if понятна - Оберон не включает в бинарь те ветки if, которые при заданных значениях констант никогда не выполнятся. Выкидывать или ветвить по значению некоторой константы определения идентификаторов нельзя.
Ситуация с пересечением имен идентификаторов тоже понятна - вместо неймспейсов используются префиксы модулей, что примерно то же самое, и проблему использования модулей с конфликтами имен не исключает.
В целом, есть такое пожелание. Не хочу сказать за всех жителей форума, но я ленив. В частности, для того, чтобы читать просто тонны текста что в этой ветке, что в безмерном количестве ссылок тут. Чтобы что-то прочувствовать, мне надо простую инструкцию (надеюсь, я не один тут такой):
1. Скачать инструменты отсюда (URL), отсюда (URL), отсюда (URL).
2. Установить это, это и это.
3. Скачать исходики отсюда (URL), отсюда (URL), отсюда (URL)
3. Открыть это в этом, нажать это.
4. Открыть это в этом, нажать это.
5. Полученый trd (scl, txz, tap, udf, td0...) запустить в Спеке.
Вот так было бы круто. Так можно пощупать сразу хоть какой-то результат, почитать код, поменять его и побаловаться, оценить скорость и объем занятой памяти на строку кода. Да и готовый шаблон для создания чего-то своего. Для хобби теория скучна. Кнопки нажимать хочется. Глядишь, и вопросы с критикой из абстрактной плоскости перерастут в практическую.
Тока, если можно - пример чуть посложнее, чем Hello, world. И инструкцию в расчете не на гениев, которые из всех технологий только про Оберон не знают, а для простых смертных, которые для Спеки писали только на asm и Basic. Для всех, то бишь. Вот это дело будет!
Oleg N. Cher
10.03.2012, 15:06
Выкидывать или ветвить по значению некоторой константы определения идентификаторов нельзя.
Не совсем верно. Вот есть "Дубовые требования" ("Oakwood guidelines" – http://smalllinux.sourceforge.net/oberon/oakwood.htm), которые предлагают реализовать макропроцессор. Выглядит это примерно так:
<* SelectorName+ *> — включить
<* SelectorName- *> — выключить
<* IF условие THEN *>
строки вашей программы
<* ELSIF условие THEN *>
строки вашей программы
<* ELSE *>
строки вашей программы
<* END *>
Небольшой пример. Допустим, вам надо вычислять по формуле x = x * 2. Вы знаете, что на процессоре А быстрее выполняется вариант INC(x,x), а на процессоре Б — x:=ASH(x,1). Идти на компромисс вы не хотите, и иметь два разных файла для одной программы тоже. Выход такой:
<* IF ProcA THEN *>
INC(x,x);
<* ELSE *>
x:=ASH(x,1);
<* END *>
Подобные требования были реализованы в продукте XDS (http://www.excelsior-usa.com/xds.html) (Бесплатный оптимизирующий компилятор Модулы-2 и Оберона-2 для платформ Windows и Linux. Windows-версия имеет собственную среду разработки).
Никто, наконец, не мешает нам реализовать для Спека диалект Оберона, в котором будут даже алиасы регистров и системные расширения SYSTEM.EI, SYSTEM.DI, SYSTEM.IM2 и так далее. Обероны – это конструктор. А мы ленивы. Потому что Спектрум и творчество это раньше были синонимы. А теперь синонимы это потребительское отношение ко всему, включая экологию, и "делаю то, за что получаю бабки". Целое такое поколение взросло на наших глазах. Поколение скриптописателей. Они уже никогда не будут спектрумистами, не в смысле юзки 8-битной железяки с телевизором, а отношения того не будет. Ни к чему.
Ситуация с пересечением имен идентификаторов тоже понятна - вместо неймспейсов используются префиксы модулей, что примерно то же самое, и проблему использования модулей с конфликтами имен не исключает.Гм, а Вы хотели бы иметь несколько разных модулей ("библиотек"), названных одинаковыми именами и юзать их одномоментно? И называете это неразрешённым конфликтом имён? :frown: Давайте всё-таки делать разницу между конфликтами имён в именах модулей и в идентификаторах внутри этих модулей. Ещё раз повторяю: эта проблема в Оберонах решена блестяще. Ссылки я дал выше.
а для простых смертных, которые для Спеки писали только на asm и Basic. Для всех, то бишь. Вот это дело будет!
Примерно такая статья по задумке и готовится на http://zx.oberon2.ru/zx-dev.htm. Но пока что-то нету вдохновения. В форумах флеймить это вам не статьи умные писать. Со временем, что-то сделаю, надо думать.
Сначала программировать на Обероне не нравится. Плюёшься на всё и вся, но вот почему.
Принятые в Оберон-технологиях ограничения специально жёстко регламентируют огульное и повальное использование каких попало средств платформы (что только способствует переносимости целевого продукта) и языка, который обычно построен по принципу супермаркета (от предоставленных средств глаза разбегаются). Изначально исходник Dash был на Си (Turbo C 2.0, DOS) и был вообще так спаян с DOS, что развод представлялся чем-то невозможным. Теперешний исходник Dash на Си, полученный транслятором Ofront с Оберона выглядит намного более наглядно и платформенно-независимо по сравнению с изначальным вариантом, который писал, кстати, вовсе не ламер. А вы видели исходники Moggy или Phantomas Saga – Infinity? Да, они на Си, но попробуйте переписать их для чего-нибудь ещё. Это надо всё делать заново. Разумеется, на Си тоже можно писать иначе, но почему-то не пишут. А цель портирования Dash была в том, чтобы получить на Обероне исходник главного модуля игры отдельно от машинно-зависимых частей. Это хорошо получается на Обероне, в котором средства отделения мух от котлет достаточно выразительны. Причём эффективность данной языковой платформы – достаточна для разворачивания даже на Спеке. Я это увидел, и этого мне хватило чтобы почувствовать значительную мощь Оберонов. Теперь, подумал я, если бы игру Dash изначально разрабатывали на Обероне со следованием принципов, принятых в Оберон-технологиях (это не только язык или часть языка, это соглашения, конвенции, правила хорошего тона и ещё масса всего, что облегчает жизнь), то сейчас мы бы имели скелет программы настолько хорошо абстрагированной от платформы, что заменить платформенно-зависимые модули, тем самым перенося игру на другую платформу, было бы уже гораздо более простая работа, чем отделять мух от котлет в Дураке, Фантомасе или Могги. В последних эта работа не проделана, и практически даже не начата. Подчеркну, что в основном модуле Dash, где всё бегает, не применяются ifdef’ы или что-либо подобное. При следовании принятым концепциям это попросту не нужно. Да, я изобрёл способ делать не очень динамические игры для Спека, используя языковую Оберон-платформу таким образом, чтобы их можно было более легко развернуть на другую аппаратную платформу. Практически любую. Эффективность полученного Оберон-представления алгоритма – высокая. Достаточная для разворачивания на Спеке. Плюс в этом. Не в самом использовании Спека, его роль здесь не более чем лакмусовой бумажки, показателя высокого качества Оберон-технологий. Вот в чём сила Оберонов. Их красота – в минимальном использовании языковых средств для получаемого представления алгоритмов. Но этому умению надо долго учиться, это подразумевает пересмотр и изменение устоявшихся языковых стереотипов и прижившихся привычек, а этот путь не для тех, кто уже и так всё знает о виртуальных методах, обработке исключений и шаблонах, а также о регистровых парах и флагах со стеком. Надо думать, опять же, что многое из того, что я говорю об Обероне справедливо и для Си, но Си не настолько выразителен. Но если бы к Си++ программисту приставить жандарма, который бил бы по рукам за неправильное использование языковых средств, то это был бы почти идеальный вариант, если закрыть глаза на уродский синтаксис и навесное излишне сложное и перегруженное ООП. Но, заметьте, трудность освоения Си++ радует тех, кто к нему сопричастен, льстит самолюбие и даёт им повод, задрав нос, поучать неофитов: “какой-де мощный язык, понимаешь, целых пять лет учил, и до сих пор ещё учу”. Это же касается и синдрома линукса. Линуксоида просто превозносит тот объём ругательств командной строки, которые он постиг прежде чем ЭТО просто перестало раздражать. А чего плеваться, раз все вокруг твердят как это круто. Если сказать одним выражением, убирая все технические и психологические тонкости, то будет “стадо гонят пастухи”. Вот что обидно.
НАЧАЛО светлое весны...
Лесов зеленые МАССИВЫ
Цветут. И липы, И осины,
И ели помыслы ясны.
Себе ПРИСВОИЛ этот май
Права одеть листвою ветки,
И целый месяц в душах МЕТКИ
Он расставляет невзначай...
И пишется легко СТРОКА,
И на этюдник рвутся кисти,
Уходит ЛОЖЬ в обличье ИСТИН,
И говорю я ей: ПОКА!
С.А. Маркин.
Золотые слова, jerri.
Но, повторюсь, инструментарий для Оберонов развит очень скромно. Тут есть над чем поработать. И я рад, если просто кого-то заинтересую. Среди спектрумистов много энтузиастов [было раньше]. А Оберон-технологии – это конструктор, а не супермаркет.
Да я вообще очень часто прописными истинами сыплю :) только меня мало кто понимает :)
Alex Rider
10.03.2012, 16:02
Сначала программировать на Обероне не нравится.
Вот честно, мне не нравится программировать на Обероне! Совсем. И не буду пока даже начинать. Потому что не знаю с чего. Вообще не знаю. Просто... Вижу коллосальный объем буков, и руки опускаются.
Почитал недоработанную инструкцию на zx.oberon2.ru - опяты уныло. Опять много буков. Опять складывается впечталение, что язык Оберон создан концептологами для каких-то других -ологов, к которым я себя не отношу. Много философии, мало практики.
Вот скажите, Олег, а правда программировать на Обероне для Спектрума настролько сложно, что нет никакой возможности положить здесь, на форуме, несколько ссылок на инструменты и написать простой пример и краткую инструкцию, после выполнения которой что-то заработает?
Oleg N. Cher
10.03.2012, 16:32
Вот честно, мне не нравится программировать на Обероне!
Тут Вы сами себе противоречите. С одной стороны Вам не нравится делать то, что Вы никогда не делали, просто представляете себе это по аналогии. С другой, все языки примерно одинаковы, что Вы обозначили на форуме выше, так что с чего бы одному нравиться, другому нет.
Оберон создан концептологами для каких-то других -ологов, к которым я себя не отношу. Много философии, мало практики.
При чём тут -ологи, это у меня стиль такой. Я иде-олог. Не мечтаю запрограммировать на Обероне всё на свете. Мечтаю, чтобы это сделали за меня. Я вообще помощников искать пришёл, заинтересованных. Приоткрыть красоты. А не отгавкиваться, браться что-то для кого-то или за кого-то делать.
Я бы не назвал оберонщиков философствующими теоретиками и -ологами. Они помаленьку разрабатывают системы, библиотеки и трансляторы. Микроконтроллеры осваивают, и встраиваемое программирование. Пишут книги и статьи, в которых делятся опытом практических разработок.
Практическую пользу от размещения кода компилятора Coloss и игры на Coloss’е видели? Неа, все их тихонько скачали, положили на полочку и тихо забыли. Даже никто не написал “какая крутая игра и какой крутой компилятор”. А если бы я не дал ссылок, сейчас бы или просили их, или пеняли, что брешу, и что не было разработано никакого Coloss’а и никакой игры. Хотя я льщу себе надеждой, что мои здешние форумные опусы кого-то всё же вдохновят на реальные свершения. Впрочем, ещё ведь наверное много спектрумистов эту ветку не читали.
Вот скажите, Олег, а правда программировать на Обероне для Спектрума настролько сложно, что нет никакой возможности положить здесь, на форуме, несколько ссылок на инструменты и написать простой пример и краткую инструкцию, после выполнения которой что-то заработает?
Как видите, Алекс, это, как минимум, нетривиально. Как показатель – ещё никто, кроме меня, до этого не додумался (программить на Обероне для Спека). Но я ничего сверх меры не изобретал, просто сложил в кучу не-Оберон- и Оберон-технологии, сдобрил Оберон-видением перспективы.
Инструкция.
1. Качаем BlackBox Component Builder, любую сборку, устанавливаем.
2. Качаем SDCC, устанавливаем.
3. Делаем несколько машинных процедур на асме Z80 внутри сишных файлов.
4. Скачиваем Ofront, гуглируем-учимся ставить новые подсистемы в BlackBox, ставим Ofront. Делаем пустой модуль-заглушку, чтобы при трансляции Си-программы заменить его на сделанный в пункте 3. Смотрим как Ofront заманглил имена префиксами, делаем также в нашем Си-коде.
5. Делаем программу на Обероне, которая при трансляции Оберона в Си юзает пустые модули в качестве низкоуровневых из пункта 3, транслируем.
6. Компилируем получившиеся сишники в SDCC, SYSTEM.h берём в этой ветке выше.
Проблемы преобразования хекс-интеловского формата, выдаваемого SDCC, в бинарь, а бинаря в TRD/TAP/Z80 здесь уже рассматривались, повторяться не буду.
Короче, ждите статью. Я ведь тоже ленивый. И люблю делать то, что мне нравится, а не то, что меня просят сделать другие ленивые.
Инструкция.
1. Качаем BlackBox Component Builder, любую сборку, устанавливаем.
2. Качаем SDCC, устанавливаем.
3. Делаем несколько машинных процедур на асме Z80 внутри сишных файлов.
4. Скачиваем Ofront, гуглируем-учимся ставить новые подсистемы в BlackBox, ставим Ofront. Делаем пустой модуль-заглушку, чтобы при трансляции Си-программы заменить его на сделанный в пункте 3. Смотрим как Ofront заманглил имена префиксами, делаем также в нашем Си-коде.
5. Делаем программу на Обероне, которая при трансляции Оберона в Си юзает пустые модули в качестве низкоуровневых из пункта 3, транслируем.
6. Компилируем получившиеся сишники в SDCC, SYSTEM.h берём в этой ветке выше.
так так значит тут не хватает еще пары пунктов
0. учим С
...
7. оцениваем результат выпадаем в осадок - стираем оберон - пользуем С
это я к чему :) я не знаю С настолько чтобы выделенное мной обрело смысл
а учить С чтобы выучить Оберон
есть ли более простой способ с либами и уже настроенной средой?
Oleg N. Cher
11.03.2012, 11:27
для серьезной работы важно:
время выполнение работ по разработке ПО;
надежность кода;
Вот именно, SpecialistMK87. Наконец-то Вы сами это сказали. Вы о надёжности, а я о бомбах, см. ниже.
:= почему плохо?
большинство программистов уже привыкло ставить '=' и '=='. И уже неважно 'правильно' это или нет.
Использование конструкций = и == вместе в одном выражении рано или поздно подразумевает, что когда-нить по случайности или по невнимательности их перепутают со всеми вытекающими последствиями.
if(a=b)...
Вот здесь врыта мина со счётчиком наступаний, которая сработает обязательно. Даже если человек привык к ==
И Си весь "пестрит" такими начинками, об этом хорошо у Свердлова написано.
Резон позволять смешивать в одном выражении сравнение и присваивание заключался в том, чтобы:
a) сократить запись (что было актуально в пору маленьких экранов и неактуально сейчас, потому что сейчас на передний план выступает наглядность, которая подразумевает, что различные конструкции из выражения лучше развести, чтобы по возможности они выглядели конструкциями отдельными);
b) вручную указать тупому компилятору где и как лучше оптимизнуть.
Да, это было актуально в эпоху тупых компиляторов и маленьких экранов, к тому же народ после автокодов и асма был готов принять даже Фортран, не то что Си.
Поэтому я утверждаю аргументированно: конструкция == устарела и, соответственно, является архаичной. Смешивание присваиваний = и сравнений == в одном выражении устарело и является архаичным, а также является ещё и бомбой замедленного действия. И средством опасно ненадёжным. Для тех, кто пришёл из Бейсика, Паскаля, или же просто изучал математику в школе (или в универе) и не успел пройти "идеологической обработки" мэйнстримом. А Специалист о надёжности кода.
В ответ на эти железобетонные аргументы сишники обычно снисходительно отвечают: "а я так привык" "мне так ндравица" "у меня всё получается иди rtfm" или железное "а мне за это плотют", даже не понимая, насколько их надули. Слухи же об архаичности := злостно распускают в сети любители синтаксических извращений.
Занимаясь Оберонами, трудно всем угодить. Отбившаяся от мэйнстрима овца за пророка не канает.
Господам сишникам так осточертели многотомные 800-страничные талмуды, что их трусит паркинсон при виде чего-нить длинее sms'ки?
Я так понимаю, что конкретное – это готовый архив с исходниками, который Вы соберёте, посмотрите, поплюётесь и отложите в дальнюю полку? И придёте потом тут рассказать, что Оберон в связке – это лишнее звено, и ничего, кроме геморроя, он Вам лично не принёс.
Ну а так получается, автор до конца не раскрылся, спрятал за пазухой кусок пирога, которым не спешит делиться, а раз так, то значит остаётся какая-то неудовлетворённость от данной ветки. Что-то невысказанное, недоуложенное в голове. Как раньше был Спектрум. Это вызов, гопспода. Вызов самому себе.
От меня ждут, что я изрыгну и начну раскладывать по блюдцам? А помните те времена, когда в ZLIST изучали хитрые процедуры ПЗУ? Думаете это было проще, чем скачать сейчас SDCC и Ofront и запрограммить Спек на Обероне? Я, между прочим, преследую те цели, что пришёл искать тех, кто сделает за меня пошаговый отладчик Оберона для Z80. Вирт может против пошаговых отладчиков. Я только за.
так так значит тут не хватает еще пары пунктов
0. учим С
...
7. оцениваем результат выпадаем в осадок - стираем оберон - пользуем С
это я к чему :) я не знаю С настолько чтобы выделенное мной обрело смысл
а учить С чтобы выучить Оберон
есть ли более простой способ с либами и уже настроенной средой?
jerri, Вы правы. Способ с Офронтом подразумевает хорошее знание Си (хотя бы без плюсов). Среды нету, откуда ж ей взяться. Либ нету. Я просто брал те машиннокодовые процедуры, что было надо, и переводил на дикий синтаксис инлайн-асма SDCC.
Нету чего-то в стиле Visual Studio для Оберона под Z80. С подветкой синтаксиса, пошаговым отладчиком и набором библиотек. Ну не ждите вы от меня этого, ей-богу. Даже десятка два примеров готового кода, которых, видимо, добивается Raider, не сделают разработку на Обероне для Спека удобнее.
Так как же рассматривать мотивацию, отчего ветка превратилась в такое нечто? Да всё дело в том, что люди не любят инакомыслящих, вместо этого они кучкуются с единомышленниками и испытывают слабость даже к предрассудкам, если оные льстят их самолюбию.
Со всей ответственностью заявляю господам сишникам, что если они дочитали досюда и все мои посты не вызвали в них никаких перемен мнения об Обероне (не говорю о желании выучить Оберон), то никакого преимущества от использования Оберона перед Си для вас не будет. Ни на Спеке, ни на чём-нибудь ещё. Оставьте забавному старичку-профессору его забавные чудачества делать всё без отладчика, оставьте паршивой овце следовать своей тропой. Будьте великодушны, вы ведь такие многоопытные разработчики, столько всего перевидали на этом свете. А сишника из меня Вы всё равно не сделаете, хотя бы потому, что я уже сишник. Вынужден использовать. Уйдите вы отсюда. Вам неинтересно, не надо самовыражаться прям во всех ветках. А пинать ногами одинокую овечку – это вообще садистская забава.
Господа, предлагаю ввести в ветке модерацию совестью. Сообщения, не касающиеся разработки на Обероне, прямо считать неуважением ко мне, автору темы, и к тем, кто остался читать ветку и писать в неё по теме.
Oleg N. Cher, лично мне не нужно
чего-то в стиле Visual Studio для Оберона под Z80. С подветкой синтаксиса, пошаговым отладчиком и набором библиотек.
есть акелпад в котором я пишу. есть для него набор кодеров в том числе и подсветкой синтаксиса. Необходим только лишь знающий человек который этот кодер настроит. Никто не будет писать ИДЕ для оберона на спектруме - оно там просто не нужно. есть множество простых, понятных и очень гибких кроссредств. их всего-лишь надо настроить.
---------- Post added at 14:35 ---------- Previous post was at 14:29 ----------
Oleg N. Cher, поучись (http://zx.pk.ru/showthread.php?t=17788) как надо заинтересовывать людей. без шума, без негатива, без возмущений и картинных поз. Я java не знаю но то что нарисованно здесь (http://zx.pk.ru/showpost.php?p=476790&postcount=29) мне понятно и интересно. я могу уже и автору что-нибудь посоветовать и критику обоснованную навести.
Andrew771
11.03.2012, 15:16
А вот я наоборот за Оберон на Спеке! Я вообще-то сам начал разработку компилятора Паскаля для Спека. Раз уж пошла такая пьянка, выкладываю то, что уже имеется. Пока компилятор (запускать файл bat) может отводить нужное место для переменных, кроме записей пока.
Насчет присваивания := и выделения места заранее под переменные полностью согласен с Oleg N. Cher. Как раз компилятору для Спектрума удобнее заранее выделить место под все переменные, описанные в VAR в Паскале или Обероне, а не по ходу, как в Бейсике или С. Т.к. этого места мало, а хочется многого.
Только, я считаю, нужно делать кросс-компилятор с PC напрямую в асм Спектрума (в текстовом виде). Что и начал делать. Использовать только целые типы, символы и строки.
Oleg N. Cher, давай тогда вместе работать. Нужно только выбрать, Оберон или Паскаль.
Компилятор Оберона, кстати, очень хорошо описан в книге "Н.Вирт. Построение компиляторов" http://www.twirpx.com/file/715110/ , я по ней делаю Паскаль.
По поводу космоса: спутники TacSat гоняют Linux. http://www.linuxjournal.com/article/7767
По поводу if(a=b): все нормальные компиляторы выдают ворнинг.
Мне безразлично, как где пишется присваивание, важно чтобы были фичи и не было оверхэда. А в Обероне нет фич и есть оверхэд.
Oleg N. Cher
12.03.2012, 23:53
Verilog и C# наше все.
Будете смеяться и не верить, но корявости есть и в C# (отсылаю к книге Свердлова), кроме того, это язык одной корпорации, его успех или неуспех слабо связан с его достоинствами, и тоже дело корпоративное.
Oleg N. Cher, поучись (http://zx.pk.ru/showthread.php?t=17788) как надо заинтересовывать людей.
Хотите несколько слов о причинах малой популярности Оберонов? Она прямо коррелирует с огромным количеством малокомпетентных людей, которые слабо разбираются в технологиях и готовы за деньги заниматься чем угодно, и, естественно, превозносить своё болотце.
Профессора, который в одиночку или в маленьком коллективе разрабатывает операционные системы, компиляторы и бортовое п/о такие здесь светочи разума называют теоретиком, а собственное скриптописательство для 1С в рамках готовых к употреблению технологий – это непременная глубочайшая практика. Деланье ежедневных заплаток на PHP к веб-сайтам потому что кушать хоца – это высокий кодинг, почти искусство. И при этом никто далеко не против прийти сюда и рассказать, какой-де он крутой разработчик, куда-де до него тупым маразматикам без долбаггера.
И эта точка зрения муссируется в инете и имеет очень широкое хождение. И любителей самоутвердиться и попинать профессора более чем достаточно. Я же призываю не считать Вирта пустофилософствующим дураком без практики, потому что он явно опытнее и умнее скриптососов, от чего последние просто готовы рвать меня на куски. Но я иду на конфликт сознательно, не пытаясь его смягчить, ибо популяризовать идеи, лежащие в основе Оберон-технологий, невозможно на старом материале. Чтобы захотеть попробовать Оберон – нужно не испытывать к нему заочного отвращения. Чего у многих не наблюдается.
Я замечал, чем самоувереннее и безапелляционнее высказывается программист, тем чаще он бывает некомпетентен. И наоборот, программист открытый к познанию нового и оттачивающий своё мастерство ежедневно – как правило личность гибкая.
Никто не хочет понимать как мы работаем БЕЗ препроцессора и БЕЗ пошагового дебаггера? Юзая при этом ДРУГИЕ механизмы, о которых мэйнстримщики не знают и, заметьте, знать не хотят.
Надо думать, я хотел притащить сюда своего друга-оберонщика, чтобы он помог мне пинать ногами оффтоперов и злостных мэйнстримистов. Так вот, он не очень-то сюда и стремился, он сказал, что тутошняя тусовка не доросла до понимания Оберон-технологий. Так что ему тоже никто не мешает самоутверждаться и считать себя крутым. Как и другим. :smile:
уже говорили про усложнения в виде var и begin.
О, светочь разума мэйнстримист. Тоже умный человек. Призывает нас экономить время записью:
extern unsigned char a;
extern unsigned int b;
вместо невменяемого, архаичного и слишком длинного:
VAR a*:CHAR; b*:INTEGER;
P.S. Java на ZX маразм, как и .NET на ZX.
Oleg N. Cher
13.03.2012, 01:06
Мне безразлично, как где пишется присваивание, важно чтобы были фичи и не было оверхэда. А в Обероне нет фич и есть оверхэд.
Давайте добавим в Оберон фичи и уберём оверхед.
Alone, ты занимался кроссразработкой, и знаешь, что некоторые накладные расходы на кросс всегда имеют место, как и расходы на кодинг для ZX на чём-то отличающемся от асма. Польза в том, что я придумал как их минимизировать. И мы можем сейчас заняться доводкой технологии до уровня полезных применений, или же зафукаем и забьём, оправдываясь тем, что асм всё равно круче.
Только, я считаю, нужно делать кросс-компилятор с PC напрямую в асм Спектрума (в текстовом виде). Что и начал делать. Использовать только целые типы, символы и строки.
Oleg N. Cher, давай тогда вместе работать. Нужно только выбрать, Оберон или Паскаль.
Андрей, именно для таких как ты я сподвигся на таки доводку до ума технологии, вот. С помощью Оберон-технологий думаю получить компилятор-линкер-IDE за пару дней. Так что подождите чуток. Для подогрева интересу скриншот:
http://zx.oberon2.ru/zx-dev.htm
А статья, видимо, отменяется. Практикам она ни к чему. :cool_std:
Смысл делать компилер с нуля считаю затеей полезной для саморазвития, но такого матёрого зубра как Alone ты этим не проймёшь. :wink:
Я в детстве тоже много таких компиляторов делал. А выкладывать исходники обязательно надо, не повторяй моих ошибок. Не волнуйся, не присвоят. :smile:
Как будем держать связь? Аська есть?
Andrew771
13.03.2012, 11:02
Как будем держать связь? Аська есть?
Аськи у меня нет, только М-агент. Я только в рабочее время доступен, т.к. дома невозможно ничего делать сейчас (семья не дает) :) Так что, можно в этой теме всё писать.
Смысл делать компилер с нуля считаю затеей полезной для саморазвития, но такого матёрого зубра как Alone ты этим не проймёшь.
Я свой Паскаль делаю не с нуля, а в Coco/R (спасибо ZEKу за наводку), потом компилирую в TurboPascal. Только файл atg вручную пишу. Выкладываю его, см.файл.
Моё вИдение:
Нужен или Паскаль, или Оберон, подогнанный под возможности Спектрума. Цель его создания, не удивить или переплюнуть кого-либо, а как быстрое средство разработки игр и программ (в первую очередь, игр, т.к. новый софт для Спека всё же лучше писать на Асме). Также как удобное средство разработки для тех, кто не знает или не хочет использовать Ассемблер, но хочет писать продвинутые игры.
Лучше делать кросс-компилятор с PC на Спектрум. На PC очень удобно писать в текстовых файлах и нет ограничений по памяти. Компилировать в Ассемблер в текстовый файл на PC, а не в бинарник. Чтобы пользователь мог выбрать потом любой кросс-ассемблер для Спектрума.
На первом этапе:
-----------------
Используемые типы данных:
byte
word
longint
char
string[n]
sprite - спрайтовый тип, на первом этапе только познакоместный цветной. Формат спрайтов продумать.
Массивы: одномерные и двумерные для всех типов. Размерность только до 256. Для двумерных массивов размерность первого индекса может быть только 4,8,16,32,64,128 или 256, это нужно для быстрого расчета адреса элемента массива (в ассемблере массивы всегда стараются делать с такими размерностями).
Записей нет.
Функции: +, -, *, div, mod, random(x), code, chr, readkey.
Арифметические выражения без скобок.
Операторы:
:=
write
writeln
read
readln
if ... then ... else ...
case ... of
for ... to (downto) ... do
while ... do
repeat ... until
inc
dec
clrscr
gotoxy
Специфические операторы:
colorstyle(ink,paper,bright,flash,over, inverse) - установка стиля
putsprite(?) - вывод спрайта
Процедуры: без параметров и локальных переменных
Шрифт: только 4х8 рус. и англ.
Я думаю, что подойдет любой язык, если будет оптимизатор, который многочисленными перестановками в машинном коде будет получать максимально оптимизированный алгоритм.
Я говорю о такой оптимизации, которая бы даже алгоритмы сортировки заменяла.
Руководство считает, что пока нет времени на справку.
Я что то попытался тут написать:
http://tmaplatform.ru/page/help/similarpascal/0types
http://tmaplatform.ru/page/help/similarpascal/1as
http://tmaplatform.ru/page/help/similarpascal/array
http://tmaplatform.ru/page/help/similarpascal/oledynamic
И еще там SQL-встроенный в ЯП
http://tmaplatform.ru/page/help/sql/local
Andrew771
13.03.2012, 11:40
Я думаю, что подойдет любой язык, если будет оптимизатор, который многочисленными перестановками в машинном коде будет получать максимально оптимизированный алгоритм.
Оптимизация будет за счет:
- использования в арифметических выражениях умножения и деления на кратные 2 числа (вычленения этих случаев);
- использования кратным 2 размерности массивов, для быстрого расчета адреса;
- вывод спрайта готовой встроенной процедурой;
- специфические алгоритмы: сортировка, поиск и прочее можно тоже сделать отдельными операторами со встроенными процедурами.
- после генерации текста ассемблера будут выисканы и удалены переприсвоения, лишние push/pop и т.д. Подмена алгоритмов конечно же не будет на первом этапе.
---------- Post added at 11:40 ---------- Previous post was at 11:34 ----------
Руководство считает, что пока нет времени на справку.
Я что то попытался тут написать:
http://tmaplatform.ru/page/help/similarpascal/0types
http://tmaplatform.ru/page/help/similarpascal/1as
http://tmaplatform.ru/page/help/similarpascal/array
http://tmaplatform.ru/page/help/simi...cal/oledynamic
И еще там SQL-встроенный в ЯП
http://tmaplatform.ru/page/help/sql/local
Ага, посмотрел. А можно ли байт-код оттуда как-то приспособить для генерации кода Спектрума?
Мне кажется, что все остальные разработчики компиляторов сделали всё то же самое. И еще не много больше. Поэтому не будет превосходства в скорости.
Если бы я хотел сделать, то что делаете вы, то внимательно изучал код всех спектрумовских демок. И добивался бы, что бы компилятор создавал такой же код.
---------- Post added at 10:44 ---------- Previous post was at 10:42 ----------
Ага, посмотрел. А можно ли байт-код оттуда как-то приспособить для генерации кода Спектрума?
Можно. Мой байт код почти не отличается от JVM. Только (я думаю), что не нужно. Стековая виртуальная машина, сборщик мусора и динамические строки похоронят производительность Спекки раз и навсегда.
Andrew771
13.03.2012, 11:48
Если бы я хотел сделать, то что делаете вы, то внимательно изучал код всех спектрумовских демок. И добивался бы, что бы компилятор создавал такой же код.
ну это, мне кажется, не реально. Реально подгонять возможности языка под платформу, т.е. корёжить изначальный язык под имеющиеся оптимальные приемы программирования.
Если бы я хотел сделать, то что делаете вы, то внимательно изучал код всех спектрумовских демок. И добивался бы, что бы компилятор создавал такой же код.
Что бы мы потом играли в демоверсии игр, вместо игр? :)
Oleg N. Cher
13.03.2012, 12:21
VAR
a*:CHAR;
b*:INTEGER;
записывается как
extern char a, int b;
У господина не было проблем с совместимостью знаковых и беззнаковых char? О, если нет, то Вы явно мало работали на Си. Кроме того, скажите:
extern int a, char *b, c, *d, char* e, f;
Вы сходу сообразите где что к чему относится? b и c – это оба указатели? а d – указатель или указатель на указатель? А e? А f – это char или указатель на char? Я понимаю, Вы напряжёте мозг и таки догадаетесь, но зачем. Если есть более удобная форма записи. А накапливающийся груз от перенапряжения на мозг в больших проектах ощущали?
Я здесь присутствующим собираюсь ДОКАЗЫВАТЬ, что их обвинения в моём незнании Си просто смешны. Я вынужден вести такие войны, хотя видит бог как я устаю от таких как Вы на этом и других форумах.
Я предлагаю быть творческими личностями с творческим подходом, и уважать друг друга. А здесь мы обсуждаем не победу Оберонов над мэйнстримом, а всего лишь разработку на Обероне для Спека. А Вы пришли здесь троллить, ничего не сказав по теме, и являетесь для меня и тех, кому нравятся мои посты, просто деструктивным элементом. Успокойтесь, ничто Вашему мэйнстриму не угрожает.
Кстати, Вам будет приятно узнать, что один из архитекторов платформы .NET и Visual Studio – ученик Вирта и оберонщик Клеменс Шиперски (Clemens Szyperski), один из основателей компании Oberon microsystems. Тоже кушать захотел и двигать большие дела.
http://research.microsoft.com/~cszypers/
http://www.inr.ac.ru/~info21/info/oberon_microsystems.htm
она их переросла еще в школе во время изучения Тurbo Pascal 3.
Вот Вам турбопаскаль. И вот. И ещё вот. Такое делают умные оберонщики, которым надоела искусственно раздутая сложность технологий.
http://sage.com.ua/ru.shtml?e1l9
http://sage.com.ua/ru.shtml?e1l5
http://sage.com.ua/ru.shtml?e1l6
http://sage.com.ua/ru.shtml?e1l3
http://sage.com.ua/ru.shtml?e1l8
Теперь буду рад увидеть в ответ нечто подобное, но что сделали Вы. Для Спека или нет, неважно.
Кстати, первая ссылка это Вольфейнштейн на Обероне. Alone, знаю, ты любишь такие штучки, зацени.
По поводу if(a=b): все нормальные компиляторы выдают ворнинг.
1. Не все нормальные компиляторы выдадут ворнинг. Это нормальная себе конструкция в языке Си, разрешённая. Вот в GCC ворнинги по умолчанию вообще выключены, их надо включать, например, командой -Wall
2. Если даже ворнинг и включен, то реально его просто не заметить в общей куче других ворнингов. А в среднего размера проектах их количество огромно. И исправить ворнинги полностью никто не пытается, хотя бы потому что их добрая половина – в стандартных заголовочных файлах, куда шаловливые ручонки всё же не лезут.
Я понимаю, привыкнуть можно. Вон Аллен Голуб такой талмудище “Как ходить по минному полю Си, почти ничем не рискуя” написал. Советует в целях снижения риска писать вместо:
if(a==2)
if(2==a)
Чтобы, если вдруг опечатался, компилятор уж точно это не прохавал. Ну что ж. Это хорошее чтиво вдобавок к мэйнстрим-средствам разработки. Но в Оберонах нельзя написать:
WHILE a := b …
И это правильно, господа. Так и должно быть. Поэтому байки об архаичности BEGIN и VAR будем считать оправданием своего невежества. Кстати, многие из здешних даже не знают что сделано хорошего в Обероне по сравнению с Паскалем в плане убирания лишних BEGIN. К скобкам очень привыкли, уже от чего-то другого начинает колбасить.
Я думаю, что можно. Вариантов масса.
Надо написать все возможные правила замены кода. (Большинство из них можно вычислить автоматом.) И написать функцию, оценивающую время выполнения программы.
Далее, применяем все перестановки и считаем время. Возможно алгоритм будет работать сутки, но в результате мы получим максимально рабочий код.
---
Еще есть вариант, написать функцию оценивающую идентичность алгоритмов. Например:
mov ax, data
loop:
shl ax, 1
jnz loop
(Допустим, это 4-х битный x86)
Выполняем эту программу, только в регистры записываем формулы! В которых переменные - это состояние регистров до выполнения команды.
Выполнена команда MOV
1) ax0=data0; ax1=data1; ax2=data2; ax3=data3;
Выполнена команда SHL
2) ax0=data1; ax1=data2; ax2=data3; ax3=0;
Далее идет разветвление (jnz loop). Если ноль (AX0|AX1|AX2|AX3 = 0), то повторяется второе действие. Иначе (AX0|AX1|AX2|AX3 == 1) первое. Решаем обе ветви и записываем результат: (AX0|AX1|AX2|AX3) & (вариант 1) | (!(AX0|AX1|AX2|AX3)) & (вариант 2)
3.1) Цикл закончился
ax0 = (!(data1|data2|data3|0)) & data1 = !data1 & !data2 & !data3 & data1 = 0
ax1 = (!(data1|data2|data3|0)) & data2 = !data1 & !data2 & !data3 & data2 = 0
ax2 = (!(data1|data2|data3|0)) & data3 = !data1 & !data2 & !data3 & data3 = 0
ax3 = (!(data1|data2|data3|0)) & 0 = 0
3.2) Цикл продолжился
ax0 = ((data1|data2|data3|0)) & data2 = (data1|data2|data3) & data2 = data2
ax1 = ((data1|data2|data3|0)) & data3 = (data1|data2|data3) & data3 = data3
ax2 = ((data1|data2|data3|0)) & 0 = 0
ax3 = ((data1|data2|data3|0)) & 0 = 0
3) Объединяем
ax0 = 0 | data2 = data2;
ax1 = 0 | data3 = data3;
ax2 = 0;
ax3 = 0;
4.1) Закончилась вторая итерация цикла
ax0 = (!(data2|data3|0|0)) & data2 = !data2 & !data3 & data2 = 0
ax1 = (!(data2|data3|0|0)) & data3 = !data2 & !data3 & data3 = 0
ax2 = (!(data2|data3|0|0)) & 0 = 0
ax3 = (!(data2|data3|0|0)) & 0 = 0
4.2) Цикл продолжился
ax0 = (data2|data3|0|0) & data3 = (data2 | data3) & data3 = data3
ax1 = (data2|data3|0|0) & 0 = 0
ax2 = (data2|data3|0|0) & 0 = 0
ax3 = (data2|data3|0|0) & 0 = 0
4) Объединяем
ax0 = 0 | data3 = data3;
ax1 = 0;
ax2 = 0;
ax3 = 0;
5.1) Еще одна итерация.
ax0 = (!(data3|0|0|0)) & 0 = 0
ax1 = (!(data3|0|0|0)) & 0 = 0
ax2 = (!(data3|0|0|0)) & 0 = 0
ax3 = (!(data3|0|0|0)) & 0 = 0
5.2) Цикл закончился
ax0 = (data3|0|0|0) & 0 = 0
ax1 = (data3|0|0|0) & 0 = 0
ax2 = (data3|0|0|0) & 0 = 0
ax3 = (data3|0|0|0) & 0 = 0
6) Следующую итерацию выполнять не надо. Так как условие (AX0|AX1|AX2|AX3) не выполняется. Там точно находятся нули.
Вот мы и получили формулу нашей программы AX0=0; AX1=0; AX2=0; AX3=0. Аналогичная формула будет у команды MOV AX = 0. Можно автоматом заменять.
Это простейший случай. Работу любой программы можно описать формулами c использованием всего трех действий И, ИЛИ, НЕ.
"Регистр до = Регистр после & Регистр после | !Регистр после"
А доказать равенство этих формул можно с помощью ИСЛ ИЛИ
(Формула 1) XOR (Формула 2) = 0
И самое приятное в таком подходе, что можно на выходе получить такие алгоритмы, которые в книгах не написаны. В программе вполне может появится архивация данных. Сама собой.
Единственное неудобство - этот способ очень ресурсоёмкий, поэтому целиком обработать программу не получится. (Не будет архиватора. :( ). Придется обрабатывать небольшие кусочки программ. Ну и GPU и кеширование результатов поможет. Что бы дважды не считать, что последовательность SHL + JNZ всегда дает 0.
Вы сходу сообразите где что к чему относится? b и c – это оба указатели? а d – указатель или указатель на указатель? А e? А f – это char или указатель на char? Я понимаю, Вы напряжёте мозг и таки догадаетесь, но зачем.
В мозгу программиста формируется нейронная сеть, которая парсит эти конструкции без участия интеллекта и внимания. Это как ходьба или печать на клавиатуре. Лично я не задумаюсь, как двигать пальцами и где расположены кнопки. Я думаю о слове.
Лично меня бесят указатели на функцию. Почему void*(*me)(int,int), а не void*(*)(int,int) me. Когда приходится работать с указателем функции на указатель функции, то вообще башню сносит.
Andrew771
13.03.2012, 12:47
Еще есть вариант, написать функцию оценивающую идентичность алгоритмов
Да, это уже слишком круто для нас :)
Надо написать все возможные правила замены кода. (Большинство из них можно вычислить автоматом.)
вот так и предполагается делать.
Хотите несколько слов о причинах малой популярности Оберонов? Она прямо коррелирует с огромным количеством малокомпетентных людей, которые слабо разбираются в технологиях и готовы за деньги заниматься чем угодно, и, естественно, превозносить своё болотце.
Профессора, который в одиночку или в маленьком коллективе разрабатывает операционные системы, компиляторы и бортовое п/о такие здесь светочи разума называют теоретиком, а собственное скриптописательство для 1С в рамках готовых к употреблению технологий – это непременная глубочайшая практика. Деланье ежедневных заплаток на PHP к веб-сайтам потому что кушать хоца – это высокий кодинг, почти искусство. И при этом никто далеко не против прийти сюда и рассказать, какой-де он крутой разработчик, куда-де до него тупым маразматикам без долбаггера.
И эта точка зрения муссируется в инете и имеет очень широкое хождение. И любителей самоутвердиться и попинать профессора более чем достаточно. Я же призываю не считать Вирта пустофилософствующим дураком без практики, потому что он явно опытнее и умнее скриптососов, от чего последние просто готовы рвать меня на куски. Но я иду на конфликт сознательно, не пытаясь его смягчить, ибо популяризовать идеи, лежащие в основе Оберон-технологий, невозможно на старом материале. Чтобы захотеть попробовать Оберон – нужно не испытывать к нему заочного отвращения. Чего у многих не наблюдается.
Я замечал, чем самоувереннее и безапелляционнее высказывается программист, тем чаще он бывает некомпетентен. И наоборот, программист открытый к познанию нового и оттачивающий своё мастерство ежедневно – как правило личность гибкая.
Никто не хочет понимать как мы работаем БЕЗ препроцессора и БЕЗ пошагового дебаггера? Юзая при этом ДРУГИЕ механизмы, о которых мэйнстримщики не знают и, заметьте, знать не хотят.
Надо думать, я хотел притащить сюда своего друга-оберонщика, чтобы он помог мне пинать ногами оффтоперов и злостных мэйнстримистов. Так вот, он не очень-то сюда и стремился, он сказал, что тутошняя тусовка не доросла до понимания Оберон-технологий. Так что ему тоже никто не мешает самоутверждаться и считать себя крутым. Как и другим. :smile:
вот друг твой да :) умный человек
а ты полностью соответствуешь своим описаниям
ссылка моя указывала на человека доказавшего практически, что java на спектруме возможна, да тупо и медленно, но возможна.
от тебя на просьбу показать "DASH" для спека в исходниках и обьектнике видно только скриншоты нарисованные в пейнте.
как ты можешь популяризировать чтото не показывая преимуществ?
а только разглагольствуя какие вокруг тебя собрались дартаньяны и какой ты тут красивый... виконт дебаржелон.
вот так и предполагается делать.
Я это все к тому говорю, что поставленные цели должен решать не синтаксис языка. Я то же могу приделать синтаксис Оберона к компилятору Си. Быстрее от этого компилятор не станет.
А вот могу приделать к любому компилятору функцию вывода спрайта и оптимизатор. Например к Sinclair Basic. И это даст результат. (Прикрутили уже и даёт.)
Поэтому лучше говорите - я напишу крутую библиотеку вывода спрайтов, крутой оптимизатор и синтаксис Оберона прикручу.
---------- Post added at 12:08 ---------- Previous post was at 12:06 ----------
Хорошие программисты пишут без ворнингов. 99% ворнингов - это код в хедерах, что ламерство по определению.
Все inline и template в хеадерах пишутся.
Невозможно такими же методами пиарить Оберон. Потому что от слова Java все млеют (так принято), а от слова Оберон всех заочно плющит.
Кстати, оскорблять и обвинять в некомпетентности не я первый начал. Надо начать модерацию с тех постов. Если приведёте сюда модераторов, будет только хорошо.
Да ладно? Да неужели? :)
я считал и считаю что единственный ЯВУ имеющий право жить на спеке это Spectrum Basic все остальное - баловство.
результаты выдаваемые паскалями, явами и прочими хаскеллями мягко говоря скромные.
результаты выдаваемые С чуть получше что и доказывают испанцы
Oleg N. Cher
13.03.2012, 13:11
В мозгу программиста формируется нейронная сеть, которая парсит эти конструкции без участия интеллекта и внимания.
Не, ну всё же какое-то внимание всё равно надо. К тому же чем проще будет эта сеть, тем быстрее и эффективнее будет работать мозг программиста, и тем больше свободных его ресурсов будет доступно для других проблем.
Господа, почему бы не считать виды записи с VAR и без VAR – просто равнозначными альтернативами, и хорошо, что они есть, так разнообразнее. Но не надо самоудволетворяться надругательством над конструкцией VAR. Это синтаксический сахар. А 99% времени всё равно уходит не на набирание на клавиатуре слов VAR и BEGIN, а на пошаговую (или не пошаговую) отладку и поиск багов.
Оберон хорош тем, что программу на нём поймёт любой грамотный инженер. Даже не зная ни одного ЯП. А уж если разберётся...
А ещё он идеален для обучения программированию. Как самый простой мультипарадигменный ЯВУ.
По поводу знаковых/беззнаковых типов - да, их можно объединить, но тогда нужно добавить знаковые форматы вывода, знаковые тайпкасты, операции знакового умножения, знакового деления и т.п.
Oleg N. Cher
13.03.2012, 15:10
Не нужны никакие библиотеки, всё в одном будет сразу.
Я тут не со всем идеологически согласен. Лучше ИМХО маленький язык и большие разнообразные библиотеки, чем всё упаковывать в один компилятор. Всё на все случаи жизни туда всё равно не вставишь, да и дорабатывать отдельную библиотеку проще, чем влезать в потроха компилера.
Андрей, я искал примерно того же, т.е. людей, которым понравится реализовывать обозначенные мною идеи, но как видишь, чудеса бывают редко, чтобы так уж всё излагаемое взяло и всем подряд понравилось.
Поэтому надеюсь, ты примешь тот грустный факт, что мне неинтересно создавать компилятор с нуля; вместо этого интересно работать на готовой связке, которая показывает отличную эффективность. Думаю, мало шансов переплюнуть кодогенерацию SDCC даже приблизительно. Но тебе хочу пожелать успехов. А если соберёшься адаптировать библиотеки (или разрабатывать новые) для своего компилятора Паскаля, тут у нас может появиться интерес для совместной деятельности.
Andrew771
13.03.2012, 16:18
Андрей, я искал примерно того же, т.е. людей, которым понравится реализовывать обозначенные мною идеи, но как видишь, чудеса бывают редко, чтобы так уж всё излагаемое взяло и всем подряд понравилось.
Поэтому надеюсь, ты примешь тот грустный факт, что мне неинтересно создавать компилятор с нуля; вместо этого интересно работать на готовой связке, которая показывает отличную эффективность. Думаю, мало шансов переплюнуть кодогенерацию SDCC даже приблизительно. Но тебе хочу пожелать успехов. А если соберёшься адаптировать библиотеки (или разрабатывать новые) для своего компилятора Паскаля, тут у нас может появиться интерес для совместной деятельности.
Я думал, ты хочешь забабахать новый компилятор. Ессно, не как Вирт - Оберон на Обероне, а пользуясь уже имеющимися инструментами (в моем случае Coco/R). Там только написать сам текстовый файл atg с элементами языка и соответствующими им образцами кода, а парсер и прочая мутотень уже есть.
Ну а ежели ты хочешь идти через связку с SDCC, то тоже можно. Главное, чтобы исходник на Обероне компилировался просто в код Z80, файлом bat например, без всяких подкручиваний, перекопирований и шаманств. Иначе им никто пользоваться не будет. Только одному самому пригодится.
Oleg N. Cher, покажи здесь уже свой "Dash" чтобы доказать эффективность
Oleg N. Cher
13.03.2012, 18:43
Главное, чтобы исходник на Обероне компилировался просто в код Z80, файлом bat например, без всяких подкручиваний, перекопирований и шаманств. Иначе им никто пользоваться не будет. Только одному самому пригодится.
Так и задумано. Ты скрин на http://zx.oberon2.ru/zx-dev.htm уже посмотрел? Трудность вижу если ошибки полезут не с уровня Оберона, а с уровня Си, вот например jerri сказал что Си не знает.
Я очень скоро выложу все свои наработки по данному проекту, Андрей. И буду отвечать на разные вопросы и всех учить рисовать скриншоты Даша в Пэйнте.
P.S. Господа. По задумке форум создавался не для оскорбления друг друга, а для обсуждения разных тем, связанных с ZX. Не нравится тема – создай другую, а не приходи в эту флудить, качать права и учить всех какой ты умный. Поэтому если Raider намерен аппелировать к форумчанам насчёт своих обид, то вспомним, что именно я создал интересную для многих тему, а кто-то другой пришёл и сюда насрал, изгадив моё детище и утопив его в своих пиписьках. И теперь меня обвиняют в подделке скриншотов и пугают модерацией и баном? Это смешно, господа. Модерацию надо было делать вовремя.
Опять же, если бы овнер форума не боялся захвата власти, или там чего он боится, то раздал бы вменяемым людям модераторские права, и этого хая не случилось бы в принципе. Значит, Raider, ищите причину своих обид не во мне и моих высказываниях. Я не красна девица, чтобы всех удовлетворять. А в политике своего форума, которая не защитила меня, пользователя, стремящегося сделать и сказать что-то полезное о ZX, и не оградила от тупых зложелателей. Если в глазах ZEK’а пришёл злой оберонщик и всех обосрал, то в моих глазах пришли злые мэйнстримисты и принялись просто смешивать мои разработки и меня самого с *****м, на что я не согласился и принялся аргументированно доказывать свою точку зрения, а поскольку в ответ на удары ногами по голове вежливо улыбаться как-то не принято, то мне пришлось применить сложившийся здесь на форуме стиль общения.
Фух ... Выдержал испытание "чтением" ... Специально решил прочитать все посты ...
Олег, совершенно не важно нужен ли ОБЕРОН большинству. Однако важно нужен ли он хотя бы одному человеку. А такие уже есть. Поэтому я желаю Вам доделать ОБЕРОН.
Только, думаю, что сравнивать Oberon с другими языками просто бесполезно. Это всё равно, что придти к японцу и сказать, что его язык устарел, и пора говорить на прогрессивном английском, ну или наоборот. Лично мне совершенно всё равно на каком языке писать, мне важен результат. И практика показывает, что наилучший результат, например: из трёх языков "Pascal", "Oberon" или "Си", даёт только "Assembler".
Давайте посмотрим в корень проблемы, что надо от языка:
1. Скорость исполнения
2. Компактность
Остальные характеристики всегда будут второстепенными. Переносимость кода, как по-мне, не должна входить в список характеристик вообще, поскольку этот пункт всегда вытеснят первый пункт, и тянет за собой кучу недостатков. Например, я вот только что придумал самый переносимый язык под названием "XorAndOr", назовём его ещё более красиво "XAO" ... Во как звучит ... На трёх операциях Xor, And и Or можно сделать вообще всё. А переносимость, ну просто идеальна ... Но выгоден этот язык будет только на матрицах. Поэтому, чего не добавляй в язык, - всегда будет хуже Assembler'а.
А из этого вывод, что на Speccy с его скоростью и памятью языки высокого уровня будут всегда выглядеть убого, с точки зрения кода. Когда пишешь код на асме мозг работает иначе, и рождаются совсем другие идеи, которые просто пестрят особенностями.
Например: у "Flash Inc." в плеере под Covox есть место микширования трёх каналов в один тремя командами асма, то есть "(a+b+c)/3", это ведь родилось именно потому, что мозг программиста просто жил в Z80.
Или например: "IF A>7 THEN DEC(A)" ни один компилятор не превратит в "SUB 8: ADC A,7"
Получается, что пункт номер "1", осилить практически невозможно.
В итоге остался только один пункт номер "2". То есть единственное, что оправдано, это компактность кода. Собственно я вижу применение любого языка на любых платформах, лишь в виде математики и кранчера данных, ну можно ещё отдать ему рисование каких-нибудь текстов. Однако этот инструмент уже есть и называется BASIC. Вот тут-то и главное !!! Бейсик уже лежит в ROM'е, и если бы Oberon дал бы мне возможность написать набор функций для расчётов чего-нибудь используя при это "ваську", что займёт минимум памяти, и я мог бы этот код таскать по памяти, вызывая его из нужного мне места в Assembler'е, то тогда бы это был оправданны язык.
Но мне кажется, что в итоге этот язык как и паскали, си, бейсики, фортраны будут только называться языком для серьёзных задач. Поскольку умножение это не серьёзная задача, и рисование линии это не серьёзная задача, и рисование полигона это так же не серьёзная задача. А вот если это будет работать невероятно быстро, если это будет заставлять смотрящего произносить фразу "как это оно на трёх-то мегагерцах работает-то ?", то это уже серьёзная задача.
Oleg N. Cher
13.03.2012, 20:38
Олег, совершенно не важно нужен ли ОБЕРОН большинству. Однако важно нужен ли он хотя бы одному человеку. А такие уже есть. Поэтому я желаю Вам доделать ОБЕРОН.
Спасибо, Robus! За терпение и добрые слова. :v2_dizzy_heart: Думаете я хотел уздреть здесь зека? Да нет вовсе! Я хотел уздреть Вас, Rasmer'а, CopperFeet'а, Кладова. Потому что я уважаю этих людей за Спектрум-деятельность и интересные посты. Кстати, здорово что пришли, располагайтесь.
Я почти доделал технологию, которую опубликую если не сегодня, так завтра. Насчёт варки в асме – полностью согласен, это обучение мастерству полным погружением. Я не собираюсь потеснять асм для Z80 Оберон-кодингом. Смысл – сделать программирование для Спектрума более удобным для новичков, дав им быстрый старт в язык, прививающий хороший стиль мышления. Ещё смысл – получить хороший удобный структурно-модульный клей для асм-подпрограмм. А вот последние-то и надо делать сверхоптимальными и хай-кастомизабельными, чтобы не включать в целевую программу неиспользуемые участки кода. Это возможно.
Так что вижу нишу для кроссразработки на Обероне для Спека. А ещё Оберон может помочь использовать хорошие Спектрум-наработки на других платформах. И вести одномоментную разработку одной программы на одном языке для Спека и, например, для Win32/Linux. Это тоже возможно. Заявляю как оберонщик и спектрумист.
Oleg N. Cher
13.03.2012, 23:11
Я знаю реакцию на слово 'Оберон'. Мне 15 лет назад подарили диск "Всё для программиста", на котором были компиляторы Modula-2 и Oberon-M. Меня тогда Модула заинтересовала больше, забавная была штучка. На Оберон только посмотрел. А активно работал на TurboBasic, MS-QuickC, TurboC++ и TurboPascal. Мой путь к Оберон-технологиям был долог, и я это пытаюсь донести вам. А Диму оцениваю как человека, находящегося где-то в начале знакомства с Оберонами. Буду огорчён если я стану причиной его дальнейшей нелюбви к ним.
У ZX-Basic масса достоинств, главное из которых – его наличие в ПЗУ. И я одобряю его использование для разработки на самом Спектруме. При кросс же разработке на первый план выходит наглядность программы и беглое её понимание.
Oleg N. Cher
14.03.2012, 18:21
Начинает казаться, что автор какую-то другую идею преследует. Очтается ждать, когда популяризатор идеи начнет популяризировать идеи.
пощупать сразу хоть какой-то результат, почитать код, поменять его и побаловаться, оценить скорость и объем занятой памяти на строку кода. Да и готовый шаблон для создания чего-то своего. Для хобби теория скучна. Кнопки нажимать хочется. Глядишь, и вопросы с критикой из абстрактной плоскости перерастут в практическую.
Тока, если можно - пример чуть посложнее, чем Hello, world. И инструкцию в расчете не на гениев, которые из всех технологий только про Оберон не знают, а для простых смертных, которые для Спеки писали только на asm и Basic. Для всех, то бишь. Вот это дело будет!
Да, с примером облом. :wink: Но надеюсь, сами напишете. :v2_dizzy_king:
Много философии, мало практики.
Вот скажите, Олег, а правда программировать на Обероне для Спектрума настролько сложно, что нет никакой возможности положить здесь, на форуме, несколько ссылок на инструменты и написать простой пример и краткую инструкцию, после выполнения которой что-то заработает?
Алекс, давайте Вы сами нам скажете насколько сложно программировать для Спектрума на Обероне. После того, как попробуете. Это будет чистая практика.
Читайте ветку http://zx.pk.ru/showthread.php?t=18387
Oleg N. Cher
14.03.2012, 23:12
Ругать Оберон с позиции многолетнего на нём ОПЫТА РАЗРАБОТКИ из всех писавших в эту ветку ОБОСНОВАННО могу только я, но, как вы все заметили, не спешу этого делать. Только по одной простой причине: Оберон-технологии ОЧЕНЬ ГИБКИЕ и МОЩНЫЕ. И поддаются лёгкой и быстрой (и надёжной) доработке в любом необходимом направлении. Как доказательство, показываю вам среду разработки НА ПЯТИ ЯЗЫКАХ программирования (Оберон, Оберон-2, Си, Си++, ассемблер процессора Z80) для ZX, которую я сделал на базе Оберон-среды BlackBox и компилятора SDCC за 2 дня. И это, несмотря на молодость проекта, вероятно, УЖЕ самый мощный и удобный инструмент из известных мне ПО ПРОСТОТЕ и ПОТЕНЦИАЛУ для развития (а также по качеству кодогенерации) для высокоуровневой разработки для Спектрума, и в т.ч. для новичков. А уж если его развить. Есть идеи как ЛЕГКО И БЫСТРО (за пару дней бы справился) добавить поддержку языков Паскаль и Модула-2. Да, нету дебаггера и пока нету подсветки синтаксиса. Последнее обещаю сделать. Не для зека, он слов не понимает. Для Alone, Raydac и других собратьев. Теперь пусть все сишники на свете возьмут сто библиотек и попробуют повторить данный проект в данный срок. И я делал это не за деньги, а за совесть, как энтузиаст. В ответ ожидаю доброе слово и немного благодарности. Вопросов по теме и предложений по усовершенствованию.
В Оберонах действительно есть к чему приложить руку. Здесь ещё не сказано последнее слово, есть много открытых направлений работы, например, я сделал биндинги библиотеки SDL для КП https://sourceforge.net/projects/sdl-for-oberon/, начал портировать на КП библиотеку KOL http://forum.oberoncore.ru/viewtopic.php?f=47&t=2829 (кстати, на базе этой библиотеки сделан эмулятор Спектрума EmuZWin), участвую в развитии GUI-библиотеки OVCL http://zx.oberon2.ru/ovcl.htm для компилятора OPCL, участвую в команде по развитию компилятора OPCL https://sourceforge.net/projects/opcl. Всё на некоммерческих началах, на правах энтузиаста.
Error404
16.03.2012, 12:48
А вообще, препроцессор С в руках программеров-извращенцев это страшное зло. Например, я весь исплевался портируя uIP оттого, что автор науевертил там такого на макросах, что многие компилеры распутать не могут (не говоря уже о понимании всего этого людями), и соответственно либо не собирают либо собирают абы что, от чего при отладке приходишь в совершенное изумление.
Друзья мои!
Большая просьба!
Если вы не хотите использовать оберон и любые его проявления в своём будущем, то не пишите в этой теме вообще. Не оставляйте глупых постов, которые я устаю удалять, пожалейте своё и, если вам не жаль своего, то, хотя бы, моё время.
Если же у вас есть личные мотивы по отношению к автору - решите этот (или эти) вопрос(-ы) в личке, в аське или каким-либо другим способом, благо его контакты (автора темы) совсем не спрятаны.
2 камрад Sayman> мне пришлось почти все твои сообщения в этой теме удалить по причине их несвязанности с тематикой форума или переходом на личности. Прочитай, пожалуйста, моё обращение к форумчанам и к тебе лично, находящееся в начале этого сообщения.
2 камрад Zek> просьба лучше фильтровать сообщения. Если чувствуешь, что излишне завёлся - дай себе маленькую паузу, может день, может неделю, отдохни. Не вынуждай применять модераторские методы.
2 камрад Oleg N. Cher> как модератор обещаю поддержку (в виде очистки от хлама) твоей темы, но требую от тебя делать максимально политкорректные определения и высказывания. Очень уж часто они у тебя на грани перехода на личности, да и сам провоцируешь переходы в оффтоп.
Oleg N. Cher
17.03.2012, 13:24
Первое, что радует в Обероне (после работы на Паскале), – это сокращённая форма записи составных операторов, а если проще, то было (Pascal):
BEGIN Op1; Op2 END;
Стало (Oberon):
Op1; Op2 END;
Слово BEGIN мы пишем только в двух случаях:
a) В самом начале каждой процедуры после объявлений констант, типов и переменных. Таким образом, BEGIN отделяет друг от друга объявление новых сущностей (декларатив) и исполняемую часть (императив) внутри процедуры;
b) В секции инициализации модуля, после всех процедур, (перед END Module). Этот код инициализирует модуль неявным вызовом, чтобы подготовить его к работе. Своеобразный “конструктор” (в терминах ООП) модуля. В язык КП добавлены ещё и “деструкторы” – секция деинициализации модуля CLOSE.
Это очень удобно.
В связи с этим вопрос. Вы бы предпочли в модулях Basic и Laser неявную инициализацию? Т.е. чтобы не надо было писать B.Init и L.Init, ограничась B.Quit? Это возможно. Надо устроить опрос наверное. Кстати, имена процедур в модуле Basic обсуждаемы, давайте предложения. Ну и кое-что наверное здесь надо добавить, не все операторы ZX-Basic реализованы. Если напишете что-нить полезненькое, присылайте.
Второе полезное отличие от Паскаля – в Обероне появилась форма “вечного” цикла LOOP END.
Т.е. не нужно писать WHILE TRUE или UNTIL FALSE. Пишем LOOP END. Из цикла LOOP можно выйти по EXIT, также ессно можно выйти изнутри цикла LOOP по RETURN (возврат целиком из процедуры).
---------- Post added at 10:57 ---------- Previous post was at 10:34 ----------
В языках Си и Паскаль интерфейсные части (*.h и секция interface), скажем так, модулей формируются ручной работой, чреватой потерей времени на правки рассинхронизаций интерфейсной и реализующей части (особенно в Си). В Delphi объявления сущностей, видимых извне (экспортированных), в секциях interface и implementation дублируются. В Обероне все экспортируемые сущности помечаются звёздочкой * или минусом –. Минус обозначает экспорт только для чтения, что убирает риск нежелательного изменения переменной извне, например.
VAR
a, b, c: INTEGER; (* Это внутренние переменные модуля, извне не видны *)
d-, e-: INTEGER; (* Эти переменные доступны извне только для чтения *)
f*, g*, h*: INTEGER; (* А эти доступны извне как для чтения, так и для записи *)
Предлагаю убедиться как легко сгенерировать интерфейсную часть (а часто для пользования функционалом модуля это единственное, что нужно знать; все механизмы реализации скрыты от конечного пользователя интерфейсом – инкапсуляция). Откройте:
File -> Open -> ZXDev/Mod/Basic.odc
Нажмите F12 (скомпилируем наш модуль подсистемой Dev, таким образом создастся символьный файл – сгенерированный интерфейс экспортов модуля). Дважды щёлкните на слове Basic и нажмите Ctrl+D. Откроется что-то такое:
DEFINITION Basic;
CONST
Black = 0;
Blue = 1;
Brown = 6;
Cyan = 5;
Green = 4;
LightBlue = 1;
LightCyan = 5;
LightGray = 7;
LightGreen = 4;
LightMagenta = 3;
LightRed = 2;
Magenta = 3;
Off = 0;
On = 1;
Red = 2;
White = 7;
Yellow = 6;
PROCEDURE AT (y, x: Coords);
PROCEDURE ATTR (y, x: Coords): BYTE;
PROCEDURE BEEP (ms: CARDINAL; freq: INTEGER);
PROCEDURE BORDER (color: Color);
PROCEDURE BRIGHT (mode: Mode);
PROCEDURE CIRCLE (cx, cy, radius: Coords);
PROCEDURE CLS;
PROCEDURE DRAW (x, y: Coords);
PROCEDURE FLASH (mode: Mode);
PROCEDURE FONT (addr: ADDRESS);
PROCEDURE INK (color: Color);
PROCEDURE INVERSE (mode: Mode);
PROCEDURE Init;
PROCEDURE KeyPressed (): BOOLEAN;
PROCEDURE OVER (mode: Mode);
PROCEDURE PAPER (color: Color);
PROCEDURE PAUSE (ticks: CARDINAL);
PROCEDURE PEEK (addr: ADDRESS): BYTE;
PROCEDURE PLOT (x, y: Coords);
PROCEDURE POINT (x, y: Coords): BYTE;
PROCEDURE POKE (addr: ADDRESS; value: BYTE);
PROCEDURE PORTIN (port: ADDRESS): BYTE;
PROCEDURE PORTOUT (port: ADDRESS; value: BYTE);
PROCEDURE PRCHAR (ch: CHAR);
PROCEDURE PRINT (i: INTEGER);
PROCEDURE PRSTR (str: ARRAY OF CHAR);
PROCEDURE PRWORD (i: CARDINAL);
PROCEDURE Quit;
PROCEDURE RANDOMIZE (seed: CARDINAL);
PROCEDURE RND (min, max: CARDINAL): CARDINAL;
PROCEDURE SGN (x: INTEGER): INTEGER;
PROCEDURE SlowCircle (cx, cy, radius: Coords);
END Basic.
---------- Post added at 11:24 ---------- Previous post was at 10:57 ----------
Точно также поступаем и с Laser. Так можно и параметры процедур быстро посмотреть, и типы, и константы с переменными. Всё ж не упомнишь.
DEFINITION Laser;
PROCEDURE ASLV (col, row, len, hgt: BYTE);
PROCEDURE ASRV (col, row, len, hgt: BYTE);
PROCEDURE ATDV (col, row, len, hgt: BYTE);
PROCEDURE ATOF;
PROCEDURE ATON;
PROCEDURE ATUV (col, row, len, hgt: BYTE);
PROCEDURE AWLV (col, row, len, hgt: BYTE);
PROCEDURE AWRV (col, row, len, hgt: BYTE);
PROCEDURE CLSM (spN: BYTE);
PROCEDURE CLSV (col, row, len, hgt: BYTE);
PROCEDURE GMAT (col, row, spD, spS: BYTE);
PROCEDURE GMBL (col, row, spD, spS: BYTE);
PROCEDURE GMND (col, row, spD, spS: BYTE);
PROCEDURE GMOR (col, row, spD, spS: BYTE);
PROCEDURE GMXR (col, row, spD, spS: BYTE);
PROCEDURE GTBL (col, row, spN: BYTE);
PROCEDURE GTND (col, row, spN: BYTE);
PROCEDURE GTOR (col, row, spN: BYTE);
PROCEDURE GTXR (col, row, spN: BYTE);
PROCEDURE INVM (spN: BYTE);
PROCEDURE INVV (col, row, len, hgt: BYTE);
PROCEDURE Init;
PROCEDURE MARV (col, row, len, hgt: BYTE);
PROCEDURE MIRV (col, row, len, hgt: BYTE);
PROCEDURE PMAT (col, row, spD, spS: BYTE);
PROCEDURE PMBL (col, row, spD, spS: BYTE);
PROCEDURE PMND (col, row, spD, spS: BYTE);
PROCEDURE PMOR (col, row, spD, spS: BYTE);
PROCEDURE PMXR (col, row, spD, spS: BYTE);
PROCEDURE PTBL (col, row, spN: BYTE);
PROCEDURE PTND (col, row, spN: BYTE);
PROCEDURE PTOR (col, row, spN: BYTE);
PROCEDURE PTXR (col, row, spN: BYTE);
PROCEDURE PWBL (col, row, spN, spCol, spRow, len, hgt: BYTE);
PROCEDURE PWND (col, row, spN, spCol, spRow, len, hgt: BYTE);
PROCEDURE PWOR (col, row, spN, spCol, spRow, len, hgt: BYTE);
PROCEDURE PWXR (col, row, spN, spCol, spRow, len, hgt: BYTE);
PROCEDURE SCRM (spN, npx: BYTE);
PROCEDURE SCRV (col, row, len, hgt, npx: BYTE);
PROCEDURE SETV (col, row, len, hgt: BYTE);
PROCEDURE SL1M (spN: BYTE);
PROCEDURE SL1V (col, row, len, hgt: BYTE);
PROCEDURE SL4M (spN: BYTE);
PROCEDURE SL4V (col, row, len, hgt: BYTE);
PROCEDURE SL8M (spN: BYTE);
PROCEDURE SL8V (col, row, len, hgt: BYTE);
PROCEDURE SR1M (spN: BYTE);
PROCEDURE SR1V (col, row, len, hgt: BYTE);
PROCEDURE SR4M (spN: BYTE);
PROCEDURE SR4V (col, row, len, hgt: BYTE);
PROCEDURE SR8M (spN: BYTE);
PROCEDURE SR8V (col, row, len, hgt: BYTE);
PROCEDURE WCRM (spN, npx: BYTE);
PROCEDURE WCRV (col, row, len, hgt, npx: BYTE);
PROCEDURE WL1M (spN: BYTE);
PROCEDURE WL1V (col, row, len, hgt: BYTE);
PROCEDURE WL4M (spN: BYTE);
PROCEDURE WL4V (col, row, len, hgt: BYTE);
PROCEDURE WL8M (spN: BYTE);
PROCEDURE WL8V (col, row, len, hgt: BYTE);
PROCEDURE WR1M (spN: BYTE);
PROCEDURE WR1V (col, row, len, hgt: BYTE);
PROCEDURE WR4M (spN: BYTE);
PROCEDURE WR4V (col, row, len, hgt: BYTE);
PROCEDURE WR8M (spN: BYTE);
PROCEDURE WR8V (col, row, len, hgt: BYTE);
END Laser.
Странно, что буквы на часто используемых словах END, VAR, PROCEDURE не экономят. А для ключевых слов PUBLIC, PRIVATE использовали символы.
Кстати autoheader-ов для Си очень много.
Oleg N. Cher
25.03.2012, 14:42
Господа, всем, кто хочет помочь проекту ZXDev. Пока что ко мне обратился только один человек, так мы далеко не уедем. Предлагаю всем подумать, нужна ли нам такая среда разработки для ZX. Всем, кому не нравится Оберон, но кто приемлет высокоуровневую разработку для Спека на других языках: Си и Си++ в ZXDev никто не отменял. Можно даже часть кода разработать на Си, часть на Си++ и часть на Обероне-2. Это не считая асма. Всем, кто не приемлет высокоуровневую разработку. Я знаю как убрать оверхед ZXDev (вернее, SDCC). Оверхед там оттого, что нету динамической линковки. Из библиотеки просто берутся все процедуры, даже неиспользуемые. Это можно пофиксить: a) криво, но самим – включать только используемые процедуры в библиотеку (с помощью ифдефов и конфигуратора); b) протолкнуть в SDCC идею смартлинковки. Или реализовать её самостоятельно.
Категорически не одобряю создание своих сборок SDCC. Это распыление сил, потому что автор забивает обычно на такую сборку, и все нововведения SDCC в неё уже перестают входить. Ну а поскольку такая сборка уже теряет мэйнтейнера, ею пользуются по инерции, и тоже рано или поздно забивают. Все усовершенствования надо проталкивать туда. Согласен, сложновато. Но так правильнее.
Я тут уже несколько раз оправдывал появление связки Oberon-2 -> Ofront -> SDCC -> машкод. Много говорилось только о недостатках такого решения. Но у него есть и достоинства. Например, на базе кодогенерации SDCC можно прикрутить другие языки. Я вижу потенциально хорошую интеграцию в среду ZXDev языков Basic (Pure Basic, Free Basic) и Паскаль/Модула-2. Всё это можно реализовать быстро через трансляцию в Си. Согласитесь, с имеющимися силами нам кодогенератор Z80 не осилить. Си может стать промежуточным мостиком, у которого есть самое важное достоинство: лучший в мире кодогенератор, притом готовый, а не в голове. Поэтому предлагаю заинтересованным людям присоединиться к проекту ZXDev, действуя в рамках своих целей, интересов, проектов и своей внутренней мотивации. Как видите, я не собираюсь от вас зажиливать исходники ZXDev или что-либо другое. Всё будет совершенно доступно для всех в равной мере. Давайте на практике реализуем схему Линуса Торвальдса "С миру по нитке, и Linux готов", описанную в книге "Just for Fun". Ведь проекты такого масштаба могут делаться только большими коллективами. Подумайте, как можно сделать ZXDev полезным и для Ваших идей. Я по-моему достаточно открыт для идей со стороны, просто скучно и долго всё делать одному. Или может подскажете, где искать помощников, если не здесь?
Странно, что буквы на часто используемых словах END, VAR, PROCEDURE не экономят.
Что такое синтаксический сахар знаете? Или, по-Вашему, там следовало быть ND, VR и PRC?
vinxru, объективности ради согласитесь со мной, что корректнее сравнивать между собой количество букафок не между void и PROCEDURE, а между extern void / static void и PROCEDURE (а это далеко не редкость, а вовсе даже типично; я бы даже назвал очень разумным решением не светить наружу локальные объекты). К тому же, зацените, в Обероне вообще не нужны извращения типа:
#ifdef BUILD_DLL #define _DLL_ENTRY extern __declspec(dllexport) #else #define _DLL_ENTRY extern __declspec(dllimport) ... #endif
Чтобы сгенерировать DLL в BlackBox даже не надо изменять текст модуля. Достаточно использовать коммандер, который слинкует Оберон-модуль в готовую DLL. Быстро и без вопросов. Дополнительные вещи (настройки, опции, ключи) упрятаны глубже, но для профессионалов всё доступно.
Так что считаю сравнение между void и PROCEDURE несколько предвзятым и некорректным. В Си короче void, в Обероне же опускается static и экспорт пишется короче: все объекты для экспорта просто помечаются звёздочкой (после имени) для полного доступа или знаком минус для read only. А вот тут я наеду на всех сишников, что в их любимом Си экспорта только для чтения вообще не предусмотрено. А ведь это очень важно для построения надёжных программ.
---------- Post added at 13:42 ---------- Previous post was at 13:19 ----------
Oleg N. Cher, покажи здесь уже свой "Dash" чтобы доказать эффективность
от тебя на просьбу показать "DASH" для спека в исходниках и обьектнике видно только скриншоты нарисованные в пейнте.
Поскольку jerri не убрал свои данные высказывания, то сообщаю, что товарищ jerri не заметил давно ещё неделек 2-3 назад выложенный снап Даша, но негатив свой высказать поторопился. Ну разве ж я в этом виноват.
Oleg N. Cher, не будь снобом :) я не сижу на твоем сайте с нетерпением ожидая когда ты на нем что-нибудь выложишь.
Для информирования заинтересованных существует лента новостей.
Негатив я высказываю когда получаю ответы на вопросы которых не задавал.
Практику правки старых постов считаю порочной
качество и размер сделанного с помощью sdcc оценил и мне оно в целом не нравится. после оценки готового продукта мое присутствие здесь больше не требуется и отвечаю я тебе только если ты меня призываешь.
Oleg N. Cher
25.03.2012, 16:04
Нужен или Паскаль, или Оберон, подогнанный под возможности Спектрума. Цель его создания, не удивить или переплюнуть кого-либо, а как быстрое средство разработки игр и программ (в первую очередь, игр, т.к. новый софт для Спека всё же лучше писать на Асме). Также как удобное средство разработки для тех, кто не знает или не хочет использовать Ассемблер, но хочет писать продвинутые игры.
Отлично. Только видишь, все начитались книжек о неимоверной крутости языков Си, Си# и Java, поэтому даже разговор об их недостатках или отсутствии чего-либо в них считается кощунственным, а многих теперь даже от самого слова "Паскаль" воротит. Попробуй тут всех заставь уважать достоинства Паскаля. :wink: Да, вопрос серьёзный, что и как назвать. Может даже имя Оберон и не самое удачное в плане маркетинга.
Лучше делать кросс-компилятор с PC на Спектрум. На PC очень удобно писать в текстовых файлах и нет ограничений по памяти. Компилировать в Ассемблер в текстовый файл на PC, а не в бинарник. Чтобы пользователь мог выбрать потом любой кросс-ассемблер для Спектрума.
С первым трудно не согласиться, а вот со вторым можно поспорить. Да и входные форматы разных кроссассемблеров весьма различаются.
Ты конечно знаешь, что в хорошем компиляторе фронт и бэк-энды – достаточно изолированные друг от друга части, что даёт много дополнительных ценных возможностей, например, кроссъязыковую поддержку или кроссплатформенную (генерация кода для разных процессоров). Ты освоил COCO/R, и это очень хороший шаг. Одобряю. Кстати, Пол Рид (Paul Reed) из Padded Cell Software Ltd выслал мне свой доклад "Building Your Own Tools - An Oberon Industrial Case-Study" (в котором он, в частности, делится опытом разработки на Обероне веб-сервисов и сайтов), там у него указано, что у Вирта количество вызовов для генерации бэк-энда Оберона составляет 14 штук.
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 MonOp BinOp Branch Jump Trap Case PrepCall Call Enter Return
The procedures usually take as parameters one or more variables of type Item, a data structure (described in Project Oberon and Compiler Construction) containing information used by the code generator to select addressing modes and sizes of operands.
Мне очень хотелось бы перевести весь доклад на русский и опубликовать, но Пол Рид запретил мне это делать, потому что у него контракт с издательством.
Так мы с тобой подходим к идее не только общего фронта на основе COCO/R, но и общего бэка, а тут появляются интересные возможности, например, ты можешь создать, наряду с бэком под проц Z80 и Спектрум, бэк, который будет генерировать текст программ на Си. Мы получим от этого массу преимуществ:
a) возможность через такую трансляцию в Си генерировать более качественный код, используя кодогенератор SDCC. А он уже готовый и отлично работает. Допускаю, можно использовать его для окончательной сборки продукта, а для промежуточной, с отладкой, можно использовать менее эффективную, но зато более надёжную и быструю свою реализацию нативной кодогенерации;
b) возможность смешивать при разработке разные языки. Как видишь, даже здесь в этой ветке есть много противников Оберона (и Паскаля), но любителей Бейсика и Си. Опыт подсказывает, что всех этих людей за раз одним махом не преубедишь, им надо постепенно показывать шаг за шагом достоинства Оберона (или Паскаля) на практике;
c) наконец, ты создашь таким образом очень ценный продукт уже не уровня игрушечного Спектрума, а вполне себе промышленного значения, к которому можно будет прикрутить разные языки и платформы, сначала через Си (на правах макета, но эффективно работающего), потом и нативно.
Вот так мне видится этот шаг.
sprite - спрайтовый тип, на первом этапе только познакоместный цветной. Формат спрайтов продумать.
Это только в библиотеку. Надо думать, мы делаем не продукт-однодневку, а что-то более серьёзное, а форматы спрайтов вещь спорная, у каждого из них есть достоинства и недостатки. Вшивать что-то в компилер смысла мало, как и держать всё-всё в одном бинарнике.
Функции: +, -, *, div, mod, random(x), code, chr, readkey.
Реализации random и readkey тоже могут быть самыми разными, не надо думать, что всем подойдёт одно и то же.
write
writeln
read
readln
А вывод делать планируется шрифтом какого размера? (шучу). Конечно, это всё тоже надо вынести в библиотеку. Ну, или по крайней мере в библиотеку SYSTEM, которая будет импортироваться неявно (в Паскаль-реализациях так часто сделано), но лучше если с внешним конфигуратором, в котором можно будет выбрать шрифт по умолчанию, например, или способ вывода литер (ПЗУ или прямо в видеопамять). Почему надо сделать именно так? А чтобы не плодить массу функций-переключателей, которые всё равно не будут кроссплатформенными, по определению. Я продумал эти вещи очень глубоко, и есть способ такое делать всё просто и кроссплатформенно, если интересуешься, расскажу более подробно, а лучше покажу (в ZXDev), со временем.
Если захочешь заняться реализацией поддержки Паскаля внутри Оберон-среды ZXDev, буду рад, и постараюсь оказывать посильную помощь в развитии продукта. Начать советую с поиска какого-либо исходника pas2c или же просто продумать бэк-энд в Си на основе COCO/R.
А уж если к нам присоединятся newart и jerri, раз им так нравится Pure Basic, то можно и его поддержку встроить в среду. Особенно если в нём есть хоть какое-то подобие модульности. Получится средство разработки на СЕМИ языках программирования для Спектрума. А если уж потом добавить Модулу-2! Да мы вообще по крутости всех за пояс заткнём. :)
Если тебе по каким-то причинам не нравится предлагаемая идеология, то давай соприкоснёмся на общей почве разработки библиотек. Прав был Robus: надо искать точки соприкосновения, а не отторжения. Кстати, Robus говорил о выработке сверхчутья при глубоком погружении в программирование на асме, это чистая правда. Так вот, при глубоком погружении в Оберон-технологии возникает такое же чутьё, но не в плане низкоуровневого кодинга, а междуплатформенного и междуязыкового (и даже междуконструкционного в языках) взаимодействия.
Оберон на удивление чётко расставляет всё в голове по местам. Что является важным, а что второстепенным. Инлайн процедура или нет, вызывается она из DLL или влинкована в EXE, модель её вызова со способом передачи параметров – это вещи второстепенные, и обычно от прикладного программиста на Обероне они скрыты в системных модулях. Давайте признаем, что инлайнить процедуру или нет, даст ли это выигрыш – в этом может разобраться умный компилятор. А вот волен ли модуль B менять переменную модуля A, доступна она извне или нет, сколько и каких параметров передать в процедуру – это вещи для программиста важные. Оберон прячет несущественное, позволяя сосредоточиться на важном. В некоторых вещах он абсолютный лидер, а я повидал технологий немало. Ну например. Чтобы превратить сишный "модуль" в библиотеку DLL – надо как следует знать модели вызова и много очень низкоуровневой лабуды: ключей линкера и прочего. В системе BlackBox почти любой модуль – хороший кандидат на DLL, этим занимается только линкер, поэтому программисту, оформившему процедуру, глубоко пофиг откуда она будет вызвана: из родного модуля Оберон-системы, в виде апплета, пришедшего по сети, импортирована ли она из DLL/SO, и так далее. Пофиг, инлайнирована она или же нет – пусть решает компилятор. Это в первую очередь процедура.
Хочу сказать Alex Raider. Не серчайте, я ведь называл писавших в эту ветку некомпетентными не вообще, а только в Оберон-технологиях. Это парадокс Оберона – все о нём всё знают и торопятся высказать своё мнение, но всё получается разное. Негатива заочного много. Глубже изучать вопрос надо, уважаемые. Не пожалеете. Я ни секунды не жалею о времени, потраченного на изучение Оберон-технологий.
---------- Post added at 15:01 ---------- Previous post was at 15:00 ----------
Ещё плюс моего предложения: все языки среды смогут использовать лучшую в мире кодогенерацию SDCC и общие библиотеки для ZX Spectrum, которые мы разработаем или портируем.
---------- Post added at 15:04 ---------- Previous post was at 15:01 ----------
jerri, не будьте кисейной барышней, мне от Вас ничего конкретно не нужно, просто защищаю свою идеологию и авторитет. Для тех, кто будет читать ветку и находить достоинства в высказанных мною идеях.
Error404
25.03.2012, 16:10
Я знаю как убрать оверхед ZXDev (вернее, SDCC). Оверхед там оттого, что нету динамической линковки. Из библиотеки просто берутся все процедуры, даже неиспользуемые. Это можно пофиксить: a) криво, но самим – включать только используемые процедуры в библиотеку (с помощью ифдефов и конфигуратора); b) протолкнуть в SDCC идею смартлинковки. Или реализовать её самостоятельно.
В этом месте выпал в осадок. Это что, действительно правда? Такого не делали даже 8-битные CP/M-овские компиляторы тридцатилетней давности.
Или я не правильно понял. Давайте уточним: терминология "библиотека" подразумевает именно библиотеку или все же модуль, в нее входящий (который уже в свою очередь состоит из процедур). Компоновать с кратностью до модуля - это нормально (не нравится - собираешь каждую процедуру в отдельный модуль), но с кратностью до библиотечного файла - это дикий трэш и угар.
Oleg N. Cher
25.03.2012, 16:21
jerri, Вы подходите к SDCC как потребитель, а не как энтузиаст. (Чего я могу сегодня поиметь с ЭТОГО, ничего не вкладывая в ЭТО?). Подобным образом Вы подходите и к ZXDev. Я же призываю не рассматривать ни SDCC, ни ZXDev как нечто статичное и закостенелое, а как хорошее начало для достойного продолжения.
Error404, вообще-то на самом деле я просто убрал внутри Basic.c тела нескольких процедур, превратив их в пустые. И размер хеловорлда стал на несколько сотен байт меньше. Проверьте. Остальное выясним методом практики.
Под библиотекой понимаю "модуль", который скомпилен в lib, и мы юзаем процедуры, вызывая их оттуда. Но такая же лабуда наблюдается и без использования lib. Неиспользуемые процедуры SDCC всё равно вставляет в программу.
Так что подтверждаю: хеловорлд в несколько десятков байт на Обероне для Спектрума ВОЗМОЖЕН.
Alex Rider
26.03.2012, 02:08
Хочу сказать Alex Raider. Не серчайте,
Пока мир. Читаю тему пассивно. Большого интереса не вижу, но и угнетать разработку своими мыслями не хочу. При налчии свободного времени занимаюсь своими проектами. В интересных для меня конструктивных дискуссиях возможно буду принимать участие на стороне себя. Ибо все для удовольствия.
P.S. Еще меньше серчать буду, если мой ник в цитатах и обращениях будет писаться правильно.
Andrew771
26.03.2012, 10:42
Oleg N. Cher, ну всё-таки ЯВУ на Спектруме, ИМХО, в наше время нужен в подавляющем большинстве случаев для написания игр. Софт на нем будет сложно написать, не экономично по памяти и так себе по быстродействию. К тому же, вряд ли новый софт для Спека кто-то будет писать. Остаются игры.
В играх важны в первую очередь: вывод спрайтов, вывод текста, реагирование на клавиатуру и джойстик, обработка двумерной карты/полей. Не важны: числа с плавающей точкой, обработка строк, многомерные массивы. Можно обойтись без записей. Плюс в Спектруме выгоднее делать умножение/деление и размерности массивов на кратные 2 числа. Вот это я и хочу реализовать, отбросив всё лишнее, оставив только важное и нужное.
Т.е., язык будет подогнан под архитектуру Спектрума и не более, будет урезанным по сравнению с оригиналом, но за счет этого оптимизирован для Спектрума. Поэтому SDCC и другие существующие компиляторы не подходят - они не оптимальны конкретно для Спектрума, т.к. универсальны и хотят быть совместимыми со всем и вся. И вызывает сомнение компиляция через промежуточный язык С - могут добавиться к изначальной универсальной кривости Оберона/Паскаля ненужные извращения С.
В общем, я за узкую локальную задачу - оптимизированный язык-инвалид для единственной платформы Спектрум.
В общем, я за узкую локальную задачу - оптимизированный язык-инвалид для единственной платформы Спектрум.
Ну инвалидность же нисколько не мешает существованию компилятора скажем под PC?
Oleg N. Cher
26.03.2012, 18:38
Andrew771, делать высокодинамические или большой сложности игры на Паскале для Спектрума – это ещё бОльшая идея фикс чем компиляция через Си. Дело в том, что если в технологии высокоуровневого клея (в Обероне, Си или Паскале) для Спектрума будет накоплено много разнообразных и очень оптимизированных асм-библиотек (ессно не вшитых в компилер), то сама суть клея – клеить – будет помогать быстрой разработке (причём софта тоже, не только игр. А в чём ты видишь преграду для этого?), а непосредственно высокий уровень останется для скорого макетирования или, скажем, разработки утилит (типа конвертеров), для которых не столь уж важно быть написанными именно на асме, главное чтобы они были написаны быстро и без ошибок. И код имел бы хорошую наглядность, необходимую для дальнейшего наращивания функционала утилиты.
SDCC подходит для Спектрума чудесно. Лучшего кодогенератора с ЯВУ, чем SDCC, для Z80 нет и процентов 99, что никогда не будет. Поэтому можно спокойно игнорировать этот факт, а можно и нет.
В играх важны в первую очередь: вывод спрайтов, вывод текста, реагирование на клавиатуру и джойстик, обработка двумерной карты/полей. Не важны: числа с плавающей точкой, обработка строк, многомерные массивы. Можно обойтись без записей. Плюс в Спектруме выгоднее делать умножение/деление и размерности массивов на кратные 2 числа. Вот это я и хочу реализовать, отбросив всё лишнее, оставив только важное и нужное.
Вот поэтому и нужно сделать библиотеки (а не вшивать весь функционал внутрь компилера раз и навсегда), которые будут реализовать вывод спрайтов, вывод текста, реагирование на клавиатуру и джойстик. И все эти функции будут доступны из всех языков среды. Т.е. кроссъязыковость и кроссплатформенность. Вот что я предлагаю.
Числа с плавающей точкой, обработка строк, многомерные массивы должны быть обязательно реализованы на уровне языка, и они никак не помешают. Это дополнительные возможности, и когда уровень технологии будет расти, будет расти и круг задач под неё. Нельзя обойтись без записей. Это конструирование пользовательских структур данных, делать без записей что-то серьёзное сложно. Эмулировать записи через массивы – тоже не фунт изюму. Умножения и деления, кратные 2, – частный случай остальных умножений и делений. Надо реализовать все деления и все умножения, но кратные двум будут просто оптимизированнее. И ессно при программировании под Спектрум все будут этим фактом активно пользоваться.
Вобщем, язык-инвалид это конечно хорошо, но тогда проект делаешь чисто для себя. Я бы предложил тебе максимально ориентироваться на совместимость с Turbo Pascal (и по библиотекам, но с поправкой на кроссплатформенность). Я вот тоже хочу понять, для себя я делаю ZXDev, или же это интересно и ещё кому-то. Если за несколько месяцев не будет очень ярко выраженного интереса и помощи, забью конечно.
Alex Rider, прошу прощения, исправлюсь.
Andrew771
27.03.2012, 10:28
Пользователями этого языка, судя по темам на форуме, будут те, кто не знает или не хочет изучать ассемблер. Они не собираются писать софт под Спектрум (тут без асма никуда), а только игры. Кто знает ассемблер, скорее всего, не будут использовать язык или будут ограниченно.
Для игр, как я уже написал, важны только некоторые составляющие языка: вывод спрайтов, вывод текста, опрос клавиатуры/джойстика, обработка двумерной карты. Остальное не важно и не нужно. Плюс, по своему опыту написания игр на асме, всегда идет подгонка под массивы с размерностью кратной 2 и умножение/деление кратное 2. Если, к примеру, X нужно умножить на 3, то я пишу на асме X*2+X, а не использую специальную процедуру умножения на произвольное число (умножение на 2 - это всего лишь сдвиг регистра влево на 1 бит).
Игры, где используются числа с плавающей точкой - обычно трехмерные, тут уже без асма не обойтись из-за быстродействия. Да и то, в них не происходит "честное" вычисление функций, а используются заранее вычисленные таблицы. Поэтому ЯВУ тут не нужен.
Записи - не очень нужны. На асме, как правило, разные поля записи в памяти размещаются своими отдельными массивами - так проще вычислять их адрес, чем лазить по целым записям, чтобы отыскать нужное поле.
Многомерные массивы - не нужны. Из-за ограниченной памяти. Трехмерную игру не напишешь на них, для двумерных - они не нужны.
Обработка строк (имеется в виду вырезание, склеивание, поиск, замена) - больше для софта подходит, чем для игр. Может только в каких-нибудь играх с искусственной речью нужны. Можно исключить.
Это дополнительные возможности, и когда уровень технологии будет расти, будет расти и круг задач под неё.
Да не будет уровень технологии на Спектруме расти, и будущего у Спектрума нет. Это ретро-платформа. Максимум технологии по быстродействию и памяти - это программирование на голом ассемблере табличными методами, таблицы подгоняются под удобные адреса, а не под удобную структуру объектов-записей.
Универсальность языка ведет к потере быстродействия и памяти. Для PC это не важно, т.к. там и того, и другого выше крыши. А для Спектрума это существенно. И тут нужно всё подгонять под него.
Повторяю. Люди, которые умеют программировать на ассемблере, будут писать на ассемблере, и даже в качестве "клея" им не понадобится универсальный ЯВУ, проще на ассемблере с макросами. Те, кто не умеет на ассемблере, будут пользоваться универсальным ЯВУ, если он будет намного лучше Бейсика по быстродействию и памяти, если в нем есть библиотека быстрых процедур вывода спрайтов, текстов и прочее. А писать процедуру вывода спрайтов на ЯВУ они не будут - это неработоспособно.
Люди, которые умеют программировать на ассемблере, будут писать на ассемблере
Не пишу и больше не буду. Надоело. PureBasic развратил.
Error404
27.03.2012, 11:26
Пользователями этого языка, судя по темам на форуме, будут те, кто не знает или не хочет изучать ассемблер. Они не собираются писать софт под Спектрум (тут без асма никуда), а только игры. Кто знает ассемблер, скорее всего, не будут использовать язык или будут ограниченно.
Сразу видно игродела. ;)
Вообще-то, все с точность до наоборот. Это игры еще как-то можно писать на асме, а вот сложные системы (ОС и утилиты, или тот же TCPIP) гораздо удобнее писать на С, тем паче что на С можно делать большие заимствования (портировать уже готовое) - это очень существенно в условиях когда поднять что-то большое с нуля уже ни у кого из форумчан не хватает потенции. И если говорить за пакет SDCC, то крайне необходима среда разработки на С с нормальным отладчиком (а не убогим SDCDB). Хотя бы как обертка над тем же SDCDB.
То, что вместе со средой разработки на C будут приятные плюшки в виде Оберонов, это только в плюс.
Если, к примеру, X нужно умножить на 3, то я пишу на асме X*2+X
Лол, распальцованным ассемблерщикам пофиг что (X << 1) + X выполняется МЕДЛЕННЕЙ, чем X + X + X? :v2_dizzy_facepalm:
sdcc команды умножения очень элегантно заменяет сложениями, проигрыш в производительности будет только если умножать на число чуть меньшее, чем степень двойки, типа 2^n-1. Потому что тут можно обойтись сдвигом и вычитанием, а sdcc все равно генерит сложение.
Error404, и много ты сложных систем на Спек пишешь?
я смотрю для спека все системные программы практически написаны :)
---------- Post added at 11:44 ---------- Previous post was at 11:42 ----------
Лол, распальцованным ассемблерщикам пофиг что (X << 1) + X выполняется МЕДЛЕННЕЙ, чем X + X + X? :v2_dizzy_facepalm:
really?
ld d,h
ld e,l
add hl,hl
add hl,de
VS
ld d,h
ld e,l
add hl,de
add hl,de
jerri, эээ, что-то старый я стал, сдвига не вижу :v2_dizzy_roll:
ld d,h
ld e,l
add hl,hl
add hl,de
чем тебе не сдвиг? :)
да да совсем старый :) на грязи надо ехать :) отдыхать - привыкать
Да не будет уровень технологии на Спектруме расти, и будущего у Спектрума нет.
Будущего нет у процедурного программирования. Скоро будут процессоры с 1024 ядрами, под которые можно писать только на функциональных языках или на чём-то, что ещё не придумали. Или вообще откажутся от понятия "ядро" и будут программировать на верилоге.
alone, да да будущего нет :) доживем до декабря 2012 и посмотрим
чем тебе не сдвиг? :)
да да совсем старый :) на грязи надо ехать :) отдыхать - привыкать
Пардон, это же сложение? А я и писал именно про то, что сложения быстрей сдвига. Для байтов - add a,a - 4 такта, sla a - 8 тактов.
Если нет разницы, то зачем платить больше?
Andrew771
27.03.2012, 12:25
Для байтов - add a,a - 4 такта, sla a - 8 тактов.
вместо sla a лучше rlca.
Eltaron, а чем тебе add hl,hl не сдвиг влево? :)
Error404
27.03.2012, 12:52
Error404, и много ты сложных систем на Спек пишешь?
я смотрю для спека все системные программы практически написаны :)
Для именно Спека я не пишу ничего.
Для Ориона пишу и на асме и на С. Большая ли разница в писании под Орион и Спек - вопрос религиозный. Портирование стека TCPIP из исходников на С у меня заняло примерно 40 часов (месяц вечерами). Напишешь ты за 40 часов сетевой стек на ассемблере? Можно не отвечать, вопрос риторический.
С другой стороны, CP/M я правлю на асме, (хотя оригинал был на PL, кстати), и это очень долгий процесс - на асме проще наделать ошибок и сложнее отлаживаться.
Я конечно понимаю, что собственные шишки набивать, заново доказывая в 21 веке то, что уже считалось доказанным в 20м, это очень по спектрумистски, но тут уж давайте определяться: шашечки вам или ехать. Если дороже бесконечный и безрезультативный процесс, то пожалуйста - асм вам в руки. Если надо поиметь что-то реальное на выходе, то наиболее прямой путь - портирование. А с какого языка в код Z80 реально портировать, учитывая что на аcме Z80 ничего что нам хотелось бы, добрый дядя не выложил? Вопрос опять риторический.
Eltaron, а чем тебе add hl,hl не сдвиг влево? :)
ладно, уговорил :) действительно, этот машинный код можно было б и SLA HL назвать
---------- Post added at 15:51 ---------- Previous post was at 15:48 ----------
вместо sla a лучше rlca.
но там же в случае переполнения ерунда получится, а не умножение?
Andrew771
27.03.2012, 14:33
Сообщение от Andrew771
вместо sla a лучше rlca.
но там же в случае переполнения ерунда получится, а не умножение?
Если a<128, то нормально. Если a>=128, то и при sla a, и при rlca ерунда, т.к. результат уже двухбайтный должен быть (если использовать в ЯВУ).
Oleg N. Cher
27.03.2012, 15:00
Пользователями этого языка, судя по темам на форуме, будут те, кто не знает или не хочет изучать ассемблер.
Неа, пользователями этого языка, вероятнее всего, будешь только ты один. Я тут такую привлекательную картинку нарисовал: программь под что угодно на чём угодно, и то подавляющее большинство оппонентов против, а не за. Чего уж сказать про Паскаль. Кроме того, человек, который не знает асма Z80, вероятно, не будет писать игры для Спектрума ни на чём. И я предлагаю знатокам асма не замену асму, а просто способ увеличить собственную производительность там, где это можно без потерь (или с малыми).
Если, к примеру, X нужно умножить на 3, то я пишу на асме X*2+X, а не использую специальную процедуру умножения на произвольное число
Андрей, но ведь запись X*2+X это реверанс в сторону тупого компилятора, а запись X*3, которая, кстати, нагляднее для понимания (и проще), но которую умный компилятор может перевести в сложения и сдвиги, что, кстати, SDCC делает. Что подтверждает и Eltaron:
sdcc команды умножения очень элегантно заменяет сложениями
Универсальность языка ведет к потере быстродействия и памяти. Для PC это не важно, т.к. там и того, и другого выше крыши. А для Спектрума это существенно. И тут нужно всё подгонять под него.
Есть такая библиотека KOL, Владимир Кладов написал. Так она уже занимает больше мега исходников. Туда можно очень много добавить. Но программы, которые делаются на этой библиотеке, преимущественно размером < 100 Кб. Это очень реальный даже для Спека размер. Всё дело в подходе, потому как из KOL берётся только то, что используется. Примерно также можно сделать и с универсальностью. Да, у Спека экран устроен иначе, но в некоторых случаях для универсальности этим можно пренебречь. И пренебрегают, отсюда клэшинг атрибутов. Или ч/б вместо цвета. Всё можно продумать и сделать. Но очень трудно найти хотя бы 2 человека, которым на 100% понравятся все твои (или мои) идеи. Проблему я вижу именно в этом. А не в чрезмерной универсальности. Ну вот, спрайты Даша прекрасно себе чёрно-белые на Спеке и цветные под досом. Логика игры этот факт игнорирует, оставляя реализацию графической подсистеме. Разрешение экрана устройства она тоже игнорирует, манипулируя разрешением лабиринта. И так далее.
А писать процедуру вывода спрайтов на ЯВУ они не будут - это неработоспособно.
Я разве где-то предлагал такое делать? Всякому овощу свой сезон, а всякой задаче свой язык.
Ладно, давай искать точки соприкосновения дальше. Ты собираешься реализовывать ReadLn для строк и чисел? Если да, любопытно было бы взглянуть. Я сделал такую процедуру ещё на языке Coloss, и она позволяла редактировать введённое число только полным затиранием и перенабором, сейчас полагаю, это надо исправить. Нервы юзеров дороже. Нужно обязательно реализовать забивку (Backspace), курсор влево-вправо. Ещё есть идея реализовать память для прошлых введённых значений (вдруг новое число проще получить из старого путём изменения одной цифры) по клавишам вверх-вниз (примерно как было в досовской проге Doskey, очень удобно). Функционал буфера прошлых введённых значений можно сделать опциональным (нетрудно придумать задачу, где он не нужен). Согласен или предпочитаешь что-либо попроще (или другое)?
Не вижу смысла сейчас писать что-то под DOS. Можно писать кроссплатформенно под ZX и CPC (Dizzy), ZX и MSX (Ball Quest), ZX и SMD (tfm player).
Oleg N. Cher
27.03.2012, 15:52
Когда поговорили о недоязыке, то оказалось что в нём не нужны записи и вещ.числа. А когда говорим о Спеке, оказывается, что это ретроплатформа. Теперь до доса дошли руки. Конечно кроссплатформенность в рамках платформ, юзающих проц Z80, достижима и на асме. А как насчёт кроссплатформенности между ZX, Win32, Linux и Android? Здесь Спек-то как лакмус. Показывает, не слишком ли разраслась идеология, не превратилась ли она уже в PL/1 (или C#). Оберон язык маленький, но делать на нём можно всё: от написания браузеров и ОС под любое железо до разработки веб-сайтов и написания игр для платформ на базе Z80.
Eltaron, а чем тебе add hl,hl не сдвиг влево? :)
кстати, если считать это сдвигом, то sdcc генерит именно сдвиги, и в этом случае претензии к нему вообще не принимаются :)
unsigned short mul(unsigned char w)
{
return w * 31;
}
ld l,e
ld h,d
add hl,hl
add hl,de
add hl,hl
add hl,de
add hl,hl
add hl,de
add hl,hl
add hl,de
Что ж он sbc hl,de не использовал )
а короче разве?
ld l,e
ld h,d
add hl,hl
add hl,hl
add hl,hl
add hl,hl
add hl,hl
or a
sbc hl,de
Дык, явно короче.
Кстати, я как-то искал множители, которые выгодно разложить на два умножения, но не нашёл ни одного!
Andrew771
27.03.2012, 16:36
А не выгоднее HL*256/4-HL? :)
---------- Post added at 16:36 ---------- Previous post was at 16:30 ----------
Ты собираешься реализовывать ReadLn для строк и чисел? Если да, любопытно было бы взглянуть.
думаю, в играх достаточно только BackSpace. :)
А не выгоднее HL*256/4-HL?
Вряд ли.
Andrew771
27.03.2012, 16:42
Да, у Спека экран устроен иначе, но в некоторых случаях для универсальности этим можно пренебречь. И пренебрегают, отсюда клэшинг атрибутов. Или ч/б вместо цвета. Всё можно продумать и сделать. Но очень трудно найти хотя бы 2 человека, которым на 100% понравятся все твои (или мои) идеи. Проблему я вижу именно в этом. А не в чрезмерной универсальности. Ну вот, спрайты Даша прекрасно себе чёрно-белые на Спеке и цветные под досом. Логика игры этот факт игнорирует, оставляя реализацию графической подсистеме. Разрешение экрана устройства она тоже игнорирует, манипулируя разрешением лабиринта. И так далее.
Ну логика лабиринта - это одно, а вывод клеток лабиринта - другое. Вывод можно встроить отдельной заранее написанной процедурой на асме, а не игнорировать, доверяясь программисту.
Логика лабиринта (кстати, это всего лишь двухмерная карта) тоже может состоять из некоторых стандартных заранее написанных процедур, которые можно встроить: проверка соседних полей с заданным полем на значение, проверка области вокруг заданного поля с заданной глубиной и т.д. (подумать еще надо, что часто встречается).
Oleg N. Cher
27.03.2012, 16:53
Andrew771, наверное у тебя есть и задумка игры, которую можно сделать на твоей реализации Паскаля? Расскажи.
Andrew771
27.03.2012, 16:58
Andrew771, наверное у тебя есть и задумка игры, которую можно сделать на твоей реализации Паскаля? Расскажи.
Нету конкретной задумки. Есть понимание, что просмотр клеток лабиринта в ZXOOM, полей в Эрудите и карты в будущей стратегии - это одно и тоже. Вывод текстов и спрайтов везде одинаков. А раз так, то можно это обобщить в ЯВУ.
Что ж он sbc hl,de не использовал )
со временем научится, принципиальных проблем ведь нету
Кстати, вот что генерит IAR:
LD D,0
LD BC,31
CALL ?S_MUL_L02
Боюсь, я перестану считать его хорошим компилятором :)
Oleg N. Cher
28.03.2012, 10:21
Andrew771, ну так и тебе не чужда тяга к универсальности. :) Если наваяешь игру, которая меня заинтересует, можем попробовать доказать на практике, что универсальность ей никак не повредит. Спортируем её в рамках ZXDev на Оберон и другие платформы. Включая ZX, кодогенерация SDCC пойдёт ей только на пользу.
Насчёт ReadLn. Можно реализовать только Backspace, курсоры и буфер. Курсоры и буфер будут опциональными, т.е. если они не нужны в проекте, то и код лишний не будет включен. Именно к такому подходу надо стремиться. К универсальности, функциональности и компактности. Имхо.
Andrew771
29.03.2012, 12:10
Задумка игры такая (ищи мои посты там): http://zx.pk.ru/showthread.php?t=9146&highlight=civilization
В 48к всё, что там описано, не поместится. Да и делать очень долго, может интерес пропасть. Поэтому пока есть планы сделать стратегию в стиле Древней Руси или Римской Империи без науки и изменения строев, и юниты только соответствующие эпохе. За год можно наклепать, если не лениться. Сейчас у меня хандра, ничего не делаю, даже апдейт для Эрудита почти готовый не могу закончить. :)
Если сначала создать ЯВУ, а потом только писать, то сроки явно затянутся. Дилемма.
Readln в играх для Спека, которые я знаю, всегда был только с backspace и более ничего. Ну если на Бейсике, то был еще курсор. А вот буфер - это уже писюканство.
В писюке есть еще буфер клавиатуры - гадость ужасная, до сих пор бесит.
Oleg N. Cher
30.03.2012, 00:32
Андрей, есть 2 противоположных подхода к программированию на Спектруме, да и не только на нём.
Первый. Это тупейший транслятор (компилятор или ассемблер) и умнейший и энергичнейший кодинг. Алгоритмы абсолютно втиснуты в архитектуру процессора, обкромсаны до частного их варианта использования, подходящего только для этого конкретного случая. Чего-то лишнее (расширения, универсальность) убраны, ибо это потери. Код экономится до байтика, такты проца тоже. Шикарный кодинг может вызвать восхищение среди таких же кодеров. Реализация крайне ориентирована на конкретные платформу и процессор. Ничего плохого в таком кодинге нет. Эффективность и компактность, быстроту никто не отменял. Проблемы начинаются когда надо понять устройство алгоритма, расширить его функциональность или портировать его на другой процессор/язык/платформу.
Первый путь был мне очень мил где-то в году 1996-м, году появления компилятора Coloss и игры SeaFight. Ничего более наглядного и красивого, чем Coloss, в плане низкоуровневого языка-инвалида для Спектрума (замены ассемблеру) я не встречал. А, вру. Встречал. Это язык Metal Владимира Кладова. Где-то на этом форуме о нём рассказывал Владимир.
Может я бы как-то более с энтузиазмом отнёсся к твоим идеям недопаскаля, но таких игрушечных компиляторов я уже делал не один десяток. Сперва QuickForth для ZX (на базе HL ZX Forth), потом Coloss для Спектрума (на Спектруме), потом Coloss для Доса (на Паскале), потом Coloss для Доса на Coloss’е (метатранслятор весил около 2 кб). Потом Coloss для Винды на Дельфи. Потом делал Паскаль. Делал маленький кроссплатформенный компилятор Оберона. Исходники к сожалению погибли. Надо ещё повспоминать, было что-то ещё. Просто хочу сказать, что всегда найдётся тот, кому будут нужны записи в недоязыке.
К тому же реализовать полностью вот хотя бы даже Оберон – это не так уж и много работы. Очень советую тебе вдумчиво изучить проект Оберс (http://zx.oberon2.ru/obers.htm). Это транслятор Оберона-2 в текст на макроассемблере NASM. Т.е. примерно такого же уровня штучка, что ты задумал. Можно переделать его для Спектрума. Наверное. Но это вполне себе серьёзная реализация, хоть сейчас садись и делай на нём многозадачную операционную систему для защищённого 32-битного режима. Недостаток: практически нет оптимизации. Достоинство: бинарник транслятора весит 25 Кб. Согласись, реальный даже для Спека объём. Теперь чуть критики, надеюсь, ты не обидишься. Вынос проекта на общее обсуждение предполагает насыщение новыми идеями. Ты довольно закрыт для идей со стороны. Вот как задумал, так и не пожертвовал ни одной своей идеей. Трудно будет работать в команде, разве что твой авторитет будет абсолютным.
Второй подход. Это абсолютно умный, практически идеальный компилятор (а ведь оно того стоит, потрудиться чтобы он появился), нагляднейшая форма представления алгоритмов, включая графику, таблицы и прочие возможности визуализации. Это гибкая настройка свойств алгоритма и свойств низкоуровневых компонентов. Это совместимость между различными платформами, включая ретро. Для Спека предполагается сделать много компонентов (на асме), с возможностью гибкого их конфигурирования, язык высокого уровня с сверхнизким оверхедом и совместимые снизу вверх библиотеки для различных платформ. Сейчас мне гораздо ближе по духу вот такой второй способ. Хотя идеальной кодогенерации для Z80 нет и не предвидится, всё равно работать для таких идей представляется интересным. Появляются новые возможности. Лёгкое понимание и модификация алгоритмов. Разворачивание их на любую платформу (автоматически), быстрая работа с низкой сложностью, высокий уровень, хорошие перспективы для платформ, котоые ещё даже не реализованы. В этом смысле я вижу очень хорошую перспективу для Оберон-технологий, правда, к ним надо ещё приложить руку конечно.
Я буду сейчас заниматься другими проектами и платформами. Считайте, что на ZXDev забил. Ввиду почти полного отсутствия интереса и помощи.
Andrew771
30.03.2012, 11:39
Посмотрел я Coloss и встроенный язык в эмулятор EmuZWin - это всего лишь замена названий команд ассемблера, но принципиально ничего не облегчает. Ну буду я писать a=7 вместо ld a,7 , что это меняет?
Вот еще пример из твоего языка Coloss:
{ 87 = alpha ‘ LD A,87 ‘
‘ LD (alpha),A ‘
** = beta ‘ ADD A ‘
‘ LD (beta),A ‘
alpha + beta ‘ LD A,(alpha) ‘
‘ LD HL,beta ‘
‘ ADD (HL) ‘
= alpha = ! ‘ LD (alpha),A ‘
‘ RST 10h ‘
ret ‘ RET ‘
## alpha , beta ; ‘ alpha: DW 0 ‘
‘ beta: DW 0 ‘
Из всего написанного лично у меня наибольший внутренний протест вызывает вывод символа по RST 10h конструкцией “{ = !”
Была мысль сделать вывод с помощью потоков... не совсем удачная. Обратите внимание на скромную открывающуюся фигурную скобку в самом начале проги. Ей не соответствует закрывающая. И не должна. Вся эта программа написана в малом (байтовом) представлении. И если вдруг мы захотим работать не с байтами, а словами, и с HL вместо A, зачем писать не “alpha + beta”? Т.е. “{“ переход в байтовый формат; ”}” соответственно в формат слов. Вещественной арифметики, встроенной в компилятор, к сожалению пока нет. Нужно писать быструю библиотеку, калькулятор Спека по RST 28h ОЧЕНЬ медленный.
Итак, во что превратится наша прожка, если изменить скобку:
} 87 = alpha ‘ LD HL,87 ‘
‘ LD (alpha),HL ‘
** = beta ‘ ADD HL,HL ‘
‘ LD (beta),HL ‘
alpha + beta ‘ LD HL,(alpha) ‘
‘ LD DE,(beta) ‘
‘ ADD HL,DE ‘
= alpha = ! ‘ LD (alpha),HL ‘
‘ CALL WRITENUM ‘
ret ‘ RET ‘
## alpha , beta ; ‘ alpha: DW 0 ‘
‘ beta: DW 0 ‘
В большом (словарном) представлении конструкция “} = !” уже выводит не символ по коду в A, а число, находящееся в HL. Вывод производится с помощью процедуры writenum, к-рая находится в стандартной библиотеке COLOSS.COL.
Почему присваивать нужно обязательно 87=alpha, а не alpha=87?
Непонятно, что означает **=beta. А почему нельзя написать beta=alpha*2? А потом alpha=alpha+beta ? А потом print alpha?
И почему скобка открывается, но не закрывается. Тогда замени ее другим чем-нибудь, оператором установки режима "байты/слова" например.
Пойми, что если исходный код состоит из закорючек и если компилируемый код не оптимален, то проще писать либо на Бейсике, либо на Ассемблере, т.к. они стандартны и известны. Оберон будет лучше Coloss, т.к. он стандартен и известен.
Полной оптимизации кода из ЯВУ часто не удается достигнуть, а для Спектрума это очень важно. Иначе получается встроенный Бейсик. Так зачем широко известный каждому спектрумисту Бейсик менять на малоизвестный Оберон?
Сейчас оптимален и используется как основной язык Ассемблер. Нужна ему более лучшая замена. Замена не названиям ассемблерных команд, а целым ассемблерным конструкциям и процедурам. Это уже есть, называется "макросы ассемблера". Нужно стандартизировать эти макросы, назвать операторами из известного ЯВУ и по возможности подогнать под конструкции ЯВУ. Т.е. идти снизу вверх, от кодов к операторам ЯВУ, а не традиционно от операторов ЯВУ к кодам.
Почему присваивать нужно обязательно 87=alpha, а не alpha=87?
Потому что это не уравнение, а присваивание. И сначала вычисление, только потом само присваивание.
Oleg N. Cher
31.03.2012, 13:26
Я не стану утверждать, что Coloss кажется мне верхом совершенства. Это замена асму для краткости. Coloss более лаконичен и более нагляден. Но не во всём. Сейчас мне некоторые вещи в нём видятся уродливыми, теперь я бы стал делать иначе. Например, я обозначал { % как регистр C, { = [[]] } как присваивание LD (BC),A - сейчас я предпочёл бы { C и = [BC]
Придраться есть к чему. Но в Coloss'е трансляция атомарная, как в асме. Соответственно транслятор примитивнейший, а код можно получить идеальный. Да, Coloss можно и нужно пересмотреть. Это безусловно. Но я этим заниматься не буду.
Oleg N. Cher
29.11.2012, 20:02
В рамках проекта XDev (http://zx.oberon2.ru/forum/viewforum.php?f=10) успешно собран экспериментальный мидлет на Компонентном Паскале. Меня тут уверяли, что пуребасик это крайне качественный продукт, так вот, господа, время показывает, что мощь Оберонов значительно превосходит наши с вами представления о них. На Оберонах возможно то, что пуребасику и не приснится. Анонсирую игру Dash с открытыми исходниками (http://zx.oberon2.ru/forum/viewtopic.php?f=27&t=38), целевые платформы (пока) — ZX Spectrum, J2ME и MS DOS. Возможно, в дальнейшем будет поддержана Amiga, Win32/64, UNIX/Linux и др. платформы.
Планируются также эксперименты по разработке софта на КП для Android. Желающих попробовать освоить это направление рад видеть в аське, мейле и у себя на форуме (http://zx.oberon2.ru/forum/).
Обращаю ваше внимание, что Компонентный Паскаль — это правильное надмножество языков Оберон-1 и Оберон-2, а это значит что можно вести разработку игры практически на одном языке, и её логика будет представлять собою единые исходники, собираемые для разных платформ. Иллюстрирую это своим проектом Dash (для MS DOS: язык Оберон-1/компилятор Oberon-M; для J2ME: язык Компонентный Паскаль/компилятор GPCP; и для ZX Spectrum: язык Оберон-2/транслятор Ofront/SDCC). Проект только недавно начал переносить под версионный контроль, поэтому сами понимаете.
Недавно с интересом узнал, что в своё время для компьютера Amiga много писали на модульных языках. Существовал даже Amiga Modula & Oberon Klub (AMOK), который зарелизил более сотни с лишним флоппи дисков с исходниками на Модуле и Обероне. Всё это доступно для скачивания. Подробнее об этом в теме Amiga и модульные языки (http://zx.oberon2.ru/forum/viewtopic.php?f=3&t=39).
Oleg N. Cher
03.12.2012, 20:55
Добавил платформу ZX Spectrum (https://sourceforge.net/projects/bolderdash/). Покритикуйте, пожалуйста, процедуру вывода тайлов GrTiles.PutTile (https://github.com/Oleg-N-Cher/Dash/blob/master/Src/ZxSpec%20(Ofront-SDCC)/GrTiles.c) — размер 16x12 (без атрибутов) на предмет скорости. Понимаю, что кардинально можно ускорить, запретив прерывания и воспользовавшись методом вывода через стек, но пока решено использовать режим IM 2.
Alex Rider
03.12.2012, 22:03
В Unreal Spectrum этот trd не грузится.
Oleg N. Cher, адрес на экране из hl принципиально забирать?
---------- Post added at 22:57 ---------- Previous post was at 22:55 ----------
PUSH IX
LD IX,#0
ADD IX,SP
#endif
LD A,#0x1E
CP A,4(IX) ; x
RET C ; IF x <= 30 THEN RETURN
LD C,5(IX) ; y
CP A,C
RET C ; IF y
в ix обработка ошибок?
---------- Post added at 23:04 ---------- Previous post was at 22:57 ----------
я бы перепахал таблицу
ld a,(ix+4)
add a,(hl)
ld c,a
inc l
ld b,(hl)
inc hl
ld a,(de)
ld (bc),a
inc de
inc c
ld a,(de)
ld (bc),a
inc de
ускорил бы на 48 тактов
Oleg N. Cher
10.12.2012, 18:36
В Unreal Spectrum этот trd не грузится.
А я проверил в Spectaculator 6, и тоже не грузится. В принципе, trd-шник создан старой ещё досовской утилитой Медноногова bin2trd, от которой я давно хочу избавиться. Однако сгенеренные ею trd-шки открываются в, начиная со старинного же Шалаева и заканчивая FUSE и EmuZWin. Исходников bin2trd у меня нет, и с форматом я не знаком. Надо разбираться.
Зато данный казус простимулировал работу над моей собственной утилитой MakeZX (https://github.com/Oleg-N-Cher/MakeZX). Планирую скоро зарелизить первую версию. Вероятно, поддержки формата TRD в версии 1.0 не будет, а может и вообще не будет. Разве что мне поможет кто-то более опытный, ведь утилита будет полезна не только для ZXDev, но и для SDCC (а может и ещё применения найдутся).
Интерфейс для работы с TRD будет выглядеть, скорее всего, так:
DEFINITION DiskTRD;
TYPE
DiskFile = RECORD (* OBJECT *)
error-: BOOLEAN; (* Is error after ReCreate, SaveBasic, SaveCode or Finalize? *)
END;
PROCEDURE (VAR trd: DiskFile) ReCreate (diskName: STRING);
PROCEDURE (VAR trd: DiskFile) SaveBasic (
name: STRING; startLine, dataLength: INTEGER; VAR data: ARRAY OF BYTE);
PROCEDURE (VAR trd: DiskFile) SaveCode (
name: STRING; startAddr, dataLength: INTEGER; VAR data: ARRAY OF BYTE);
PROCEDURE (VAR trd: DiskFile) Finalize;
END DiskTRD.
Работа с диском будет осуществляться так (с лентой аналогично):
PROCEDURE CreateTrdDisk;
VAR
trd: DiskTRD.DiskFile; data: ARRAY 2 OF BYTE;
BEGIN
data[0] := CHR(243); data[1] := CHR(175); (* First 2 bytes of ROM. *)
trd.ReCreate("mydisk.trd");
trd.SaveCode("ROM", 0, 2, data);
trd.Finalize;
IF trd.error THEN IO.WriteStr("Disk creating error") END;
END CreateTrdDisk;
Oleg N. Cher, адрес на экране из hl принципиально забирать?Конечно же непринципиально, можно забирать из любой пары.
в ix обработка ошибок?Не совсем. IX в начале процедуры мы настраиваем чтобы таскать параметры из стека, которые были положены туда примерно так:
LD HL, tileAddr
PUSH HL
LD HL, tileCoords
PUSH HL
CALL _GrTiles_PutTileНо мы проверяем не вышли ли координаты за пределы экрана. В конце работы над игрой эти проверки, если понадобится, можно убрать.
я бы перепахал таблицуjerri, интересная мысль! Благодарю.
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot