В примере две функции, обе с одним параметром: Basic_BORDER, Basic_PAPER. Почему для первой генерится передача параметра в регистре А, а для второй функции - в регистре С? Это такой странный выход транслятора или просто пример "с листа"?
Это, разумеется, сделано для эффективности и компактности машинного кода. Если знаете Си, то вот как именно это реализовано:
Код:#define __hash__ #
#define __id__(x) x
#define __ld_a__(x) if(x==0) {__asm xor a,a __endasm;}else{__asm ld a,__id__(__hash__)x __endasm;}
#define __ld_c__(x) __asm ld c,__id__(__hash__)x __endasm
import void Basic_BORDER_stdcall (SHORTINT color);
#ifndef BORDER_fastcall
#define Basic_BORDER Basic_BORDER_stdcall
#else //BORDER_fastcall
#define Basic_BORDER(color) __ld_a__(color); \
__asm \
call 0x229B \
__endasm;
#endif
import void Basic_PAPER_stdcall (SHORTINT color);
import void Basic_PAPER_fastcall (void /* Register C */);
#ifndef PAPER_fastcall
#define Basic_PAPER Basic_PAPER_stdcall
#else //PAPER_fastcall
#define Basic_PAPER(color) __ld_c__(color); Basic_PAPER_fastcall()
#endif
Приветствую, Олег!
Интеллекта не хватает, твою систему освоить. Поэтому пока балуюсь только гольным sdcc.
Не подскажешь ли, как мне 1) crt0.rel свой сделать, 2) как на выходе бинарные файлы получать вместо ihx?
Та ладно, Сергей, не прибедняйтесь. ;) Не так там уж сложно всё. Впрочем, готов поотвечать на вопросы в аське, ирц, жаббере или на форуме ZX.Oberon2.Ru/Forum, милости прошу, пишите ЛС, если есть охота.
crt0.rel я никогда не делал, даже не баловался. Если честно, я даже не знаю зачем оно надо. ;) Тут нам вместе надо обратиться к гуру SDCC.
Перегнать IHX в BIN можно несколькими способами. ZXDev использует утилиту Hex2bin, скачивается отсюда: http://sourceforge.net/projects/hex2bin. Есть планы сделать утилиту, напрямую конвертирующую IHX в TAP/TZX/TRD (с добавкой произвольного загрузчика). Первая версия уже почти-почти готова (но пока умеет только BIN в TAP, без IHX).
По реквесту AlCo сделал возможность автосборки и запуска Оберон-программ для Спека нажатием F12 (можно переделать на любую другую комбинацию или отдельную клавишу). Сделано несложно, а именно: для модуля Module.odc (или Mod/Module.odc) ищется одноименный файл Obj/Module.bat, всё остальное делает уже сам батник. Проверяет существование откомпилированных модулей (при необходимости перекомпилируя их), вызывает сишный компилер, проверяет не вернул ли он ошибку; если да, то останавливается; если нет, для основного модуля вызываются Hex2bin, bin2trd, далее целевой собранный TRD-шник запускается в эмуле, связанном с расширением .trd. Запускать TRD-шник автоматически при старте умеют не все эмули. Бороться с этим планирую переходом на формат TAP.
Есть ещё варианты как сделать. Например, если одноименного батника для модуля нет, можно запускать в зависимости от выбранной команды один из батников (Bin/compile, Bin/build, Bin/run) на всю подсистему, они-то и будут знать как компилировать, собирать и запускать программы заданным компилером. Ещё вариант: ручной выбор из меню компилятора и целевой платформы, а батники будут лежать в папке bin компилятора. Эти варианты обдумываются.
Прошу прощения, а под х64 будет работать? Пока что посылает лесом, ругается на х64.
Под x64 не тестировалось, но по идее никаких препятствий быть не должно. А как именно ругается?
Вложение 40058
Запускал и в режиме совместимости, результат тот же.
Удалось найти пока только это: http://zx.pk.ru/showthread.php?t=18315 (тот же) и то что во вложении.
Да, проблема на x64 происходит из-за того, что конвертер bin2trd — досовый. Давно хочу от него избавиться. Пока что переделал батники ZXDev/Obj/HelloWorld.bat и ZXDev/Obj/TinyHello.bat чтобы собирать TAP'ы другой утилитой — bin2data. Она умеет вставлять машкод в бейсик-загрузчик после REM (или в виде DATA), поэтому с её использованием есть трудности в случае большой программы и низкого значения RAMTOP (как в LaserDemo). Так что утилита bin2data — временное решение, до тех пор пока не будет готова утилита MakeZX, которая по задумке более универсальна.
Ух ты! Оказывается, утилитка bin2trd (Медноногова) есть собранная и для виндовз. Честное слово, не знал.
Сгенеренный ею TRD попробовал открыть в Spectaculator, вроде всё ок, и вот эта проблема не проявилась. Надо тестировать в других эмуляторах. Но в любом случае пока что ничего более подходящего на эту тему мне не попадалось. Зато есть исходник, если что-то придётся править. Спасибо, Влад! Спасибо также за эту адаптацию Александру Шабаршину.
Обновил trd2bin, поправил скрипт для сборки LaserDemo. Теперь должно работать в x64.
---------- Post added at 02:21 ---------- Previous post was at 02:14 ----------
P.S. Обнаружил, что эта версия trd2bin все буквы имени целевого TRD-шника делает строчными и устанавливает для целевого файла атрибут только для чтения.
Подготовил примерчик, показывающий как работать с беззнаковыми числами.
Проблемы всё ещё есть, например, импортированные из других модулей (кроме SYSTEM) беззнаковые типы и переменные считаются знаковыми. Решать их предлагаю по мере необходимости в данном подходе. Мне важно показать, что всё, что понадобится, в технологию XDev/ZXDev можно добавить, причём не только библиотеки, но даже новые языковые конструкции, и сделать это достаточно легко.
Теперь на очереди, видимо, подсветка синтаксиса и препроцессор?
Ну что ж, раз все молчат — значит вопрос о раскраске синтаксиса неактуален. Тем более, такие вещи решаются в среде BlackBox Component Builder с помощью сторонних компонентов. Я знаю минимум парочку. Больше информации есть в этой теме:
Сборка BlackBox-XDev для кросс- и embedded разработки
Также обращаю ваше внимание на то, что BlackBox (и вследствие этого — XDev) обладает подходом к оформлению текстов программ, недоступным для традиционного и повсеместно используемого текстового формата с раскрашенным по шаблону синтаксисом. Например, можно внедрять в качестве комментариев к исходникам рисунки (что в ряде случаев не просто удобно, а вообще незаменимо), расширенные возможности фолдинга, позволяющие, в частности, иметь несколько вариантов исходного текста и удобно переключаться между ними. Разумеется, такой нетекстовый формат представления исходников имеет проблемы с системами контроля версий, заточенными под текст, но, надеюсь, это временная трудность, которая будет решена, ибо развитие программерского подхода должно вестись и в направлении изучения преимуществ нетекстового представления исходников, а традиция текстового представления, сложившаяся в умах программистов, на этом пути является тормозом эволюции.
Пока проблемы с контролем версий решаю дублированием нетекстового исходника его текстовым представлением. Не очень красиво, но мириться можно. Процесс взаимодействия с системами контроля версий конечно хотелось бы автоматизировать, но надо решить проблему автоматического слияния нетекстовых исходников, а это нетривиально.
Вот ещё одна полезная и уникальная возможность. Я дорабатываю транслятор Ofront, который ещё раньше портировался автором с Oberon-2 на Component Pascal. Часть кода осталась исходной на Обероне-2, и такой код в исходнике имеет чёрный цвет; изменения, коснувшиеся перевода на КП, обозначены красным; а свои изменения я отмечаю синим цветом. Это позволяет быстрее ориентироваться в исходниках и не путаться, имея чёткий критерий, что именно менял сам. Такой подход используется и в BlackBox (В свете этого появляется весомое преимущество задания ключевых слов в Обероне заглавными буквами, выделяющими структуру и отчасти снимающими необходимость в раскраске синтаксиса).
Темы, которые также могут быть интересны ZX-кодерам:
Как я пришёл к Оберону. Зачем его использую. Есть ли у него преимущества
О трансляции Оберона в Си (И зачем писать на Обероне, если есть Си?)
Обероны и кроссплатформенность
Среда XDev: с чего начать?
Будни разработки XDev
На Java для ZX (Java для Z80)
Как создать новую библиотеку для ZXDev
Порт графической библиотеки Graph (из Turbo Pascal) под ZXDev
Все адекватные люди от бинарных форматов уходят, яркий пример MS Office
Мягко говоря - это спорное утверждение, я за то чтобы исходники оставить в текстовом виде - конкретно в чистом unicode. Внедрять же в исходники картинки можно разными путями, самый простой - представлять двоичные объекты в исходниках программ кодированными в текст, способов же это сделать много, но есть еще более удобный путь - самодокументирование со вставками в исходники сцециальных комментариев или макросов со ссылками на двоичные файлы, по которым умные сборщики, умеют сами генерить красивую с картинками документацию, в том числе с подтянутыми картинками по ранее заложенным в комментариях или макросах в исходники программ ссылкам на них.
Мало ли Вы за что. Программинг шагает вообще от представления программы в виде текста к набору различными путями визуализированных принятых решений и свойств программы.
Может быть здесь прозвучат адекватные достоинства текстового представления перед нетекстовым? (не имеется в виду бинарным; это мелочи, как именно это реализовано; имеется в виду использование различных средств, повышающих графическую наглядность программы, удобство настройки путём модификации её свойств и т.п. Рано или поздно рамки текстового формата скажут "нет", и придётся их отбросить).
perestoronin, что ж Вы не прокомментировали перечисленные выше полезные возможности, которых Вы лишены при работе на чисто текстовом представлении?
Но, впрочем, спорить я не буду, программьте на чём привыкли. Или на чём заставляют гиганты индустрии.
Не надо путать представление программы и контейнер для хранения артефактов разработки этой программы.
Все вышеуказанное прекрасно можно хранить в текстовом xml-based формате. Который можно и редактировать вручную при необходимости и четко видеть изменения в системе контроля версий.
Oleg N. Cher, так что есть нетекстовое представление-то?
psb, в основном я под этим понимаю расширяемый формат составных документов каркаса BlackBox Component Builder и всю массу управляющих элементов, которые можно на нём разработать плюс инструменты по визуализации и редактированию (кнопки, строки ввода команд, визуальные мини-редакторы свойств и форм), которые легко встроить в компонентную среду на базе этого каркаса, гораздо легче, чем вцепиться намертво в текстовое представление и городить текст, а потом поверх него различные xml-файлы форм, свойств проекта, мейк-файлы и прочея.
Конечно можно иметь исходник в тексте и рядом с ним текстовый же xml, который будет расписывать где в каком месте этого исходника какой цвет и где вставлена картинка, но — упс — подредактировали чуток текст и всё рассыпалось. Зачем же так изголяться? Не для редактирования ли мы с этим xml мирились? Только для какого редактирования? А почему нельзя редактировать двоичный файл? Религиозная привязанность к любимому Notepad'у? Не лучше ли адаптировать системы контроля версий в контексте наших задач и использовать более компактный и универсальнее, чем xml, двоичный формат?
В BlackBox есть конвертеры из и в текстовое представление (html, rtf, txt и т.д.), так что совместимость по исходникам (и для контроля версий) остаётся, никуда мы от неё не убежим.
Vitamin, теги — не для чтения. Это компромисс между человеческим и машинным, подход, который имеет ограниченную применимость. Также для меня уродливо выглядит попытка насадить весь мир на xml для чего надо и в особенности для чего не надо.
Посмотрите, господа, вы в одних случаях "за" текстовый вид (например, в xml, где оно в ряде случаев чревато ошибками, громоздко, времяёмко по распарсиванию, да и требует больших объёмов памяти), а вот промежуточное представление для трансляции Оберон-программ в виде текста на языке Си — смущает. Что не так? Хотите чтобы вся музыка и графика тоже хранилась в xml, а не в mp3, jpg и png? :) Ну может со временем так и будет, если адекватные дяди из майкрософт постараются. Когда-то майкрософт удивлялся плоским html и считал их неэффективными, использовал двоичные .doc и .xls форматы. А теперь сажает на xml весь мир. Не надоело хавать всё, что суют под нос?
Господа, понятно, что расширенные возможности форматирования текстов программ могут понадобиться не всем из вас, и я, разумеется, собираюсь поддержать простой plain текст в виде UTF-8, например, и с раскраской синтаксиса, когда-нибудь. Я не ставлю цель угодить всем. А то некоторым здесь больше нравится придираться к моим формулировкам и затеять священную войну за "а мне так больше ндравица", чем аргументированно доказывать свою точку зрения, или, не дай бог, увидеть преимущества чего-то выходящего за рамки привычного и поучаствовать в его развитии.
Возражения не сколько против бинарности формата (тот же BXML вполне себе существует), сколько против очередного самописного велосипеда с крайне туманными перспективами по устойчивости, сопровождаемости и расширяемости. И невозможность посмотреть текстовый документ без кучи всяких спецпрограмм.
Как раз потому что бинарные доки парсить- это ужоснах, потому и переехали на более многословный, но гибкий и расширяемый xml.
psb, пример — сама среда BlackBox Component Builder. Она в одном своём внутреннем формате сочетает то, на что в других случаях используется много форматов. Вы открываете Word и сохраняете документ в docx, открываете Си-редактор и сохраняете в текст, открываете в браузере HTML, но чтобы сохранить сразу всю страницу, Вам нужен уже веб-архив chm или mht. BB предлагает для всего этого один расширяемый формат .odc (Oberon DoCument). И для гиперпереходов, и для исходников, и для форматированных документов с динамическими картинками. Это универсализация подхода к документам вообще. А поглядеть можно... ну, например, посмотрите как изящно в тексты встраиваются коммандеры (аналог кнопки-командной строки), можно разработать подобные же, но другие по функционалу элементы управления.
Если неохота вникать в среду BlackBox, читать доки, пробовать (давно штудировали VisualStudio с многотонным талмудом в руках?). Если пипл не понимает и не хочет понимать преимуществ форматируемых элементов в исходниках (например, подчеркнуть важный фрагмент кода, а сверхважный выделить красным жирным; не до конца отлаженное пометить курсивом, а временный код бледным серым),
тут я пас.
psb, он о маразме BB, там можно к примеру гифку анимированую или кнопку вставить в исходник, и что там как в RTF можно текст раскрашивать
- Итак, у нас есть 50 разных контейнеров для хранения текстовой информации, каждый со своими плюсами и минусами.
- Какой ужас! Надо что-то с этим делать! Надо придумать контейнер, заменяющий всю эту свору!
...
- Итак, у нас есть 51 разный контейнер для хранения текстовой информации...
я кстати согласен, что иметь возможность делать пометки "на полях" у кода (т.е. то, что не войдет в сам исходник, но будет с ним связано), вести какие-то обсуждения, и возможно даже выделять код цветом (такое было, кстати, в шторме) - иногда было бы интересно. как и расшаривание редактирования кода в ide между участниками. это все хорошо.
но вот в какой-то единый формат для хранения всего этого что-то слабо верю. точнее, вообще не верю. контейнеров плодить можно до бесконечности, но это лишь контейнеры.
п.с. кто-то пытался сравнивать разные ревизии опенофисовских документов (текстовые xml, ага)? успешно (в смысле, все ли понятно)?
1. Можно смотреть и/или править код программы на компьютера без IDE.
2. Можно сравнивать версии кода при помощи текстовых компарилок типа WinMerge.
3. Возможность использовать для компиляции программы любые сторонныие компиляторы, поддерживающие синтаксис языка.
4. Распространенные системы контроля версий поддерживают слияние кода только в текстовом формате.
Хватит?
На самом деле, выделение разных участков кода разными стилями - это хорошая возможночть, которой мне не хватает в той же Visual Studio. Но цена бинарного подхода очень высока. Олсо костыли в виде вспомогательных файликов рядом некошерны.
Как сопоставить высказывание Vitamin'а об ужасности парсенья бинарных файлов и существовании вполне себе бинарного формата BXML? Я не против этого формата. Но не соотношу его с текстовым XML. Токенизированный двоичный BXML в моих глазах приобретает перед текстовым xml важное преимущество — работать с ним должна только машинная программа, а не человеческое восприятие. Я против ручного редактирования больших массивов текста в перемешку с тегами. Это больше приличествует маньяку, чем похоже на комфортную работу в визуальном средстве разработки. А то, знаете, есть такая штука ant (кто юзает яву, тот в курсе), большим недостатком которого на мой вгзляд является xml-представление командного файла. Приходится много ручками редактировать. Не, ну может кому-то и нравится. А мне это настолько давит на мозг, что уж лучше бы там были плоские текстовые команды с параметрами, но без всяких тегов.
Чем же так принципиально трудно парсить бинарные форматы? Может парсилка кривая? Я исхожу из того, что любое текстовое представление ASCII (или UTF) — это подмножество бинарного представления, но не наоборот; соответственно, потенциал бинарей выше. Нет, Vitamin прав в том, что если сломается корявый софт и придётся отскребать мозги от асфальта, то тут да, сломанные бинарные форматы отдыхают, а xml безусловно вне конкуренции.
ЗАЧЕМ?
Можно программить на компе без Visual Studio, в debug.exe. Или на ZX без асма, прям в хекс дампе.
Как-нить откройте в BlackBox два документа и нажмите F9.Цитата:
2. Можно сравнивать версии кода при помощи текстовых компарилок типа WinMerge.
А почему Вы решили, что сейчас в XDev это нельзя? По-моему, я так и вызываю SDCC. :)Цитата:
3. Возможность использовать для компиляции программы любые сторонныие компиляторы, поддерживающие синтаксис языка.
Решаемо. Было бы желание решать. Как сказал умный человек: кто хочет сделать, тот ищет возможности, а кто не хочет — ищет отмазки.Цитата:
4. Распространенные системы контроля версий поддерживают слияние кода только в текстовом формате.
Так Вы бы попробовали. ;) Нету там никаких воспомогательных файликов, только одни .odcЦитата:
На самом деле, выделение разных участков кода разными стилями - это хорошая возможночть, которой мне не хватает в той же Visual Studio. Но цена бинарного подхода очень высока. Олсо костыли в виде вспомогательных файликов рядом некошерны.
---------- Post added at 15:00 ---------- Previous post was at 14:55 ----------
Это называется костыль. Придуманный, чтобы заткнуть недостатки принятого решения в виде текстового хранения исходников.
Но, впрочем, пусть будут оба подхода, раз они востребованы.
Для чего тогда изобретается новый? Или я что-то путаю, и .odc является каким-то стандартным контейнером бинарных данных (bxml/ogg/zip etc)?
А ЗАЧЕМ такие крайности- "программируй либо в IDE со всеми наворотами или прямо в отладчике по-джедайски"? Во имя чего отрезать принципиальную возможность редактировать в любимом vim/notepad/etc?
Всего один вопрос- как?
Откладывание таких вопросов "на потом" - еще один гвоздь в крышку гроба хорошего начинания.
Что именно "костыль"? Система ревью кода?
А зачем мне ставить IDE и настраивать (!) ее на тестовый комп только чтобы поглядеть исходники?
А кто говорить про "программировать без IDE"? Я про посмотреть / пофиксить мелкий баг. А если я хочу на телефоне посмотреть реализацию и быстро прояснить кому-то как-йто момент работы кода? На Спектруме это можно сделать из STS, да или через POKE просто. В виду наличия эмуляторов с отладчиками мало нужно. Бесплатный легкий (относительно) компилятор csc.exe позволяет пересобрать сборку из чуть поправленных в блокноте исходников на C#. ЕМНИП, ASP.NET страницы вообще можно править "на лету", без остановки Web-сервера. В общем, не убедительно.
1. Я люблю WinMerge.
2. см. п.1 мне опять нужна IDE для этого.
Для компиляции текстового C-исходника в asm? Или SDCC теперь знает ваш хитрый бинарный формат и генерит бинарь прямо их Оберона? А если я хочу написать свой компилятор вашего бинарного текста, мне, о ужос, надо еще и парсер формата написать? Или уповать на чей-то готовый?
То есть, либо бинарный текст для компиляции/сравнения/слияния преобразуется в plain text, а потом, при необходимости, обратно, либо для поддержки этих действий тул для каждой из них надо снабжать парсером бинарного формата, что отбивает сторонние разработки.
Это средство отделения информации об анализе кода от самого кода. Ибо тулам для обработки и хранения кода эта информация совсем не нужна. А хранить ее в исходном коде накладно.
Я, например, активно использую поиск по файлам. Просто потому, что мне не нравится, как оно медленно в VS работает, и как неудобно по результатам перемещаться. И ни в одной IDE, что я видел, удобно не реализовано.
А если мне надо сделать какую-то хитрую операцию? BlackBox умеет, скажем, многострочные регэкспы применять ко всем файлам проекта?
А с кодогенерацией как? Писать свой сериализатор?
Бинарные форматы - это самое большое зло на свете. Для обработки текста существует слишком обширный удобный инструментарий (grep, sed, awk, perl, wc, tr etc), чтобы отказываться от него ради картинок в тексте. Код надо писать так, чтоб и обычных-то комментариев требовалось минимум, а уж картинок и подавно.
не попадают, а рядом лежат? или не лежат? и мне не столько бы для ревью этого бы хотелось, сколько для истории. сейчас, например, есть репа с проектом и багтрекер. в багтрекере куча полезной инфы, но она же в другом месте. и когда-то она потеряется, и кому-то потом будет неизвестно, а почему сделали именно так, останется только номер тикета, которого нет.
п.с. заточка на одну единственную среду (типа, делайте все только в нашей крутой ide) - не взлетит, имхо.
А если сервер с системой контроля версий (не распределенной) подохнет, то потеряется вся история и комментарии к коммитам. А еще база данных, заполненная нужными данными, в том числе с таблицами-словарями, может потеряться. Но это всё не повод терабайтную помойку в VCS устраивать, достаточно просто делать бэкапы :)
Если IDE эта — Visual Studio, то метания понятны. Это одоробло только ставится полчаса. А ББ в полной поставке весит 5 метров и умеет работать с флешки. На остальное отвечу позже, но хочу заметить, что в XDev будет оба подхода — возможность сохранять исходники как в .odc, так и в текстовом виде со стандартной раскраской (это уже сейчас можно сделать с помощью подсистемы Мастер, если не лениться, правда, я её не тестировал под ядром 1.6). В ББ уже сейчас возможно сохранять как .odc, так и html/rtf/txt, а с помощью доп. модуля и в юникод/UTF. Все вы умнейшие ребята, но возможностей ББ не знаете даже и приблизительно, поэтому и критикуете не саму её, а своё мнение о ней.
Я, если честно, ожидал не споров по поводу текст vs не-текст, а конкретных предложений помочь с библиотеками для ZXDev. Но если это выше ваших сил, тогда ладно, сам буду помаленьку делать.
Я не имею возможности критиковать/одобрять систему потому что вот на этом форуме так и не увидел ссылку чтобы скачать это, поставить по инструкции и собрать Hello, world. Приходится основываться только на словах популяризатора. У меня пока скорее смутные представления о том, что надо найти и выкачать 100500 компонентов, поредактировать 25 ini'шников, выставить сотни опций, и только тогда будет мне посмотреть. Вот например даже на пример. Сылка в начале дискуссии про новую сборку ведет на форум, на котором ссылки на setup.exe тоже нет (или не нашел).
Не надо судить о том, что тут выше наших сил. Я вот не могу носок связать потому что не умею. Потому что не интересно. А бабушка моя умеет. Однако бабушка не тыкает в меня тем, что ее умения выше моих сил.