А вообще, препроцессор С в руках программеров-извращенцев это страшное зло. Например, я весь исплевался портируя uIP оттого, что автор науевертил там такого на макросах, что многие компилеры распутать не могут (не говоря уже о понимании всего этого людями), и соответственно либо не собирают либо собирают абы что, от чего при отладке приходишь в совершенное изумление.
Друзья мои!
Большая просьба!
Если вы не хотите использовать оберон и любые его проявления в своём будущем, то не пишите в этой теме вообще. Не оставляйте глупых постов, которые я устаю удалять, пожалейте своё и, если вам не жаль своего, то, хотя бы, моё время.
Если же у вас есть личные мотивы по отношению к автору - решите этот (или эти) вопрос(-ы) в личке, в аське или каким-либо другим способом, благо его контакты (автора темы) совсем не спрятаны.
2 камрад Sayman> мне пришлось почти все твои сообщения в этой теме удалить по причине их несвязанности с тематикой форума или переходом на личности. Прочитай, пожалуйста, моё обращение к форумчанам и к тебе лично, находящееся в начале этого сообщения.
2 камрад Zek> просьба лучше фильтровать сообщения. Если чувствуешь, что излишне завёлся - дай себе маленькую паузу, может день, может неделю, отдохни. Не вынуждай применять модераторские методы.
2 камрад Oleg N. Cher> как модератор обещаю поддержку (в виде очистки от хлама) твоей темы, но требую от тебя делать максимально политкорректные определения и высказывания. Очень уж часто они у тебя на грани перехода на личности, да и сам провоцируешь переходы в оффтоп.
Первое, что радует в Обероне (после работы на Паскале), – это сокращённая форма записи составных операторов, а если проще, то было (Pascal):
Стало (Oberon):Код:BEGIN Op1; Op2 END;
Слово BEGIN мы пишем только в двух случаях:Код:Op1; Op2 END;
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-ов для Си очень много.
Господа, всем, кто хочет помочь проекту 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 полезным и для Ваших идей. Я по-моему достаточно открыт для идей со стороны, просто скучно и долго всё делать одному. Или может подскажете, где искать помощников, если не здесь?
Что такое синтаксический сахар знаете? Или, по-Вашему, там следовало быть ND, VR и PRC?Цитата:
Сообщение от vinxru
vinxru, объективности ради согласитесь со мной, что корректнее сравнивать между собой количество букафок не между void и PROCEDURE, а между extern void / static void и PROCEDURE (а это далеко не редкость, а вовсе даже типично; я бы даже назвал очень разумным решением не светить наружу локальные объекты). К тому же, зацените, в Обероне вообще не нужны извращения типа:
Чтобы сгенерировать DLL в BlackBox даже не надо изменять текст модуля. Достаточно использовать коммандер, который слинкует Оберон-модуль в готовую DLL. Быстро и без вопросов. Дополнительные вещи (настройки, опции, ключи) упрятаны глубже, но для профессионалов всё доступно.Код:#ifdef BUILD_DLL #define _DLL_ENTRY extern __declspec(dllexport) #else #define _DLL_ENTRY extern __declspec(dllimport) ... #endif
Так что считаю сравнение между void и PROCEDURE несколько предвзятым и некорректным. В Си короче void, в Обероне же опускается static и экспорт пишется короче: все объекты для экспорта просто помечаются звёздочкой (после имени) для полного доступа или знаком минус для read only. А вот тут я наеду на всех сишников, что в их любимом Си экспорта только для чтения вообще не предусмотрено. А ведь это очень важно для построения надёжных программ.
---------- Post added at 13:42 ---------- Previous post was at 13:19 ----------
Цитата:
Сообщение от jerri
Поскольку jerri не убрал свои данные высказывания, то сообщаю, что товарищ jerri не заметил давно ещё неделек 2-3 назад выложенный снап Даша, но негатив свой высказать поторопился. Ну разве ж я в этом виноват.Цитата:
Сообщение от jerri
Oleg N. Cher, не будь снобом :) я не сижу на твоем сайте с нетерпением ожидая когда ты на нем что-нибудь выложишь.
Для информирования заинтересованных существует лента новостей.
Негатив я высказываю когда получаю ответы на вопросы которых не задавал.
Практику правки старых постов считаю порочной
качество и размер сделанного с помощью sdcc оценил и мне оно в целом не нравится. после оценки готового продукта мое присутствие здесь больше не требуется и отвечаю я тебе только если ты меня призываешь.
Отлично. Только видишь, все начитались книжек о неимоверной крутости языков Си, Си# и Java, поэтому даже разговор об их недостатках или отсутствии чего-либо в них считается кощунственным, а многих теперь даже от самого слова "Паскаль" воротит. Попробуй тут всех заставь уважать достоинства Паскаля. :wink: Да, вопрос серьёзный, что и как назвать. Может даже имя Оберон и не самое удачное в плане маркетинга.Цитата:
Сообщение от Andrew771
С первым трудно не согласиться, а вот со вторым можно поспорить. Да и входные форматы разных кроссассемблеров весьма различаются.Цитата:
Лучше делать кросс-компилятор с 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 - спрайтовый тип, на первом этапе только познакоместный цветной. Формат спрайтов продумать.
Реализации random и readkey тоже могут быть самыми разными, не надо думать, что всем подойдёт одно и то же.Цитата:
Функции: +, -, *, div, mod, random(x), code, chr, readkey.
А вывод делать планируется шрифтом какого размера? (шучу). Конечно, это всё тоже надо вынести в библиотеку. Ну, или по крайней мере в библиотеку SYSTEM, которая будет импортироваться неявно (в Паскаль-реализациях так часто сделано), но лучше если с внешним конфигуратором, в котором можно будет выбрать шрифт по умолчанию, например, или способ вывода литер (ПЗУ или прямо в видеопамять). Почему надо сделать именно так? А чтобы не плодить массу функций-переключателей, которые всё равно не будут кроссплатформенными, по определению. Я продумал эти вещи очень глубоко, и есть способ такое делать всё просто и кроссплатформенно, если интересуешься, расскажу более подробно, а лучше покажу (в ZXDev), со временем.Цитата:
write
writeln
read
readln
Если захочешь заняться реализацией поддержки Паскаля внутри Оберон-среды 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, не будьте кисейной барышней, мне от Вас ничего конкретно не нужно, просто защищаю свою идеологию и авторитет. Для тех, кто будет читать ветку и находить достоинства в высказанных мною идеях.
В этом месте выпал в осадок. Это что, действительно правда? Такого не делали даже 8-битные CP/M-овские компиляторы тридцатилетней давности.Цитата:
Сообщение от Oleg N. Cher
Или я не правильно понял. Давайте уточним: терминология "библиотека" подразумевает именно библиотеку или все же модуль, в нее входящий (который уже в свою очередь состоит из процедур). Компоновать с кратностью до модуля - это нормально (не нравится - собираешь каждую процедуру в отдельный модуль), но с кратностью до библиотечного файла - это дикий трэш и угар.
jerri, Вы подходите к SDCC как потребитель, а не как энтузиаст. (Чего я могу сегодня поиметь с ЭТОГО, ничего не вкладывая в ЭТО?). Подобным образом Вы подходите и к ZXDev. Я же призываю не рассматривать ни SDCC, ни ZXDev как нечто статичное и закостенелое, а как хорошее начало для достойного продолжения.
Error404, вообще-то на самом деле я просто убрал внутри Basic.c тела нескольких процедур, превратив их в пустые. И размер хеловорлда стал на несколько сотен байт меньше. Проверьте. Остальное выясним методом практики.
Под библиотекой понимаю "модуль", который скомпилен в lib, и мы юзаем процедуры, вызывая их оттуда. Но такая же лабуда наблюдается и без использования lib. Неиспользуемые процедуры SDCC всё равно вставляет в программу.
Так что подтверждаю: хеловорлд в несколько десятков байт на Обероне для Спектрума ВОЗМОЖЕН.
Пока мир. Читаю тему пассивно. Большого интереса не вижу, но и угнетать разработку своими мыслями не хочу. При налчии свободного времени занимаюсь своими проектами. В интересных для меня конструктивных дискуссиях возможно буду принимать участие на стороне себя. Ибо все для удовольствия.Цитата:
Сообщение от Oleg N. Cher
P.S. Еще меньше серчать буду, если мой ник в цитатах и обращениях будет писаться правильно.
Oleg N. Cher, ну всё-таки ЯВУ на Спектруме, ИМХО, в наше время нужен в подавляющем большинстве случаев для написания игр. Софт на нем будет сложно написать, не экономично по памяти и так себе по быстродействию. К тому же, вряд ли новый софт для Спека кто-то будет писать. Остаются игры.
В играх важны в первую очередь: вывод спрайтов, вывод текста, реагирование на клавиатуру и джойстик, обработка двумерной карты/полей. Не важны: числа с плавающей точкой, обработка строк, многомерные массивы. Можно обойтись без записей. Плюс в Спектруме выгоднее делать умножение/деление и размерности массивов на кратные 2 числа. Вот это я и хочу реализовать, отбросив всё лишнее, оставив только важное и нужное.
Т.е., язык будет подогнан под архитектуру Спектрума и не более, будет урезанным по сравнению с оригиналом, но за счет этого оптимизирован для Спектрума. Поэтому SDCC и другие существующие компиляторы не подходят - они не оптимальны конкретно для Спектрума, т.к. универсальны и хотят быть совместимыми со всем и вся. И вызывает сомнение компиляция через промежуточный язык С - могут добавиться к изначальной универсальной кривости Оберона/Паскаля ненужные извращения С.
В общем, я за узкую локальную задачу - оптимизированный язык-инвалид для единственной платформы Спектрум.
Ну инвалидность же нисколько не мешает существованию компилятора скажем под PC?Цитата:
Сообщение от Andrew771
Andrew771, делать высокодинамические или большой сложности игры на Паскале для Спектрума – это ещё бОльшая идея фикс чем компиляция через Си. Дело в том, что если в технологии высокоуровневого клея (в Обероне, Си или Паскале) для Спектрума будет накоплено много разнообразных и очень оптимизированных асм-библиотек (ессно не вшитых в компилер), то сама суть клея – клеить – будет помогать быстрой разработке (причём софта тоже, не только игр. А в чём ты видишь преграду для этого?), а непосредственно высокий уровень останется для скорого макетирования или, скажем, разработки утилит (типа конвертеров), для которых не столь уж важно быть написанными именно на асме, главное чтобы они были написаны быстро и без ошибок. И код имел бы хорошую наглядность, необходимую для дальнейшего наращивания функционала утилиты.
SDCC подходит для Спектрума чудесно. Лучшего кодогенератора с ЯВУ, чем SDCC, для Z80 нет и процентов 99, что никогда не будет. Поэтому можно спокойно игнорировать этот факт, а можно и нет.
Вот поэтому и нужно сделать библиотеки (а не вшивать весь функционал внутрь компилера раз и навсегда), которые будут реализовать вывод спрайтов, вывод текста, реагирование на клавиатуру и джойстик. И все эти функции будут доступны из всех языков среды. Т.е. кроссъязыковость и кроссплатформенность. Вот что я предлагаю.Цитата:
Сообщение от Andrew771
Числа с плавающей точкой, обработка строк, многомерные массивы должны быть обязательно реализованы на уровне языка, и они никак не помешают. Это дополнительные возможности, и когда уровень технологии будет расти, будет расти и круг задач под неё. Нельзя обойтись без записей. Это конструирование пользовательских структур данных, делать без записей что-то серьёзное сложно. Эмулировать записи через массивы – тоже не фунт изюму. Умножения и деления, кратные 2, – частный случай остальных умножений и делений. Надо реализовать все деления и все умножения, но кратные двум будут просто оптимизированнее. И ессно при программировании под Спектрум все будут этим фактом активно пользоваться.
Вобщем, язык-инвалид это конечно хорошо, но тогда проект делаешь чисто для себя. Я бы предложил тебе максимально ориентироваться на совместимость с Turbo Pascal (и по библиотекам, но с поправкой на кроссплатформенность). Я вот тоже хочу понять, для себя я делаю ZXDev, или же это интересно и ещё кому-то. Если за несколько месяцев не будет очень ярко выраженного интереса и помощи, забью конечно.
Alex Rider, прошу прощения, исправлюсь.
Пользователями этого языка, судя по темам на форуме, будут те, кто не знает или не хочет изучать ассемблер. Они не собираются писать софт под Спектрум (тут без асма никуда), а только игры. Кто знает ассемблер, скорее всего, не будут использовать язык или будут ограниченно.
Для игр, как я уже написал, важны только некоторые составляющие языка: вывод спрайтов, вывод текста, опрос клавиатуры/джойстика, обработка двумерной карты. Остальное не важно и не нужно. Плюс, по своему опыту написания игр на асме, всегда идет подгонка под массивы с размерностью кратной 2 и умножение/деление кратное 2. Если, к примеру, X нужно умножить на 3, то я пишу на асме X*2+X, а не использую специальную процедуру умножения на произвольное число (умножение на 2 - это всего лишь сдвиг регистра влево на 1 бит).
Игры, где используются числа с плавающей точкой - обычно трехмерные, тут уже без асма не обойтись из-за быстродействия. Да и то, в них не происходит "честное" вычисление функций, а используются заранее вычисленные таблицы. Поэтому ЯВУ тут не нужен.
Записи - не очень нужны. На асме, как правило, разные поля записи в памяти размещаются своими отдельными массивами - так проще вычислять их адрес, чем лазить по целым записям, чтобы отыскать нужное поле.
Многомерные массивы - не нужны. Из-за ограниченной памяти. Трехмерную игру не напишешь на них, для двумерных - они не нужны.
Обработка строк (имеется в виду вырезание, склеивание, поиск, замена) - больше для софта подходит, чем для игр. Может только в каких-нибудь играх с искусственной речью нужны. Можно исключить.
Да не будет уровень технологии на Спектруме расти, и будущего у Спектрума нет. Это ретро-платформа. Максимум технологии по быстродействию и памяти - это программирование на голом ассемблере табличными методами, таблицы подгоняются под удобные адреса, а не под удобную структуру объектов-записей.Цитата:
Сообщение от Oleg N. Cher
Универсальность языка ведет к потере быстродействия и памяти. Для PC это не важно, т.к. там и того, и другого выше крыши. А для Спектрума это существенно. И тут нужно всё подгонять под него.
Повторяю. Люди, которые умеют программировать на ассемблере, будут писать на ассемблере, и даже в качестве "клея" им не понадобится универсальный ЯВУ, проще на ассемблере с макросами. Те, кто не умеет на ассемблере, будут пользоваться универсальным ЯВУ, если он будет намного лучше Бейсика по быстродействию и памяти, если в нем есть библиотека быстрых процедур вывода спрайтов, текстов и прочее. А писать процедуру вывода спрайтов на ЯВУ они не будут - это неработоспособно.
Не пишу и больше не буду. Надоело. PureBasic развратил.Цитата:
Сообщение от Andrew771
Сразу видно игродела. ;)Цитата:
Сообщение от Andrew771
Вообще-то, все с точность до наоборот. Это игры еще как-то можно писать на асме, а вот сложные системы (ОС и утилиты, или тот же TCPIP) гораздо удобнее писать на С, тем паче что на С можно делать большие заимствования (портировать уже готовое) - это очень существенно в условиях когда поднять что-то большое с нуля уже ни у кого из форумчан не хватает потенции. И если говорить за пакет SDCC, то крайне необходима среда разработки на С с нормальным отладчиком (а не убогим SDCDB). Хотя бы как обертка над тем же SDCDB.
То, что вместе со средой разработки на C будут приятные плюшки в виде Оберонов, это только в плюс.
Лол, распальцованным ассемблерщикам пофиг что (X << 1) + X выполняется МЕДЛЕННЕЙ, чем X + X + X? :v2_dizzy_facepalm:Цитата:
Сообщение от Andrew771
sdcc команды умножения очень элегантно заменяет сложениями, проигрыш в производительности будет только если умножать на число чуть меньшее, чем степень двойки, типа 2^n-1. Потому что тут можно обойтись сдвигом и вычитанием, а sdcc все равно генерит сложение.
Error404, и много ты сложных систем на Спек пишешь?
я смотрю для спека все системные программы практически написаны :)
---------- Post added at 11:44 ---------- Previous post was at 11:42 ----------
really?Цитата:
Сообщение от Eltaron
VSКод:ld d,h
ld e,l
add hl,hl
add hl,de
Код: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 ядрами, под которые можно писать только на функциональных языках или на чём-то, что ещё не придумали. Или вообще откажутся от понятия "ядро" и будут программировать на верилоге.Цитата:
Сообщение от Andrew771
alone, да да будущего нет :) доживем до декабря 2012 и посмотрим
Пардон, это же сложение? А я и писал именно про то, что сложения быстрей сдвига. Для байтов - add a,a - 4 такта, sla a - 8 тактов.Цитата:
Сообщение от jerri
Если нет разницы, то зачем платить больше?
вместо sla a лучше rlca.Цитата:
Сообщение от Eltaron
Eltaron, а чем тебе add hl,hl не сдвиг влево? :)
Для именно Спека я не пишу ничего.Цитата:
Сообщение от jerri
Для Ориона пишу и на асме и на С. Большая ли разница в писании под Орион и Спек - вопрос религиозный. Портирование стека TCPIP из исходников на С у меня заняло примерно 40 часов (месяц вечерами). Напишешь ты за 40 часов сетевой стек на ассемблере? Можно не отвечать, вопрос риторический.
С другой стороны, CP/M я правлю на асме, (хотя оригинал был на PL, кстати), и это очень долгий процесс - на асме проще наделать ошибок и сложнее отлаживаться.
Я конечно понимаю, что собственные шишки набивать, заново доказывая в 21 веке то, что уже считалось доказанным в 20м, это очень по спектрумистски, но тут уж давайте определяться: шашечки вам или ехать. Если дороже бесконечный и безрезультативный процесс, то пожалуйста - асм вам в руки. Если надо поиметь что-то реальное на выходе, то наиболее прямой путь - портирование. А с какого языка в код Z80 реально портировать, учитывая что на аcме Z80 ничего что нам хотелось бы, добрый дядя не выложил? Вопрос опять риторический.
ладно, уговорил :) действительно, этот машинный код можно было б и SLA HL назватьЦитата:
Сообщение от jerri
---------- Post added at 15:51 ---------- Previous post was at 15:48 ----------
но там же в случае переполнения ерунда получится, а не умножение?Цитата:
Сообщение от Andrew771
Если a<128, то нормально. Если a>=128, то и при sla a, и при rlca ерунда, т.к. результат уже двухбайтный должен быть (если использовать в ЯВУ).Цитата:
Сообщение от Eltaron
Неа, пользователями этого языка, вероятнее всего, будешь только ты один. Я тут такую привлекательную картинку нарисовал: программь под что угодно на чём угодно, и то подавляющее большинство оппонентов против, а не за. Чего уж сказать про Паскаль. Кроме того, человек, который не знает асма Z80, вероятно, не будет писать игры для Спектрума ни на чём. И я предлагаю знатокам асма не замену асму, а просто способ увеличить собственную производительность там, где это можно без потерь (или с малыми).Цитата:
Сообщение от Andrew771
Андрей, но ведь запись X*2+X это реверанс в сторону тупого компилятора, а запись X*3, которая, кстати, нагляднее для понимания (и проще), но которую умный компилятор может перевести в сложения и сдвиги, что, кстати, SDCC делает. Что подтверждает и Eltaron:Цитата:
Если, к примеру, X нужно умножить на 3, то я пишу на асме X*2+X, а не использую специальную процедуру умножения на произвольное число
Цитата:
Сообщение от Eltaron
Есть такая библиотека KOL, Владимир Кладов написал. Так она уже занимает больше мега исходников. Туда можно очень много добавить. Но программы, которые делаются на этой библиотеке, преимущественно размером < 100 Кб. Это очень реальный даже для Спека размер. Всё дело в подходе, потому как из KOL берётся только то, что используется. Примерно также можно сделать и с универсальностью. Да, у Спека экран устроен иначе, но в некоторых случаях для универсальности этим можно пренебречь. И пренебрегают, отсюда клэшинг атрибутов. Или ч/б вместо цвета. Всё можно продумать и сделать. Но очень трудно найти хотя бы 2 человека, которым на 100% понравятся все твои (или мои) идеи. Проблему я вижу именно в этом. А не в чрезмерной универсальности. Ну вот, спрайты Даша прекрасно себе чёрно-белые на Спеке и цветные под досом. Логика игры этот факт игнорирует, оставляя реализацию графической подсистеме. Разрешение экрана устройства она тоже игнорирует, манипулируя разрешением лабиринта. И так далее.Цитата:
Универсальность языка ведет к потере быстродействия и памяти. Для PC это не важно, т.к. там и того, и другого выше крыши. А для Спектрума это существенно. И тут нужно всё подгонять под него.
Я разве где-то предлагал такое делать? Всякому овощу свой сезон, а всякой задаче свой язык.Цитата:
А писать процедуру вывода спрайтов на ЯВУ они не будут - это неработоспособно.
Ладно, давай искать точки соприкосновения дальше. Ты собираешься реализовывать ReadLn для строк и чисел? Если да, любопытно было бы взглянуть. Я сделал такую процедуру ещё на языке Coloss, и она позволяла редактировать введённое число только полным затиранием и перенабором, сейчас полагаю, это надо исправить. Нервы юзеров дороже. Нужно обязательно реализовать забивку (Backspace), курсор влево-вправо. Ещё есть идея реализовать память для прошлых введённых значений (вдруг новое число проще получить из старого путём изменения одной цифры) по клавишам вверх-вниз (примерно как было в досовской проге Doskey, очень удобно). Функционал буфера прошлых введённых значений можно сделать опциональным (нетрудно придумать задачу, где он не нужен). Согласен или предпочитаешь что-либо попроще (или другое)?
Не вижу смысла сейчас писать что-то под DOS. Можно писать кроссплатформенно под ZX и CPC (Dizzy), ZX и MSX (Ball Quest), ZX и SMD (tfm player).
Когда поговорили о недоязыке, то оказалось что в нём не нужны записи и вещ.числа. А когда говорим о Спеке, оказывается, что это ретроплатформа. Теперь до доса дошли руки. Конечно кроссплатформенность в рамках платформ, юзающих проц Z80, достижима и на асме. А как насчёт кроссплатформенности между ZX, Win32, Linux и Android? Здесь Спек-то как лакмус. Показывает, не слишком ли разраслась идеология, не превратилась ли она уже в PL/1 (или C#). Оберон язык маленький, но делать на нём можно всё: от написания браузеров и ОС под любое железо до разработки веб-сайтов и написания игр для платформ на базе Z80.
кстати, если считать это сдвигом, то sdcc генерит именно сдвиги, и в этом случае претензии к нему вообще не принимаются :)Цитата:
Сообщение от jerri
Код: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
Дык, явно короче.
Кстати, я как-то искал множители, которые выгодно разложить на два умножения, но не нашёл ни одного!
А не выгоднее HL*256/4-HL? :)
---------- Post added at 16:36 ---------- Previous post was at 16:30 ----------
думаю, в играх достаточно только BackSpace. :)Цитата:
Сообщение от Oleg N. Cher
Вряд ли.Цитата:
Сообщение от Andrew771
Ну логика лабиринта - это одно, а вывод клеток лабиринта - другое. Вывод можно встроить отдельной заранее написанной процедурой на асме, а не игнорировать, доверяясь программисту.Цитата:
Сообщение от Oleg N. Cher
Логика лабиринта (кстати, это всего лишь двухмерная карта) тоже может состоять из некоторых стандартных заранее написанных процедур, которые можно встроить: проверка соседних полей с заданным полем на значение, проверка области вокруг заданного поля с заданной глубиной и т.д. (подумать еще надо, что часто встречается).
Andrew771, наверное у тебя есть и задумка игры, которую можно сделать на твоей реализации Паскаля? Расскажи.