А вообще, препроцессор С в руках программеров-извращенцев это страшное зло. Например, я весь исплевался портируя uIP оттого, что автор науевертил там такого на макросах, что многие компилеры распутать не могут (не говоря уже о понимании всего этого людями), и соответственно либо не собирают либо собирают абы что, от чего при отладке приходишь в совершенное изумление.
Последний раз редактировалось GriV; 16.03.2012 в 13:50.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Друзья мои!
Большая просьба!
Если вы не хотите использовать оберон и любые его проявления в своём будущем, то не пишите в этой теме вообще. Не оставляйте глупых постов, которые я устаю удалять, пожалейте своё и, если вам не жаль своего, то, хотя бы, моё время.
Если же у вас есть личные мотивы по отношению к автору - решите этот (или эти) вопрос(-ы) в личке, в аське или каким-либо другим способом, благо его контакты (автора темы) совсем не спрятаны.
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 не заметил давно ещё неделек 2-3 назад выложенный снап Даша, но негатив свой высказать поторопился. Ну разве ж я в этом виноват.
Последний раз редактировалось Oleg N. Cher; 25.03.2012 в 17:25.
Oleg N. Cher, не будь снобомя не сижу на твоем сайте с нетерпением ожидая когда ты на нем что-нибудь выложишь.
Для информирования заинтересованных существует лента новостей.
Негатив я высказываю когда получаю ответы на вопросы которых не задавал.
Практику правки старых постов считаю порочной
качество и размер сделанного с помощью sdcc оценил и мне оно в целом не нравится. после оценки готового продукта мое присутствие здесь больше не требуется и отвечаю я тебе только если ты меня призываешь.
С уважением,
Jerri / Red Triangle.
Отлично. Только видишь, все начитались книжек о неимоверной крутости языков Си, Си# и Java, поэтому даже разговор об их недостатках или отсутствии чего-либо в них считается кощунственным, а многих теперь даже от самого слова "Паскаль" воротит. Попробуй тут всех заставь уважать достоинства Паскаля.Да, вопрос серьёзный, что и как назвать. Может даже имя Оберон и не самое удачное в плане маркетинга.
С первым трудно не согласиться, а вот со вторым можно поспорить. Да и входные форматы разных кроссассемблеров весьма различаются.Лучше делать кросс-компилятор с 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, не будьте кисейной барышней, мне от Вас ничего конкретно не нужно, просто защищаю свою идеологию и авторитет. Для тех, кто будет читать ветку и находить достоинства в высказанных мною идеях.
Последний раз редактировалось Oleg N. Cher; 25.03.2012 в 22:56.
В этом месте выпал в осадок. Это что, действительно правда? Такого не делали даже 8-битные CP/M-овские компиляторы тридцатилетней давности.
Или я не правильно понял. Давайте уточним: терминология "библиотека" подразумевает именно библиотеку или все же модуль, в нее входящий (который уже в свою очередь состоит из процедур). Компоновать с кратностью до модуля - это нормально (не нравится - собираешь каждую процедуру в отдельный модуль), но с кратностью до библиотечного файла - это дикий трэш и угар.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
jerri, Вы подходите к SDCC как потребитель, а не как энтузиаст. (Чего я могу сегодня поиметь с ЭТОГО, ничего не вкладывая в ЭТО?). Подобным образом Вы подходите и к ZXDev. Я же призываю не рассматривать ни SDCC, ни ZXDev как нечто статичное и закостенелое, а как хорошее начало для достойного продолжения.
Error404, вообще-то на самом деле я просто убрал внутри Basic.c тела нескольких процедур, превратив их в пустые. И размер хеловорлда стал на несколько сотен байт меньше. Проверьте. Остальное выясним методом практики.
Под библиотекой понимаю "модуль", который скомпилен в lib, и мы юзаем процедуры, вызывая их оттуда. Но такая же лабуда наблюдается и без использования lib. Неиспользуемые процедуры SDCC всё равно вставляет в программу.
Так что подтверждаю: хеловорлд в несколько десятков байт на Обероне для Спектрума ВОЗМОЖЕН.
Пока мир. Читаю тему пассивно. Большого интереса не вижу, но и угнетать разработку своими мыслями не хочу. При налчии свободного времени занимаюсь своими проектами. В интересных для меня конструктивных дискуссиях возможно буду принимать участие на стороне себя. Ибо все для удовольствия.
P.S. Еще меньше серчать буду, если мой ник в цитатах и обращениях будет писаться правильно.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
