Просмотр полной версии : Компилятор языка Паскаль - планы на будущее
Я попробую описать что есть и что будет в компиляторе, а вы допишите на что ещё обратить внимание, может что важное забыл.
Типы данных: 7 целых (byte, word, int64...), boolean, pointer, char, string.
Допускаются array, record и pointer в любых комбинациях: массив указателей на структуры, внутри которых указатели на массивы байтов, и т.п. Массивы пока только одномерные, но можно описать массив массивов.
Переменные: любого типа (см. выше), глобальные/локальные, допускается absolute.
Константы тоже будут, но с ними пока затруднения.
Подпрограммы (процедуры, функции): до 10 параметров любого типа, параметры передаются по значению и по ссылке (var). Почти работают полиморфные подпрограммы и override.
Выражения и операторы в них: + - * / > < >= <= = <> div mod and or xor shl shr @ ^ :=
А также скобки, приоритеты операций, явное преобразование типов. Сложность выражений ограничена объёмом памяти при компиляции и при работе.
Ветвления, циклы: if, while, repeat. Цикл for пока только в одну сторону (инкремент).
Cейчас работаю над кодогенератором. Выдаёт более-менее осмысленный, но абсолютно неработоспособный код.
Планы на будущее:
- директивы условной компиляции $define, $ifdef и прочие (ничего сложного, надо заняться реализацией);
- переопределение арифметических операторов;
- числа с плавающей точкой;
- файловые типы данных;
- множества, оператор in;
- оператор case (пока вообще нет идей как это реализовать);
- модули (unit, uses, interface, implementation...);
- динамическое распределение памяти (new, getmem...);
- умная линковка;
- inline-подпрограммы;
- запуск компилятора на платформе с 16-битной адресацией (Z80, собственный процессор...) и диском (FDD, HDD, flash...).
Viktor2312
22.02.2015, 03:02
По поводу компиляторов, книжечку какую нибудь не подскажите, сам сейчас читаю: Хантер. Проектирование и конструирование компиляторов. Но не серьёзно читаю, а так для общего развития.
Сколько памяти требует компилятор? Работает под TR-DOS? Какие промежуточные файлы создаёт? Есть ли встроенный редактор(интегрированная среда)? Обрабатывает-ли русские комментарии и/или русские строки? Или это вообще кросс-компилятор под Windos-у?
denpopov
22.02.2015, 08:50
Кажется, Andrew771 выкладывал компилятор Паскаль?
или грядет вновь изобретенный Оберон велосипед?
---------- Post added at 08:50 ---------- Previous post was at 08:49 ----------
Типы данных: 7 целых (byte, word, int64...), boolean, pointer, char, string
множество (set) не помешало б.
Кажется, Andrew771 выкладывал компилятор Паскаль?
или грядет вновь изобретенный Оберон велосипед?
множество (set) не помешало б.
Множества и оператор in указаны в списке "планы на будущее". Мне они тоже нужны.
С Andrew771 у нас совершенно разные цели. Он пишет компилятор под конкретную платформу, мне же нужен универсальный (кросс-)компилятор Паскаля, поддерживающий 8-битные микропроцессоры и микроконтроллеры. Да, в какой-то степени это велосипед, но компиляторы, в которых нельзя, например, получить указатель на элемент массива, или поддерживающие указатели только на базовые типы, меня категорически не устраивают.
Сколько памяти требует компилятор? Работает под TR-DOS? Какие промежуточные файлы создаёт? Есть ли встроенный редактор(интегрированная среда)? Обрабатывает-ли русские комментарии и/или русские строки? Или это вообще кросс-компилятор под Windos-у?
Пока это кросс-компилятор, памяти требует много, но в идеале он мне нужен запускающимся на 64k. Работа под TR-DOS - я пока не совсем понимаю работу в ней с временными файлами, а они в этом случае будут. Сейчас, при работе под Windows/Linux, всё держит в памяти, временных файлов не создаёт, кроме выходного файла на языке ассемблера (требуется внешний ассемблер).
Интегрированной среды нет, это именно консольный компилятор.
Русские комментарии обрабатывает. Русские строки - да, если символы однобайтные. Скорее всего будет встроена перекодировка для WH1602 и подобных.
---------- Post added at 10:45 ---------- Previous post was at 10:34 ----------
По поводу компиляторов, книжечку какую нибудь не подскажите,
Ссылку на хорошую подборку с уклоном в Оберон давал Oleg N. Cher.
Andrew771
24.02.2015, 00:26
Я в своем компиле уже перешел на стадию написания оптимизации. Сейчас выдает полностью работоспособный код, поддерживает все заявленные мною операторы и типы, библиотека встроенных процедур полностью написана. Но код не оптимизирован.
Книгу рекомендую Н.Вирт "Построение компиляторов", по ней писал в основном,всё понятно изложено. Даж бумажную себе купил, в электричке и сортире читать. :)
В принципе, я уже пошел дальше книги, компиль выдает не сразу код Спека, как рекомендовано Виртом, а промежуточный псевдокод, который легче оптимизировать. Собстно, из него можно генерить потом код не только Спека, но и любой машины.
Цикл for пока только в одну сторону (инкремент).
Ну ежели пишешь универсально, то декремент легко вставить сразу.
Константы тоже будут, но с ними пока затруднения.
туда же. Константы я запихивал в таблицу переменных, но под своим типом.
Cейчас работаю над кодогенератором. Выдаёт более-менее осмысленный, но абсолютно неработоспособный код.
это как?
У псевдокода тоже есть свои недостатки. Попробуй добавить в кодогенератор второй, третий процессор - сразу станет ясно что не так в архитектуре компилятора. Кроме множества поддерживаемых процессоров сейчас также вырисовываются варианты компилятора для запуска на "больших" и на "маленьких" платформах.
Думаю, надо найти какой-то компромисс между вариантами генерации кода. Это как раз то, про что не напишут в книгах - конкретная реализация, которую выбрал автор. Поэтому могу сказать, что этап чтения книг я уже прошёл.
Почему код "осмысленный, но неработоспособный"? В кодогенераторе много заглушек. Структура получаемого кода в целом видна, но, например, размер и смещение переменных не учитывается.
Viktor2312
24.02.2015, 09:48
Книгу рекомендую Н.Вирт "Построение компиляторов", по ней писал в основном,всё понятно изложено. Даж бумажную себе купил, в электричке и сортире читать.
Спасибо, уже скачал, почитаю на досуге
Вирт Н. Построение компиляторов 2010г. Скачать (https://yadi.sk/d/ExJElI0werTPw)
Bolt, а может не изобретать велосипед, а попробовать далее развить Turbo Pascal? Добавить в него типы данных которых нет и которые нужны, функций, операторов и всё что надо? Может даже автоматическую работу с многостраничным ОЗУ? Исходники (декомпилированные) версии 3 под ЦПМ имеются. Мне вот, пока хватило бы добавить тип LongInt беззнаковый и беззнаковый int, но с теорией компиляции не знаком и в исходнике почти ничего не понимаю.
denpopov
24.02.2015, 13:16
а попробовать далее развить Turbo Pascal?
интрено, в какую развить? в сторону Борман Дельфи?
Vadim, я когда начал писать компилятор тоже с теорией компиляции не был знаком. Была мысль прикрутить к FPC нужный кодогенератор, но FPC со стороны исходников мне не очень понравился. Я решил пойти по пути написания компилятора с нуля.
Доработать Turbo Pascal под CP/M? А толку? Даже если разобраться в декомпилированных исходниках и умудриться доработать, то это так и останется компилятор, "прибитый гвоздями" к конкретному процессору и ОС.
Andrew771
25.02.2015, 12:50
У псевдокода тоже есть свои недостатки. Попробуй добавить в кодогенератор второй, третий процессор - сразу станет ясно что не так в архитектуре компилятора.
псевдокод в данном случае - это не замена ассемблерных команд один-в-один, а каждая команда псевдокода может содержать несколько ассемблерных команд. Т.е. по сути каждая команда псевдокода описывает элементарное действие (запомнить, сложить, делить и т.д.), которое может состоять из нескольких ассемблерных команд.
Вот например, нужно компильнуть: a:=4+(2+3).
При просмотре исходника преобразуем в команды:
_LoadConst 4 -
_Push - -
_LoadConst 2 -
_Push - -
_LoadConst 3 -
_PopAdd - -
_PopAdd - -
_StoreByte 0 _A
Каждая команда содержит мнемонику, а также один числовой и один строковый параметры (прочерк '-' означает отсутствие значения).
_LoadConst на коде Асма будет ld hl,const
_Push - push hl. Приходится вталкивать в стек каждое значение, иначе заранее неизвестно, что мы с ним будем делать дальше.
_PopAdd - это в реале две команды pop de и add hl,de.
_StoreByte - это запись hl в один байт, т.е. ld a,l и ld(_A),a
Реальный код:
ld hl,4
push hl
ld hl,2
push hl
ld hl,3
pop de
add hl,de
pop de
add hl,de
ld a,l
ld (_A),a
Теперь, чтобы его оптимизировать, не нужно проводить глубокий анализ всех push-pop и прочего, а только смотрим последовательные комбинации команд и сравниваем с заданными шаблонами оптимизатора. Например, имеется шаблон - последовательность _Push, _LoadConst, _PopAdd заменить на _LoadConst2Add.
_LoadConst2Add состоит из двух команд: ld de,const и add hl,de
_LoadConst 4 -
_Push - -
_LoadConst 2 -
_LoadConst2Add 3 -
_PopAdd - -
_StoreByte 0 _A
Тогда будет:
ld hl,4
push hl
ld hl,2
ld de,3
add hl,de
pop de
add hl,de
ld a,l
ld (_A),a
Как-то так. Команды и шаблоны я сам придумываю в своем компиле :)
Да, всё верно. Но у нас всё-таки разные компиляторы и подход к их написанию. Потом будет интересно сравнить результат.
батл компиляторов?))))))))))))
Andrew771
26.02.2015, 12:49
батл компиляторов?))))))))))))
ага. Oleg N.Cher пока выигрывает, у него уже готов! :)
Oleg N. Cher
27.02.2015, 22:23
Снимаем с соревнований. Во-первых потому что это всё-таки не Паскаль, во-вторых потому что там всю работу делают Ofront и SDCC. А развивается ли Z80-кодогенератор SDCC? Определённо да. Недавно обновил до нового снапшота, компактнее код генерит. На удивление стабильно собрал несколько сложных прог. Нужно не лениться репортить ошибки, их таки исправляют и продукт становится лучше.
AlCo предлагает разработать Оберон-компилятор чтобы работал на самом Спеке, я пока отбрыкиваюсь, вроде странная задачка.
Alex Rider
28.02.2015, 00:20
AlCo предлагает разработать Оберон-компилятор чтобы работал на самом Спеке, я пока отбрыкиваюсь, вроде странная задачка.
Воистину странная - адекватоной IDE нет на Спеке.
Oleg N. Cher
02.03.2015, 01:48
Воистину странная - адекватоной IDE нет на Спеке.Странная идея - пытаться юзать Спек как полноценную хост-платформу для разработки в качестве IDE. А то ведь, как я думаю, этому мешают объективные факторы - низкое разрешение экрана, слабенький проц и мало памяти. Даже если взять во внимание клоны, то и тогда вопрос использования именно Z80-based машины не имеет преимуществ, помимо нерациональной привязанности к системе команд этого проца aka тёплых домашних воспоминаний. Или это для истинных мазохистов ценителей?
Кто-то называет выбранный мною подход трансляции Оберона в Си читерским, но я не верю в разработку кодогенератора приемлемого качества одной персоной на голом энтузиазме за разумный срок. Также не верю и в то, что две персоны согласуют взгляды на разработку до каких-то общих целей. Так что это раз. Два - желание хорошо отделить фронт-энд от бэк-энда. Вроде бы мне это удалось. Переписывать под Z80 - странная идея. Топтаться на месте много лет. Кому-то нравится? Удачи.
Ссылку на хорошую подборку с уклоном в Оберон давал Oleg N. Cher.Вот ещё кое-что интересное на тему языков и трансляции, я весьма советую:
• Правильные книги по теории и обзору языков программирования (http://forum.oberoncore.ru/viewtopic.php?f=75&t=1090)
Кто-то называет выбранный мною подход трансляции Оберона в Си читерским, но я не верю в разработку кодогенератора приемлемого качества одной персоной на голом энтузиазме за разумный срок.
Подход не читерский, подход позволяет достичь поставленную цель - компиляция под заданную платформу - за разумный срок. У меня цель - сборка под разные платформы, не используя Си в любом виде.
Можно пояснить что понимается под приемлемым качеством кодогенератора?
У меня цель - сборка под разные платформы, ...
Как по мне дак самое главное в этом магическом "разные платформы" именно адресуемое пространство, сегодня 99.999% литературы по алгоритмам предпологают бесконечное адресное пространство, а это значит что для запуска их нужен процессор у которого отсутствует лимит адресов (такого процессора нету, но наблюдается тенденция увеличения битности адреса в процессорах по мере возрастания размера обрабатываемых данных).
Короче, отвечая в лоб, если хочется чтобы твой компилер был одинаковый для всех, то сначала уровняй всех. Например напиши для всех 1 виртуальную машину, и компилер пиши для этой машины. Ну и тут вопрос скорости, он вторичный в плане теории, но первичный на практике, так как мы уже видели и запуск ARM linux на avr 8bit и запуск x86 windows3.0 на mcs-51, но тормоза свели эти проекты в область чисто академического интереса.
Отсюда вопрос - не пагубна ли сама идея: "сборка под разные платформы"? смысла практического ведь НЕТУ? Но вот под конкретную платформу сделать хороший инструмент, нужный людям! куда как более востребованное занятие, не зря народ жаждит update-a borland pascal под cp/m
Kakos_nonos
12.03.2015, 18:33
запуск x86 windows3.0 на mcs-51
Можно по-подробнее про это? Стало интересно.
JFYI
дизассемблед и фиксед версия турбо паскаля
http://www.cirsovius.de/CPM/Projekte/Disassembler/TURBO-en.html
там вообще у чувака КУЧА разных рабочих дасмов.
Можно по-подробнее про это? Стало интересно.
http://www.fleasystems.com/flea86.html
Andrew771
13.03.2015, 10:23
Можно пояснить что понимается под приемлемым качеством кодогенератора?
Видимо, оптимизированная компиляция (https://ru.wikipedia.org/wiki/%D0%9E%D0%BF%D1%82%D0%B8%D0%BC%D0%B8%D0%B7%D0%B8%D 1%80%D1%83%D1%8E%D1%89%D0%B8%D0%B9_%D0%BA%D0%BE%D0 %BC%D0%BF%D0%B8%D0%BB%D1%8F%D1%82%D0%BE%D1%80#.D0. 9A.D0.BE.D0.BD.D0.BA.D1.80.D0.B5.D1.82.D0.BD.D1.8B .D0.B5_.D0.BC.D0.B5.D1.82.D0.BE.D0.B4.D1.8B). Другое дело, какой уровень оптимизации приемлем для Спека. В моем компиле точно есть (дописываю на днях):
- свёртка констант;
- упрощение выражений перекидыванием операндов из стека в регистры (удаление лишних push/pop);
- быстрое умножение и деление на числа степени 2, а также быстрое умножение на некоторые часто используемые числа;
- удаление повторных присваиваний и чтений переменных;
- удаление повторных расчетов индексов массива.
Как по мне дак самое главное в этом магическом "разные платформы" именно адресуемое пространство, сегодня 99.999% литературы по алгоритмам предпологают бесконечное адресное пространство ...
Короче, отвечая в лоб, если хочется чтобы твой компилер был одинаковый для всех, то сначала уровняй всех. Например напиши для всех 1 виртуальную машину, и компилер пиши для этой машины.
Для меня в этом магическом "разные платформы" главное - переносимость на уровне исходного кода. Язык высокого уровня и есть то, что позволяет писать, не задумываясь о том, на чём это будет запускаться.
Виртуальная машина тоже позволяет абстрагироваться от конкретного процессора. Создать такую виртуальную машину и писать программы на ассемблере для неё я уже пробовал, следующим этапом стал Паскаль. Который в том числе сможет генерировать код для виртуальной машины.
Отсюда вопрос - не пагубна ли сама идея: "сборка под разные платформы"? смысла практического ведь НЕТУ? Но вот под конкретную платформу сделать хороший инструмент, нужный людям! куда как более востребованное занятие, не зря народ жаждит update-a borland pascal под cp/m
Нет, не пагубна. Практичность/академичность действий понятие относительное. Например, вычисление тройных интегралов и числа Пи до 100-го знака на 8-битных процессорах может использоваться для тестирования процессоров и математических библиотек. Вполне практическое применение.
Мне интересна работа и устройство компиляторов и процессоров, Andrew771 делает инструмент под конкретную платформу, Oleg N. Cher'у нравится Оберон, кто-то запускает ARM Linux на 8-битных процессорах, а кто-то может заняться добавлением функций в дизассемблированную программу или написанием кодогенератора для FPC/GCC/etc.
В моем компиле точно есть (дописываю на днях):
...
Это всё на уровне псевдокода? В момент генерации или отдельным проходом? Где и как при этом хранится псевдокод?
Я тоже при разборе исходника генерировал псевдокод, но на пятом или шестом процессоре понял, что оптимизация получится как-то не очень. Проверка типов данных при попытке добавить все эти "массивы указателей на записи, в которых указатели на массивы" тоже зашла в тупик. Но у псевдокода свои плюсы, и сейчас задумываюсь о возвращении к чему-то подобному.
Andrew771
15.03.2015, 21:11
Это всё на уровне псевдокода?
Да.
В момент генерации или отдельным проходом?
При первой генерации генерируется псевдокод, а не код ассемблера. А оптимизация происходит при отдельных нескольких проходах.
Где и как при этом хранится псевдокод?
Псевдокод состоит из команд вида: мнемоника-число-строка. Хранится в массиве записей. Потом после оптимизации при окончательной генерации кода уже генерируется код ассемблера. Каждая команда псевдокода, как правило, состоит из нескольких ассемблерных команд.
На уровне псевдокода проще проводить оптимизацию, чем на окончательном ассемблере. И из него уже можно генерировать не только под Спектрум, но и под другие процы. Просто задать коды конкретного асма для каждой псевдокоманды.
Да, вот именно так у меня и было. Работало. Но таким способом получается хороший код для простых процессоров, а, например, для x86 или ARM с их заковыристыми адресациями такой метод просто не видит операции, они "рассыпаются" в псевдокоде. Или же программу надо писать "простыми словами", а не вот так
if node^.nodeargs[i]^.resulttype<>nil then
typ1:=node^.nodeargs[i]^.resulttype^
else begin
typ1.flags:=node^.nodeargs[i]^.resulttypeflag;
typ1.size:=4;
end;
Надо что-то изменить в структуре псевдокода, пока не пойму что.
---------- Post added at 00:11 ---------- Previous post was at 00:01 ----------
Кодогенератор FPC вообще жжот, для надёжности проверяет индекс массива два раза :) и копирует один байт при помощи movsb:
# [210] typ1.flags:=node^.nodeargs[i]^.resulttypeflag;
movzbl -860(%ebp),%eax
decl %eax
cmpl $9,%eax
jbe .Lj3685
call FPC_RANGEERROR
.Lj3685:
movzbl -860(%ebp),%eax
movl %eax,%edx
decl %eax
cmpl $9,%eax
jbe .Lj3686
call FPC_RANGEERROR
.Lj3686:
movl -884(%ebp),%ecx
movl 12(%ecx,%edx,4),%eax
leal -40(%ebp),%edi
leal 69(%eax),%esi
cld
movsb
Andrew771
16.03.2015, 10:41
Да, вот именно так у меня и было. Работало. Но таким способом получается хороший код для простых процессоров, а, например, для x86 или ARM с их заковыристыми адресациями такой метод просто не видит операции, они "рассыпаются" в псевдокоде.
Про x86 не знаю, не писал никогда на его асме. Возможно, определенные последовательности псевдокоманд можно объединять в одну команду асма x86.
У меня сейчас в выражениях используется только двухбайтовое представление (через регистровую пару HL), даже если действия производятся над однобайтовыми значениями. Только чтение и запись значений производятся соответственно размерности. Здесь нужно делать еще один проход, чтобы определить максимальный используемый тип в сгенерированном выражении. В первой версии компиля пока не буду это оптимизировать.
И еще индуктивность переменных тоже никак не учитываю. Так что, если встретится например:
for i:=1 to 100 do
a[i]:=i;
то на каждой итерации цикла будет рассчитываться заново адрес в памяти для ячейки a[i], хотя можно было всего лишь прибавить смещение к предыдущей ячейке. Здесь нужно уже анализировать весь поток от начала до конца цикла, а вдруг еще внутри есть другие циклы и ветвления. Пока не стал заморачиваться. А вот если эта же ячейка понадобится еще раз после, то уже возьмется запомненный ее адрес, это я сделал:
for i:=1 to 100 do
begin
a[i]:=i;
b[i]:=i+1;
if a[i]>b[i] then a[i]:=100;
end;
Ячейка a[i] только один раз будет рассчитываться.
Возможно, определенные последовательности псевдокоманд можно объединять в одну команду асма x86.Да, одной командой x86 можно объединить несколько простых псевдокоманд.
movswl EAX,[EBP+EDX*2+1200h]
Вот такое чтение элемента массива размером 2 байта, номер которого в EDX, с одновременной конвертацией в longint с учётом знака. Сколько это команд на псевдокоде...?
Andrew771
17.03.2015, 09:26
После оптимизации 4 штуки (два сложения, одно умножение и запись).
Error404
17.03.2015, 12:32
AlCo предлагает разработать Оберон-компилятор чтобы работал на самом Спеке, я пока отбрыкиваюсь, вроде странная задачка.
Почему нет?
В CP/M есть отличный компилятор ANSI C - Hitech C. Сделайте опять же нативный Z80-транслятор с Оберона на С.
Если не нравится Hitech C (например из-за того что он для CP/M, хотя Алоне все равно для АТМ пишет же), есть несколько компиляторов С в исходниках. Да и на спеке наверное есть С-компилеры (правда, из 90-х помнится что спековские компилеры были слабоваты, возможно из-за отсутствия нормальной ОС)
---------- Post added at 12:32 ---------- Previous post was at 12:21 ----------
Vadim, я когда начал писать компилятор тоже с теорией компиляции не был знаком. Была мысль прикрутить к FPC нужный кодогенератор, но FPC со стороны исходников мне не очень понравился. Я решил пойти по пути написания компилятора с нуля.
Доработать Turbo Pascal под CP/M? А толку? Даже если разобраться в декомпилированных исходниках и умудриться доработать, то это так и останется компилятор, "прибитый гвоздями" к конкретному процессору и ОС.
Компиляторы компиляторами, а смотрели вы например трансляторы (не интерпретаторы!)? Например, Innerfuse Pascal Script 3? Это скриптовый Object Pascal движок вида "Дельфи внутри Дельфи", на входе скрипт (т.е. программа на паскале), на выходе некий байт-код для executar-а (модуля-исполнителя байткода). Есть "дизассемблер байт-кода". Лет двенадцать назад я был просто фанатом IPS3 (версия 3 - последняя Free OpenSource, остальные платные), писал на нем программы в тысячи строк. Работало быстро и без косяков, все в исходниках, язык - практически полный Object Pascal.
Компиляторы компиляторами, а смотрели вы например трансляторы (не интерпретаторы!)? Например, Innerfuse Pascal Script 3? Это скриптовый Object Pascal движок вида "Дельфи внутри Дельфи"...
Нет, не смотрел, но в курсе, что такое есть.
По описанию это вообще не то, что мне нужно.
влезу немного сюда - не подкинет ли кто ссылочку на книжки какие-нибудь по написанию парсеров? мне не для языка или компилятора, хотя что-то похожее. просто конфиги получаются у меня навороченные, а парсер текущий - просто жуткая жуть. нужно какое-то более грамотное решение. заколебался уже с ними сидеть...
Error404
18.03.2015, 12:56
влезу немного сюда - не подкинет ли кто ссылочку на книжки какие-нибудь по написанию парсеров? мне не для языка или компилятора, хотя что-то похожее. просто конфиги получаются у меня навороченные, а парсер текущий - просто жуткая жуть. нужно какое-то более грамотное решение. заколебался уже с ними сидеть...
lex/yacc может быть? На них парсеры для чего угодно делали, от ЯВУ до игрушек диалоговых.
Книжек про них не знаю, но статей прогугливается очень много.
Barmaley_m
18.03.2015, 18:47
по написанию парсеров?
Попробуй GNU Bison. Бесплатно и сердито. Правда, я ни разу на нем ничего не делал, там надо осваивать, доки читать.
просто конфиги получаются у меня навороченные,
Для конфигов лучше всего задействовать стандартный формат типа XML или JSON. Парсеров полно, качай и пользуйся.
надо было сразу пояснить видимо. я не использую сейчас кое-либо яву. конфиги которые нужно распарсить уже существуют в определённом формате в оригинале на ПЦ, а мне под спринтера нужно тоже самое. по сути, конфиги имеют вид стандартных ini файлов с секциями типа [section] и далее строки с параметрами. есть секции вида [sect type n], где n какое-то целое число. и т.д. нашёл несколько исходников ini парсеров. но они все , конечно, на си. уже глаза в кучу...
Error404
18.03.2015, 20:45
Попробуй GNU Bison. Бесплатно и сердито. Правда, я ни разу на нем ничего не делал, там надо осваивать, доки читать.
Бизон это и есть yacc, переписанный линупсовыми "улучшайзерами". В комплекте с бизоном обычно используют flex (аналог lex)
Alex Rider
18.03.2015, 22:46
Наверняка ведь парсишь эти ini'шники в структуры. Напиши на PC утилиту, которая будет парсить их в двоичное представление этих структур, а в Спринтер загружай уже готовый к употреблению файл.
Andrew771
19.03.2015, 16:21
И еще индуктивность переменных тоже никак не учитываю. Так что, если встретится например:
Код:
for i:=1 to 100 do
a[i]:=i;
то на каждой итерации цикла будет рассчитываться заново адрес в памяти для ячейки a[i], хотя можно было всего лишь прибавить смещение к предыдущей ячейке. Здесь нужно уже анализировать весь поток от начала до конца цикла, а вдруг еще внутри есть другие циклы и ветвления. Пока не стал заморачиваться.
Кстати, заметил в Delphi (в Паскале вроде нет), что внутри цикла for и даже внутри него во вложенных циклах запрещено изменять счетчик цикла. Т.е. получается, что компилятору проще оптимизировать индуктивные переменные (у нас a[i]), не надо анализировать изменение где-то глубоко внутри цикла счетчик i. Ну нинаю, изменение счетчика внутри цикла - дурной тон, но в принципе не должен быть запрещен, как и оператор goto. Ну просто иногда позарез надо его менять (или переходить), иначе логика получается навороченной с кучей условий со многими флагами. Я такое не запретил у себя. Пусть лучше компиль мучается с оптимизацией, чем программист на нем.
А по-моему правильное ограничение, это не тот цикл, в котором можно прыгать туда-сюда. Сказано 10 раз, значит 10. При необходимости можно воспользоваться циклами while, repeat, или выйти из for при помощи break.
Andrew771
01.04.2015, 22:52
В общем, я выпустил первую бета-версию своего компилятора - ZX Like Pascal 0.9beta. Смотреть тут (http://zx-pk.ru/showthread.php?t=24967)
Отсюда вопрос - не пагубна ли сама идея: "сборка под разные платформы"? смысла практического ведь НЕТУ? Но вот под конкретную платформу сделать хороший инструмент, нужный людям! куда как более востребованное занятие, не зря народ жаждит update-a borland pascal под cp/m
А вот объясните мне, в чём фишка (сложность?) Паскаля под CP/M? В его принципиальном отсутствии? Он действительно так нужен? Его сложно написать? Почему? CP/M какая-то особенная?
А вот объясните мне, в чём фишка (сложность?) Паскаля под CP/M? В его принципиальном отсутствии? Он действительно так нужен? Его сложно написать? Почему? CP/M какая-то особенная?
наверно только ограничение TRDOS на длину файла и кол-во файлов на дискете.
Я тоже решил "пошутить" и выложить что есть :)
В исходниках на данный момент 134 TODO, плюс список задач в текстовом файле, то есть ещё работать и работать. В целом - стараюсь сделать "настоящий" Паскаль, совместимый с TurboPascal/FreePascal. Пока это всё выдаёт огромный медленный код, нужна оптимизация. Но сейчас важнее отладить фичи, чтобы устаканилась внутренняя структура компилятора, на которую опирается кодогенератор.
О возможностях компилятора.
Поддерживаются типы данных: 6 целочисленных (byte, word, longword, shortint, smallint, longint), boolean, pointer, string.
Допускаются array, record и pointer в любых комбинациях: массив указателей на структуры, внутри которых указатели на массивы байтов, и т.д., на сколько хватит оперативки.
Массивы пока только одномерные, но можно описать массив массивов.
Переменные могут быть любого типа (см. выше), глобальные/локальные, допускается absolute для явного указания адреса, по которому будет храниться эта переменная.
Выражения и операторы в выражениях: + - * / > < >= <= = <> div mod and or xor shl shr @ ^ :=
В выражениях учитываются приоритеты арифметических операций, скобки, допускается явное преобразование типов. Сложность выражений, в принципе, ничем не ограничена.
Ветвления, циклы: if, while, repeat, for. Цикл for работает с предпроверкой диапазона ;)
Подпрограммы (процедуры, функции): до 10 параметров любого типа, параметры передаются по значению и по ссылке (var, const).
Допускаются полиморфные подпрограммы (подпрограммы с одинаковым именем, но разным набором параметров).
Препроцессор понимает директивы условной компиляции $define, $undef, $ifdef, $else, $endif.
Директива $i - вставка текста из другого файла (include).
Компилятор (транслятор?) выдаёт файл на языке ассемблера, который можно собрать кросс-ассемблером.
Можно делать вставки на ассемблере asm...end, всё что между - копируется в выходной файл как есть. Парсер ассемблера и обработка в нём идентификаторов - отдельное большое TODO.
Теперь о недоделках.
Тип char вроде есть, но не проверял, скорее всего будет некорректно работать.
Иногда может путаться знаковая/беззнаковая арифметика.
Константы, перечислимые типы, многомерные массивы начаты, но нормально не работают, надо довести до ума.
Глобальные переменные на самом деле локальные, в стеке.
Не работает передача параметров по значению, если параметр нестандартного типа (массивы, записи...), передавайте по ссылке.
Проблемы с обработкой символов ' " / \ в строковых константах, потому что код обработки был написан лет 5 назад по принципу "лишь бы запустилось". Переделывать его надо полностью.
Отсутствует очень много семантических проверок. Если компилятор что-то "проглотил", это не значит что написано правильно :)
Также давайте разделять сам компилятор с языком Паскаль, и библиотеки. Спрайты, скроллы, шрифты - это всё библиотеки, которые пишутся и прикручиваются отдельно. Вот этих библиотек у меня сейчас нет вообще. Если кто-то решит написать какую-нибудь демку или игру - спрашивайте, расскажу отдельно о прикручивании ассемблерных процедур.
В общем, пробуйте, если что-то не работает - пишите, буду думать.
64832
хорошо бы вид от Борман Паскаль.
Иногда может путаться знаковая/беззнаковая арифметика.
это фиаско!
Глобальные переменные на самом деле локальные, в стеке.
как это?
хорошо бы вид от Борман Паскаль.
Что? Какой вид?
это фиаско!
Это версия ноль-ноль :)
как это?
У глобальных переменных не статический абсолютный адрес, а так же выделяется stack frame, как и для любой подпрограммы.
Что? Какой вид?
собсно текстовый редактор
http://i101.fastpic.ru/big/2018/0401/bb/2657c43e814de38fb4d0f0b290f0ddbb.png
- - - Добавлено - - -
У глобальных переменных не статический абсолютный адрес, а так же выделяется stack frame, как и для любой подпрограммы.
мне кажется, что это неправильно.
Да, неправильно. Такого "неправильного" там порядка 160 пунктов, причём "добавить поддержку модулей" и "переписать кодогенератор" в списке тоже есть. Если реализовывать даже по одному пункту в день исключая выходные, то как раз работы до конца года. Но оно уже хоть как-то работает. Вот ещё текстового редактора не хватает, это да...
ой, да по идее хватает простого редактора, без всяких там copy/paste. Набираешь текст, компилируешь, если ошибка вкралась, то подсвечивается, правишь, и снова в бой.
Такого "неправильного" там порядка 160 пунктов
надеюсь, не дореволюционных методов от CP/M80?
Так, арифметику со знаком доработать.
Текстового редактора (IDE) нет и не планируется.
Есть что ешё сказать конкретно по этой версии? Или "не смотрел, но осуждаю"? Тогда давай прекратим этот диалог.
В общем, пробуйте, если что-то не работает - пишите, буду думать.
Есть что ешё сказать конкретно по этой версии? Или "не смотрел, но осуждаю"? Тогда давай прекратим этот диалог.
шаблон затрещал, но лопнул. пока что компилятор подавился на:
{$define target_z80}
var
a,b:word;
function euclid(a,b:word):word;
begin
if a=b then
euclid:=a
else
if a>b then
euclid:=euclid(a-b,b)
else
euclid:=euclid(b-a,a)
end;
begin
a:=24;
b:=16;
euclid(a,b);
end.
Вот, это конструктивный разговор, с исходниками :)
У меня уже давно "глаз замылился", поэтому и выложил, чтобы попробовали другие люди.
Например, сразу понял, что процедуры вывода текста лучше включить в mysystem.inc, заодно и переименовать его.
По коду...
1. В конце строки 17 закрыть оператор символом ";". Не знаю как именно правильно с точки зрения языка, буду посмотреть.
2. Для результата функции я везде использую переменную result. Если писать так как в исходнике возникает некая неоднозначность, которую я пока не придумал как разрулить. У меня в todo это есть.
3. Дополнил код, см. приложенный файл.
И да, с signed типами у меня там всё плохо, буду доделывать. Unsigned должны корректно работать.
Ещё неожиданно обнаружился баг с выводом чисел больше чем 1 429 496 729.
В архиве исправленный и дополненный исходник, .bin и .tap. Почему .bin такой большой? Да потому что в нём весь mysystem.inc. "Умная линковка" в очереди.
64876
64877
ладно, оставлю в покое тогда.
mysystem.inc не корректный. По идее inc(a) это a:=a+1, inc (a,5) это a:=a+5
и вопрос по ассемблерным вставкам: можно ли обращаться к переменным? например, LD DE,@a ?
mysystem.inc не корректный. По идее inc(a) это a:=a+1, inc (a,5) это a:=a+5
Да, действительно. Добавлю, но вообще это заглушки, потому что потом это будут встроенные процедуры, как положено.
и вопрос по ассемблерным вставкам: можно ли обращаться к переменным? например, LD DE,@a ?
К сожалению нет. Пока нет... но когда "да" - большой вопрос.
Пока можно так:
var a:word absolute $7000;
...
asm
ld de,(0x7000)
end;
Аргументы передаются в стеке, по 4 байта на аргумент, обращаться через регистр IX (это base pointer).
[IX+4] это последний аргумент подпрограммы, [IX+8] предпоследний, и т.д.
Могу попробовать развернуть порядок аргументов, [IX+4] это будет первый, [IX+8] второй и т.д.
При переделке кодогенератора смещения могут измениться.
Error404
04.04.2018, 13:31
Текстового редактора (IDE) нет и не планируется.
Рискну вызвать гнев автора (ибо не смотрел т.к. кажется еще рано), но влезу с пожеланиями.
Если сделать кодогенератор с генерацией отладочной информации и файлов символических ссылок, и добавить к этому движок эмулятора Z80 с делегацией функций дебугера (как минимум брикпоинты и загрузку в эмуль кода/окружения - простейшая задача для тутошних авторов эмуляторов), то можно сравнительно малой кровью прикрутить готовые несложные интерфейсы типа ProgrammersNotepad и получить source-level debugger IDE с редактором, подсветками, проектами и т.п. Такой опыт уже был у меня (я типа давал ТЗ :) ) и b2m (он допиливал свой эмулятор (http://zx-pk.ru/threads/8373-pozhelaniya-i-plany-po-emulyatoru-bashkiriya-2m.html?p=488682&viewfull=1#post488682)), и не взлетело это (ну как не взлетело, промежуточный результат был, но порой промахивался мимо брикпоинтов) исключительно из-за убожества SDCC (http://zx-pk.ru/threads/8373-pozhelaniya-i-plany-po-emulyatoru-bashkiriya-2m.html?p=494676&viewfull=1#post494676) (это такой кросс компилятор C с претензиями, под который делалось) и невозможности его допиливания в онлайне (да и в офлайне). Т.е. главное - наличие покладистого и головастого писателя компилятора, остальное найдем. :)
промежуточный результат был, но порой промахивался мимо брикпоинтов
Если отключить оптимизацию, то вроде не промахивался. Лично мне не нравилось, что плагин к ProgrammersNotepad - это один большой костыль. Тут надо копать в сторону протокола gdb и поддерживающих его IDE.
Но в одном ты прав - полнота отладочной информации от компилятора, это базис, без которого не стоит и начинать. А SDCC на тот момент предоставлял не всю нужную информацию, да и с локальными переменными там какой-то косяк был.
OrionExt
04.04.2018, 13:47
Error404, простейшая ли? Не видал таких. Отладочную инфу гнать по стандадарту. И возможно ли это. Платформы 8-бит даже от одного родителя сами себе противоречат. Вроде были попытки, но воз и ныне там. Хотя тема очень актуальная, для меня уж точно. Так и живем.
Error404
04.04.2018, 13:51
Если отключить оптимизацию, то вроде не промахивался. Лично мне не нравилось, что плагин к ProgrammersNotepad - это один большой костыль. Тут надо копать в сторону протокола gdb и поддерживающих его IDE.
Но в одном ты прав - полнота отладочной информации от компилятора, это базис, без которого не стоит и начинать. А SDCC на тот момент предоставлял не всю нужную информацию, да и с локальными переменными там какой-то косяк был.
SDCC на тот момент уже десятилетие разрабатывался, на секундочку. :) И содержал на выходе кучу всякого мусора, как в коде, так и в отладочной информации, что отражало отсутствие в головах разработчиков порядка. Когда я вижу такие вещи, то последующие метания авторов меня не интересуют (научился отсекать маргиналов на подлёте, чем немало сэкономил ресурсов и здоровья), так что не могу сказать полегчало там сейчас или нет (хотя помнится много позже в тредах по UZIX видел что таки не полегчало, т.к. UZIX собирается только какой-то особой промежуточной версией SDCC с неким опытным путем подобранным набором промежуточных же UZIX-only патчей).
Рискну вызвать гнев автора (ибо не смотрел т.к. кажется еще рано), но влезу с пожеланиями.
Может и рано... Смотря что вы ожидаете там увидеть :)
Если сделать кодогенератор с генерацией отладочной информации и файлов символических ссылок
Да лехко. Но, наверное, не в этом году :) IDE я точно заниматься не буду - меня просто на всё не хватит.
А вообще в ассемблерный файл сейчас выводятся строки исходного кода, так что ассемблер может оттуда всё вытащить. Только давайте о формате договоримся.
; example.pas(281,2): write(' test ');
ld hl,label017
ld (__reg32a),hl
ld hl,0
ld (__reg32a+2),hl
call __pusharg
call __write_131
ld hl,4
add hl,sp
ld sp,hl
строчки с комментариями как раз то, что нужно.
Andrew771
05.04.2018, 15:28
Я тоже решил "пошутить" и выложить что есть
Это хорошо. Слишком долго надоедает работать в стол, да и глаз замыливается. Я свой допиливал потом почти 2 года, пока не стала стабильная версия (на данный момент 9-я).
У глобальных переменных не статический абсолютный адрес, а так же выделяется stack frame, как и для любой подпрограммы.
мне кажется, что это неправильно.
Это правильно, Н.Вирт в своей книжке такое тоже упоминал. Просто, лишний раз юзается стек, замедляет работу.
Просто, лишний раз юзается стек, замедляет работу.
мне думается, что Борланд положил на книжку
Andrew771
05.04.2018, 17:07
мне думается, что Борланд положил на книжку
Скорее всего, да. Глобальные лучше прямо объявлять в памяти, быстрее обращаться к ним. Вирт об этом тоже писал.
У меня так и сделано, правда нет вообще локальных. Из-за этого отсутствия, кстати, невозможно пока скомпилировать сам компилятор и сделать нативным для ZX, что просил Alone.
версия 0.1
исправления и дополнения:
- арифметика signed integer;
- вывод целых чисел;
- многомерные массивы;
- именованные константы const a=1; (пока только целые положительные);
- библиотека zxlib.inc (clrscr, вывод текста);
- inc(x,y) и dec(x,y) в system.inc.
64927
const
HERO_SPRITE:array [1..12] of byte = (1,0,0,71,$5a,$52,$3c,$10,$10,$18,$14,$14);
DEVIL_SPRITE:array [1..12] of byte = (1,0,0,3,$5a,$52,$3c,$10,$10,$18,$14,$14);
begin
...
SpritePutClear(@HERO_SPRITE,x_hero-1,y_hero-1);
for i:=1 to volume_devils do SpritePutClear(@DEVIL_SPRITE,devil[i,1]-1,devil[i,2]-1);
...
end.
И это, блин, работает! :)
64961
Andrew771
10.04.2018, 23:33
ща, как время появится и доберусь до своих паскаль-исходников для PC, позапускаю на твоем компиле. Хочется симулятор футбола хотя бы запустить (есть такой). Там куча типов записей.
К-какой симулятор футбола? Мне аж страшно... но интересно.
Оно скорее всего в оперативку не поместится. Зато будет понятно в какую сторону дальше копать.
Сейчас у моего кодогенератора бинарник получается раза в 3 больше, чем в ZX Like Pascal. В demo_z.prg один только код, без спрайтов, около 45 килобайт.
Andrew771
11.04.2018, 00:17
К-какой симулятор футбола? Мне аж страшно... но интересно.
Оно скорее всего в оперативку не поместится. Зато будет понятно в какую сторону дальше копать.
Не бойся, он текстовый.) Симулятор чемпионата Европы по футболу. Надеюсь, влезет.
Еще есть прога на Delphi поиска оптимального маршрута в Московском метро, тоже текстовая. Тоже попробую.)
Сейчас у моего кодогенератора бинарник получается раза в 3 больше, чем в ZX Like Pascal. В demo_z.prg один только код, без спрайтов, около 45 килобайт.
Ого. Да, надо потом над оптимизацией кода компилятора работать - это отдельная большая тема.
Да, надо. У меня давно уже возникают мысли о том, что псевдокод в моём случае - лишняя сущность. Но об этом ещё рано серьёзно думать.
Сегодня заработала "умная линковка", но пока спотыкается на forward-подпрограммах, их надо переделывать.
Andrew771
11.04.2018, 21:55
Псевдокод, каждая команда которого состоит из нескольких команд ассемблера (пи-код) или одной? Пи-код, на мой взгляд, проще оптимизировать, т.к. команды более обобщены. Я писал в статье об этом, тут со стр.52 (http://dgmag.in/N15/DowngradeN15b.pdf)
Нашел некоторые свои поделки на Паскале, см.файлы. Что в них нужно подогнать под твой компиль? (Правда, на нынешнем ноуте с Win10 у меня нифига не работают ни DOS-овские программы, ни EmuZWin, не могу ничего сделать. :( В конце мая буду на нормальном компе у родоков, где всё пашет).
Что в них нужно подогнать под твой компиль?
Скорее компилятор надо подогнать под поддержку того, что нужно этим программам...
Eurofoot и Topolog пока по объёму сгенерированного кода в 64 килобайта не уложатся.
Также там есть readln (которого у меня пока нет) и работа с файлами (которых у меня пока тоже нет).
Попробовал life.pas. Что изменил:
- uses заменил на {$i};
- в строке 36 и 37 изменил обращение к random;
- закомментировал строку 61 (из-за READKEY, его пока нет) и строку 69 (из-за оператора NOT, что-то с ним не так).
Собралось :) 12135 байт. Но естественно не запустилось. Надо компилятор и библиотеки доделывать.
Andrew771
11.04.2018, 22:51
в данных прогах обращение к файлам можно заменить загрузкой (инициализацией) значений в массивы.
Тем более не поместится.
В life.pas в процедуре FORMIROV первый цикл (который I, J, 80x24) выполняется около минуты.
Потом запнулось из-за (не)случайных чисел.
Займусь этим на следующей неделе.
Псевдокод, каждая команда которого состоит из нескольких команд ассемблера (пи-код) или одной? Пи-код, на мой взгляд, проще оптимизировать, т.к. команды более обобщены. Я писал в статье об этом, тут со стр.52 (http://dgmag.in/N15/DowngradeN15b.pdf)
Прочитал статью. Интересно.
У меня всё, в принципе, так же, только пи-код другой. String в нём кажется совсем лишний, у меня всё что можно перебрасывается на библиотечные подпрограммы, деление тоже написано на Паскале (system_divmod.inc). Сделано это чтобы на начальном этапе не заморачиваться написанием деления, строк и прочего под новый процессор, а когда будет добавлено переопределение операторов - вообще станет штатной функцией компилятора.
Пи-код находится между синтаксическим деревом и инструкциями современных процессоров, которые заточены под языки высокого уровня. При подгонке пи-кода он всё больше похож на синтаксическое дерево и всё больше соответствует одной строке ассемблера какого-нибудь x86 или ARM. Поэтому и думаю что он мне не нужен.
Сейчас, если внимательно посмотреть на сгенерированный для Z80 код, можно увидеть что он как бы транслирован с 32-битного процессора. Почти так и есть.
Интересно, а выполнение пи-кода будет ли быстрее, чем скомпилированная программа?
По сравнению с тем что сейчас - однозначно :)
По сравнению с идеальным машинным кодом - нет. Пи-код это байт-код, которому нужен интерпретатор. На каждую операцию добавляется как минимум чтение байта и переход по таблице.
Версия 0.2
Исправления и дополнения:
- константы-массивы (массивы констант?), пока только массивы байтов;
- удаление неиспользуемых подпрограмм (smart linking);
- исправлено размещение многомерных массивов в памяти;
- исправлены ошибки работы с boolean;
- написан wrapper для некоторых подпрограмм из бибилиотеки ZX Like Pascal;
- адаптирована "demo_lode_runner.prg" из ZX Like Pascal;
- адаптирована life.pas.
"Умная линковка" позволяет писать на Паскале библиотеки любого размера, в код будут включены только используемые подпрограммы.
В архиве бинарники win32 и linux64, библиотеки, файлы-примеры .pas и .tap.
64974
life.pas не зависла, она работает, 20 секунд идёт инициализация и 60 секунд на итерацию :)
64973
Эта неделя получилась непродуктивной в плане компиляторостроения. В основном внутренние изменения, никаких новых функций. Плюс появились другие задачи, кроме компилятора.
Планы: оператор case, чтобы запустить demo_z. Так как код пока не оптимизирован и бинарник с картинками имеет объём около 60 килобайт, запускать будем в режиме Spectrum +3, отключая ROM. Следующим пунктом будет поддержка константных выражений в описаниях констант и типов.
Пример:
const
c=20;
size=c*5+4;
type
tArray=[1..size] of byte;
Потом будет большая работа по внутреннему "тюнингу", после чего, надеюсь, удастся избавиться от приведения всей арифметики к 32 битам, что должно немного уменьшить размер кода и значительно увеличить его скорость.
Ещё очень нужны inline-подпрограммы. Но без оптимизации кода они смысла не имеют.
Andrew771
24.04.2018, 10:02
Потом будет большая работа по внутреннему "тюнингу", после чего, надеюсь, удастся избавиться от приведения всей арифметики к 32 битам, что должно немного уменьшить размер кода и значительно увеличить его скорость.
Bolt, у тебя сейчас кодогенерация происходит в пи-код или сразу в ассемблер?
Для выражений рекомендуют в книжках сначала определить максимальный используемый числовой тип данных в выражении и уже отталкиваться от этого, какое выражение - 8-битное, 16-битное, 32-битное и т.д.
Т.е., если у тебя в выражении максимальный тип byte, то всё выражение рассчитывается по 8-битному алгоритму.
В ZX Like Pascal везде 16-битные выражения, только есть отдельные оптимизации, превращающие в 8-битные, где надо.
Bolt, у тебя сейчас кодогенерация происходит в пи-код или сразу в ассемблер?
В пи-код. Который пока никак не оптимизируется и вообще, как мне кажется, лишний, я уже объяснял почему.
Для выражений рекомендуют в книжках сначала определить максимальный используемый числовой тип данных в выражении и уже отталкиваться от этого, какое выражение - 8-битное, 16-битное, 32-битное и т.д.
Об этом я тоже думал, но можно сделать ещё круче :) Попытался, запутался, не осилил, отложил на потом, приведя всё к 32 битам.
Надо синтаксическое дерево и пи-код в порядок привести. В них сейчас не всё корректно заполняется, в результате работает "на честном слове". Знак-беззнак до сих пор кое-где не работает. Или, например, выражение (@a+n)^ обрабатывается правильно, а (@a+n+m)^ теряет тип указателя. А если поверх всего этого ещё оптимизацию наложить - вообще потом концов не найдёшь.
s_kosorev
24.04.2018, 11:15
ля выражений рекомендуют в книжках сначала определить максимальный используемый числовой тип данных в выражении и уже отталкиваться от этого, какое выражение - 8-битное, 16-битное, 32-битное и т.д.
Это для толстых процессоров, для Z80 нужно каждую пару вычислять с минимальной разрядностью, сложить восьмибитную пару и потом расширить до 16 бит проще,чем сразу складывать 16бит, конкретно для сложения это не совсем так, но нужно 2 расширения делать вместо одного, но мысль думаю понятна.
Так можно перенос потерять. Но мысль понятна.
Можно даже диапазоны учесть. "(word div 300) + 17" на выходе даст byte.
Andrew771
24.04.2018, 12:20
В пи-код. Который пока никак не оптимизируется и вообще, как мне кажется, лишний, я уже объяснял почему.
как вариант, конвертировать 32-битный пи-код в еще один пи-код, 8-битный.
Так и до микрокода дойти можно, а там такой простор для оптимизации, особенно для архитектур на основе VLIW :)
mordaha: Это старкон2, запущенный в DosBox, под иксами в Дебиане, который запущен в VMWare, которая в WinXP
mordaha: Куда мне вопрос о неработающем звуке задавать? )))))
gregory_777: Санитарам.
Andrew771
24.04.2018, 13:09
Видимо, утопичная идея была сделать "компилятор под все платформы". Нужно было хотя бы ограничиться 8-битными компьютерами. Ну или все, и старые, и новые платформы пусть на 8-битах сидят.
Видимо, утопичная идея была сделать "компилятор под все платформы".
От запуска на 64k RAM давно отказался, вот это неудачная мысль была.
А кодогенераторы для 8 и 32 бит - нисколько не утопичная, особенно при правильной внутренней организации.
Я потом может ещё 16-битные добавлю (MSP430).
Оператор case работает, demo_z уже что-то выводит, но надо ещё работать.
Бинарник 56593 байта. В архиве 65134 .tap для компьютеров с поддержкой портов 1FFD/7FFD. Я запускаю в эмуляторе fuse в режиме plus3.
Andrew771, что надо вручную изменить в подпрограммах вывода спрайтов, чтобы учесть режимы, нужные для demo_z?
Вывод карты пока заблокирован, вывожу только некоторые спрайты, но их сильно корёжит, особенно когда спрайт выходит за пределы экрана.
65133
Andrew771
25.04.2018, 15:54
Andrew771, что надо вручную изменить в подпрограммах вывода спрайтов, чтобы учесть режимы, нужные для demo_z?
Удалить вывод атрибутов.
Вывод на виртуальный экран оставить.
А вообще непонятно, что значит изменить. Они ж библиотечные процедуры с включаемыми по опциям кусками кода, или у тебя как-то по другому сделано?
Конечно у меня по-другому, процедуры сейчас включены целиком, потому что обработку ключей и кусков кода делал твой компилятор.
Вывод атрибутов я вроде нашёл и закомментировал.
Какие ещё куски кода убрать?
Andrew771
25.04.2018, 17:40
Конечно у меня по-другому, процедуры сейчас включены целиком, потому что обработку ключей и кусков кода делал твой компилятор.
Вывод атрибутов я вроде нашёл и закомментировал.
Какие ещё куски кода убрать?
В процедурах вывода спрайтов всё, что между комментариями:
; +++++ _flag_attr_sprite +++++
; ----- _flag_attr_sprite -----
удалить, включая вложенные комментарии других опций.
Остальное всё оставить.
- - - Добавлено - - -
Или проще, скомпилируй моим компилятором demo_Z и оттуда скопируй все процедуры из скомпиленного файла ASM.
Компилировать и копировать уже пробовал - не понравилось...
Убрал блоки _flag_attr_sprite, стало совсем хорошо. Теперь надо перенести SpritePutAnd(), SpritePutOr(), и карту, и будет вообще красиво :)
65140
Oleg N. Cher
25.04.2018, 21:23
Видимо, утопичная идея была сделать "компилятор под все платформы".Утопичная, потому что "нас, ностальжат, мало, и у каждого самая правильная тельняшка. И полное желание контролировать абсолютно все аспекты проекта. И нежелание делать неинтересную работу, откладывая на вечное "потом".
И поэтому нас есть сейчас два эмммм... средненьких... компилятора Паскаля для Z80. Вместо одного хорошего.
Бывают и другие расклады, Free Pascal вот. Он если не под всё, то много под что.
- - - Добавлено - - -
Не умеем работать вместе, господа, не умеем. Даже если идеи схожие. Честно себе признайтесь.
Free Pascal хорош, есть под много что, но пусть он там и будет. Внутрь я заглядывал лет 5 назад, там тихий ужас. Если они продолжают его писать так же, то пусть пишут. Человек со стороны вряд ли разберётся в том коде, а на письма авторы не отвечали.
Да, работать вместе "не умеем".
Мне вот сейчас очень не хватает тестов. Простых программ, которые будут проверять пограничные случаи. Да ту же арифметику прогнать и убедиться что умножение и деление работает корректно. Кто-нибудь будет их писать? Кто-нибудь будет писать графические библиотеки? Или вот сегодня напоролся на очень неоднозначную ситуацию, кто-нибудь готов думать как из этого выкручиваться или почитать спецификацию и сказать "там на 628-й странице это описано"?
Нет, люди будут ждать готовую Visual Delphi IDE for Z80 с кнопкой "сделай мне хорошо", и чтобы это хорошо было лучше чем на ассемблере.
Oleg N. Cher, а как ты представляешь объединение двух "эмммм... средненьких..." компиляторов в один хороший? При том что один компилятор является отдельным диалектом, мало с чем совместимым, а другой компилятор в идеале планируется довести до способности сборки самого себя, и даже может того же FPC. (кстати, сам себя на x86 он уже почти собирает)
Oleg N. Cher
25.04.2018, 23:18
Bolt, абсолютно верная постановка вопроса. Никто ничего делать не будет. Максимум - дадут совет. Или сделают что-то для себя. То есть все может и хотят объединиться, но только вокруг своего проекта.
При всех недостатках внутреннего устройства Free Pascal это большой и хороший проект, который уже довели до вполне стабильного состояния. И имеющий много пользователей. В своё время я очень просил Андрея Andrew771 открыть исходники его ZX-Like Pascal. Всё-таки открытый проект воспринимается приятнее. И есть, может быть, тайная надежда, что кто-то присоединится. Но сейчас Андрей наверняка может прибавить пять копеек и сказать, что это не имело смысла. Никто ничего на уровне исходников компилятора не делал. Максимум - ковырялись в Спектрум-рантайме.
Думаю, самое умное, что я скажу в этом посте, понимайте как хотите, это будет такая идея. Хорошо бы создать компилятор (Паскаля или Си), однотаргетный или мультитаргетный, но с возможностью описывать оптимизацию кода на каком-то внутреннем языке/скрипте. Чтобы человек, которого не устраивает конкретно тот или иной код, мог поучаствовать в написании правила оптимизации. И чтобы это было просто. Приблизительный аналог - peephole-оптимизатор, использованный в SDCC, который команда z88dk сумела снабдить набором расширенных правил, получив ZSDCC. Только такой подход мне кажется разумным в условиях, когда проект ведётся одним разработчиком, пускай даже ему все кричат "давай-давай!", а кто-то даже чем-то помогает.
Вот так и представляю. Но тут нужно переосмысление "кирпичиков" оптимизации.
Пожалуй, всё-таки недо-Си в стиле Sphinx C-- или даже PL/M для Z80 будет более реалистичным проектом, чем Си/Паскаль. Именно по качеству выхлопа, т.е. не по количеству полученного от проекта удовольствия, а по качеству получившегося в итоге инструмента. Дискуссабельно.
P.S. Bolt, ну а Вы ZXDev хоть щупали? Что в нём конкретно настолько не так, что надо пилить другой компилятор? Просто интересно. Язык не тот?)
Да, язык не тот ) ZXDev, насколько помню, транслирует Оберон в Си? Вот поэтому оно и не то. Возможно, я отстал от жизни, но 7 лет назад основной целью было никак не касаться Си. На то было причины.
Понимайте как хотите, но я не хочу продолжать это обсуждение. Кто хочет поучаствовать - на генерации кода и оптимизации свет клином не упёрся, есть ещё RTL и тесты.
Погоня за качеством вещь хорошая, но "так сложились обстоятельства" (с), что вся моя жизнь превратилась в погоню за результатом и "повышение качества жизни" (с) любой ценой. Всё, от чего я получал удовольствие, было отодвинуто на десятый план, потому что "перед нами стоит задача, нам необходимо принять ответственное решение" (с). Мне не понравилось. Теперь у меня приоритет на получение удовольствия, а качество продукта приложится.
Andrew771
26.04.2018, 10:07
Убрал блоки _flag_attr_sprite, стало совсем хорошо. Теперь надо перенести SpritePutAnd(), SpritePutOr(), и карту, и будет вообще красиво
Скорее всего, есть еще проблема с адресом виртуального экрана. Он у меня размещается в конце ОЗУ перед стеком, адрес жестко задан. Тебе нужно переопределелить его.
И поэтому нас есть сейчас два эмммм... средненьких... компилятора Паскаля для Z80. Вместо одного хорошего.
Не умеем работать вместе, господа, не умеем. Даже если идеи схожие. Честно себе признайтесь.
Bolt пока еще создает компилятор, причем близкий к спецификации "настоящего" Паскаля, так что всё впереди. Я, если так можно выразиться, в помощниках - предоставил библиотеку процедур. А также хотел бы по оптимизации помочь. Если Z_demo скомпилится полностью в 48к и будет работать на нормальной скорости, то можно ZX Like Pascal забросить.
Скорее всего, есть еще проблема с адресом виртуального экрана. Он у меня размещается в конце ОЗУ перед стеком, адрес жестко задан. Тебе нужно переопределелить его.
Там проблем нет. Проблема есть в другом.
Выражение вида "A<(B-C)". Если B и C имеют размер 8 или 16 бит, то всё просто. Но если B, например, longword, то выражение в скобках signed или нет? Потому что сравнения cmp_us и cmp_uu дадут разный результат и я пока не знаю как правильно. На чём и споткнулся (http://zx-pk.ru/threads/24967-zx-like-pascal.html?p=961254&viewfull=1#post961254).
о5 нам впаривают Оберон. Было, не?
Мне вот что интересно: когда не получается алгоритм, я скармливаю исходник Hitech C, потом смотрю на бинарник.
Выйдет ли что-то вменяемое из вышеупомянутых средств разработки? Наверное, ничего.
Oleg N. Cher
26.04.2018, 12:43
на генерации кода и оптимизации свет клином не упёрся, есть ещё RTL и тесты.Но ведь оптимизация - это самое главное для разработки на Z80. Удовольствие само собой, но от разработки тестов оно сомнительно)
Трансляция в Си - компромисс, чтобы не заниматься оптимизацией и кодогенерацией. А сосредоточиться на рантайме. Кстати, библиотеки некоторые в ZXDev имеются, в т.ч. и графические, советую ознакомиться.
- - - Добавлено - - -
Если Z_demo скомпилится полностью в 48к и будет работать на нормальной скорости, то можно ZX Like Pascal забросить.Ну вот, грустно всё это. А я предлагал тебе не сосредотачиваться на исключительно Z80, помнишь?)
о5 нам впаривают Оберон. Было, не?Тебе впаришь. Было ещё когда ты был DenPopov'ым. Давно и неправда.
Выйдет ли что-то вменяемое из вышеупомянутых средств разработки? Наверное, ничего.Наверное скудоумие некоторых товарищей или какая-то абсолютно непонятная упрямость мешают им смотреть на вещи адекватно. Я опять повторюсь: SDCC имеет намного больше права на жизнь, чем Hitech C. Впрочем, для господ извращенцев я даже начал делать подсистему ZXDev3 на базе CP/M-ного Hitech C. Ажиотажа вокруг неё совершенно не наблюдается.
marinovsoft
26.04.2018, 13:00
Bolt, а допилить кодогенератор, чтобы на выходе был i8080 код, возможно?
Тебе впаришь. Было ещё когда ты был DenPopov'ым. Давно и неправда.
тяжело с тобой разговаривать. досвидули.
Bolt, а допилить кодогенератор, чтобы на выходе был i8080 код, возможно?
Возможно. Есть определённые сложности, но возможно. Сложность заключается в отсутствии каких-либо инструкций для поддержки ЯВУ, у Z80 хотя бы регистры IX/IY есть...
Вот на i8086 уже будет намного проще.
Вот на i8086 уже будет намного проще
речь о 8080. какие индексные регистры у 8086?
Andrew771
26.04.2018, 14:48
Если Z_demo скомпилится полностью в 48к и будет работать на нормальной скорости, то можно ZX Like Pascal забросить.
Ну вот, грустно всё это. А я предлагал тебе не сосредотачиваться на исключительно Z80, помнишь?)
Еще раз уточню, а то вдруг не так понял про забрасывание. :)
Сейчас Z_demo компилится в ZX Like Pascal в 48к и работает на нормальной скорости, даже еще есть место, т.к. вообще-то это должна быть полноценная игра, а не демо. Но если Bolt-овский компилятор сможет также скомпилить, то лучше перейти на него, т.к. это полноценный Паскаль, а не мой ограниченный спец.инструмент для написания игр. У меня даже задумка есть, еще более его ограничить - сделать только 8-битные команды и выкинуть атрибуты и ключи, для увеличения быстродействия и написания монохромных игр.
s_kosorev
26.04.2018, 14:51
какие индексные регистры у 8086?
SI,DI, BP ?
Oleg N. Cher
26.04.2018, 16:57
т.к. это полноценный Паскаль, а не мой ограниченный спец.инструмент для написания игр. У меня даже задумка есть, еще более его ограничить - сделать только 8-битные команды и выкинуть атрибуты и ключи, для увеличения быстродействия и написания монохромных игр.Именно монохромных? Э-ээ, батенька, да Вы делаете шаги в сторону Sphinx C--, только на базе Паскаля... И правильно.
Теперь надо перенести SpritePutAnd(), SpritePutOr(), и карту, и будет вообще красиво :)
Перенёс SpritePutAnd(), SpritePutOr(), и карту :)
65148 (.tap для Spectrum+3)
65147
версия 0.3
добавлен оператор case
доработана zxlikepascal_lib
собирается и запускается demo_z.pas
оптимизирован код при работе с массивами
некоторые внутренние изменения
65162
Andrew771
28.04.2018, 14:59
версия 0.3
В EmuZWin 2.7 все проги работают, кроме demo_z (с прошивкой Spectrum 3+), выводит только цветные диагональные полосы.
life работает нормально, но выдает в начале одну и ту же комбинацию микроорганизмов. Необходим randomize.
И вообще не понял, как компилировать файлы pas. Я лет 15 уже только на кнопки с надписями умею жать. :) Напиши плз короткую инструкцию.
Про ramdomize и иструкцию - учту.
Demo_z не работает которая .tap? Только что проверил, в FUSE работает.
Где взять EmuZWin? Всё что нахожу - VirusTotal ругается. Он, правда, и на мой компилятор сказал "1/61"...
Oleg N. Cher
28.04.2018, 19:43
Где взять EmuZWin?Все версии EmuZWin с авторского сайта:
http://kolmck.ru/r_apps.htm
Andrew771
28.04.2018, 20:05
Поставил Fuse, всё работает, правда скорость удручающая, даже у Life. Оптимизация, как воздух, нужна. Но для начала супер!
EmuZWin отказывается работать на Windows 10. А на остальных виндах может ругаться антивирус на него.
Bolt, подскажи еще, как компилировать файлы pas?
В EmuZWin 2.7 все проги работают, кроме demo_z (с прошивкой Spectrum 3+), выводит только цветные диагональные полосы.
В отладчике EmuZWin я вижу только одно поле под названием "RAM", в котором появляется то, что выводится в порт 0x7FFD, и переключатель ROM.
DI
LD BC,1FFDH
LD A,01H
OUT (C),A
JP 0000H
Это по идее должно включить special paging mode, pages 0,1,2,3. Но в поле "RAM" появляется "01", с адреса 0xC000 появляется page 1, при этом на адресе 0x0000 остаётся ROM.
Неполная/некорректная эмуляция порта 0x1FFD? Или я что-то не так делаю?
- - - Добавлено - - -
Поставил Fuse, всё работает, правда скорость удручающая, даже у Life. Оптимизация, как воздух, нужна.
Полностью согласен :)
EmuZWin отказывается работать на Windows 10.
И, кажется, некорректно эмулирует порт 0x1FFD.
Bolt, подскажи еще, как компилировать файлы pas?
В командной строке
bmpc_z80.exe 1.pas
Выдаст файл 1.asm, а дальше - по вкусу. Я пользуюсь z80asm (в Ubuntu что-то поставилось, но он не поддерживает dup/edup) или Zeus Z80 Assembler, добавив в конце одну строку
output_bin "1.bin",0x8000,$-0x8000
Error404
28.04.2018, 21:20
Я пользуюсь z80asm (в Ubuntu что-то поставилось, но он не поддерживает dup/edup) или Zeus Z80 Assembler, добавив в конце одну строку
output_bin "1.bin",0x8000,$-0x8000
Это оттого, что DUP/EDUP был придуман авторами кто их ввел от незнания трансляторов-аналогов, в более ранних ассемблерах (и в т.ч. лучших по моему мнению таких как M80 от Microsoft) для аналогичных целей использовался блок REPT-ENDM (https://github.com/serge-404/AltairDOS/blob/master/man/M80KOI8.TXT). В современных трансляторах обычно используются таки REPT-ENDM, а DUP/EDUP назначаются как алиас (https://k1.spdns.de/Develop/Projects/zasm/Documentation/z65.htm) чтобы работали оба варианта. Предлагаю это вынести в опцию, чтобы компилятор генерировал оба варианта по указанию ключем командной строки. Обидно, если вывод компилятора Паскаль будет не совместим с M80 - для него под CP/M масса различных библиотек (формата REL линковщика L80 пакета Микрософт) в т.ч. и либы от различных ЯВУ т.к. они использовали M80 как транслятор с ASM.
"dup" есть в библиотеке из ZX Like Pascal.
z80asm не поддерживает ни dup, ни rept.
В компиляторе dup/edup не используется, поэтому опция не нужна. Сгенерированный код вообще стараюсь сделать как можно проще с точки зрения ассемблера. А вот опция компилятора "использовать недокументированные инструкции" может и понадобится.
Andrew771, у меня тут при оптимизации вся мелкая недвижимость потерялась. Большая в правом верхнем углу карты присутствует.
Как оно называется и в каком месте программы выводится?
65268
Andrew771
14.05.2018, 20:45
По-моему она и до оптимизации была потеряна. Это заводы WORK и флаги FLAGS в процедуре put_objects
Хм, действительно. Странно, потому что в процессе оптимизации оно то появлялось, то пропадало. Будем искать...
Нашёл.
if (x_put>=x_min_lim) and (x_put<=(x_map_scr+map_scr_width))
and (y_put>=y_min_lim) and (y_put<=(y_map_scr+map_scr_height))
then
(Смысл этих проверок от меня как-то ускользает. Догадываюсь что проверяется видимость объектов на экране, но до конца понять не могу.)
Проблема всё с тем же "заворотом" значений. В моём компиляторе буду стараться вычислять "математически". Если написано "(A-B)>10", то по возможности так и будет вычисляться, без удержания в уме типов переменных и правил работы с ними (привет языку Си). При A=5 и B=6 результат false.
Уместил demo_z в 48k. Занимает всю доступную память, для уменьшения кода закомментировал анимацию флагов, прописал вручную адреса некоторых переменных, ну и ещё есть несколько мелких костылей.
65302
Andrew771
18.05.2018, 18:02
Хорошо! Значит, оптимизация нормально идет.
У тебя еще отсутствует анимация рек, флажков, и часики на фабриках не ходят :) Ну это так...
Про часики и флажки знаю, надо же было как-то на 48k перейти, поэтому закомментировал. А реки текут, их я не трогал :)
Оптимизация да, идёт. "Простые" оптимизации в кодогенераторе закончились, надо теперь "сложные" делать, вроде свёртки констант.
версия 0.4
Оптимизирован кодогенератор.
examples.tap уменьшился с 14401 до 9732 байт.
demo_lode_runner.tap уменьшился с 11896 до 6601 байт.
life.tap уменьшился с 9237 до 5886 байт, длительность итерации сократилась с 60 до 23 секунд.
demo_z.tap уменьшился с 54656 до 32587 байт и теперь запускается на 48K.
Не знаю удастся ли уменьшить код ещё в три раза, но потенциал есть. Например оптимизация выражений "A:=A+B", сокращение разрядности вычислений, глобальные переменные, переменные в регистрах, автоматическое вынесение кода в подпрограммы...
65396
Andrew771
09.06.2018, 16:52
Фигово, что скомпилированный асм-файл не работает в асме эмулятора EmuZWin. Не понимает он директивы db (ну это легко заменить вручную поиском/заменой), а также всяческие include. Пытался вручную вставить текст из библиотек, но фиг вам.
Ну с include понятно что делать, а директива db ему чем не угодила? На что её заменить?
DEFB
Если запустить EmuZWin, два раза нажать F12, потом мышкой вопросик в углу, откроется страница помощи.
Там ещё и про ENTRYPOINT DEFM DEFW DEFS
DEFG DEFD ENCODE можно почитать.
А, ну да, DEFB. Я уже в ассемблерах запутался.
Директива include используется только один раз, для системной библиотеки. Уберу.
Ассемблер EmuZWin не понимает 0x1234, надо 1234h :v2_dizzy_facepalm:
TODO список изменений, необходимых для EmuZWin:
- заменить строку include ... на текст системной библиотеки;
- заменить db на defb;
- заменить числа вида 0x?? на 0??h.
Bedazzle
10.06.2018, 22:39
Ассемблер EmuZWin не понимает 0x1234, надо 1234h :v2_dizzy_facepalm:
Можно попробовать ублажить Дениса, он вроде недавно правленую версию с обновлённым ассемблером сотворил.
Ветка тут (http://zx-pk.ru/threads/28111-emuzwin-hack-edition.html).
версия 0.4.1
Адаптировал под ассемблер EmuZWin.
demo_z.asm в EmuZWin собирается и запускается.
Обнаружил две ошибки: не работает оператор NOT и иногда выводятся несуществующие ошибки при вызове подпрограмм с параметрами. То есть на самом деле всё правильно, а компилятор пишет ошибку.
Ну и на отладочный вывод не обращайте внимание :)
Так, стоп. Архив собрал неправильно. И танк не движется в EmuZWin.
65500
- - - Добавлено - - -
Подскажите правильный ассемблер, который может выдавать листинг после трансляции вот в таком виде:
a120 label080loop:
a120 fd 2a e8 82 ld iy,(parentframe1)
a124 fd 5e f1 ld e,(iy+-15)
a127 fd 56 f2 ld d,(iy+-14)
a12a eb ex de,hl
a12b 23 inc hl
a12c eb ex de,hl
a12d fd 2a e8 82 ld iy,(parentframe1)
a131 fd 73 f1 ld (iy+-15),e
a134 fd 72 f2 ld (iy+-14),d
версия 0.4.2
Танк поехал :)
65511
65510
Andrew771
19.06.2018, 17:29
Не работает самая простая программа, компилируется в асм, но потом требует какую-то отсутствующую метку:
program z;
var
a: byte;
begin
a:=30;
clrscr;
writeln('a=',a);
end.
Библиотеку подключал, всё равно требует.
Весь вывод write/writeln сводится к выводу символов через процедуру
procedure writechar(c:byte);
begin
end;
Можно подключить библиотеку system_zxlib.pas, там эта процедура уже есть, выводит текст шрифтом из ROM, записывая байты в видеопамять.
А можно описать свою и перенаправить или даже продублировать вывод, например, в COM-порт.
Ещё надо цвет текста установить, потому что инициализация пока полностью прописывается вручную.
Пример:
program z;
{$i system.inc}
{$i system_zxlib.pas}
var
...
begin
textcolor(7);
...
end.
- - - Добавлено - - -
Полный текст:
program z;
{$i system.inc}
{$i system_zxlib.pas}
var
a: byte;
begin
textcolor(7);
a:=30;
clrscr;
writeln('a=',a);
end.
Бинарник 2040 байт.
Запускаем...
65566
Паскаль для STM8 кого-нибудь интересует?
забыл спросить - а long используется?
Есть ли типы longword и longint? Конечно. Как без них?
Кодогенератор хочу переписать полностью, поэтому спрашиваю про STM8. Оно уже и на STM8 кое-как запустилось, но некоторые особенности кодогенератора мешают как раз перейти от 32 к 8 битам.
longint наверное. Просто на Паскакале нет поддержки типа данных, вроде у Борланд.
Всё никак не соберусь переписать кодогенератор, а на том что есть в 48 килобайтах особо не развернёшься.
Попробовал написать на Паскале что-то типа эмулятора Z80, а к нему 16к ROM и 16к RAM. ПЗУ запускается и даже пытается тестировать память, но пока не все команды реализованы. На микроконтроллере PIC24 (120 МГц, 60 MIPS) скорость достигает 10% от реальной. Есть куда расти :)
68331
Столкнулся с выражениями, которые не может обработать мой новый кодогенератор, и надо это как-то обойти.
Что-то мне помнится что Turbo Pascal выдавал ошибку "expression too complex", но ничего про это не могу найти. Я что-то путаю? Может это был какой-то другой язык или компилятор?
Bedazzle
28.05.2019, 18:44
Что-то мне помнится что Turbo Pascal выдавал ошибку "expression too complex", но ничего про это не могу найти. Я что-то путаю? Может это был какой-то другой язык или компилятор?
Вряд ли в Турбе, его сильно давно использовал.
Наверное в дельфях, когда реально дофига всяких скобок-знаков.
Кто возьмётся по листингу и .tap найти где сбивается кодогенератор?
demo_lode_runner стала меньше на 10%, 5935 байт.
demo_z работает с ошибками, но там без помощи автора не смогу.
В планах исправление ошибок и несколько фич кодогенератора, которые ещё уменьшат объём и увеличат скорость, потом - 8086 и STM8.
demo_lode_runner стала меньше на 10%, 5935 байт.
demo_z работает с ошибками, но там без помощи автора не смогу.
В планах исправление ошибок и несколько фич кодогенератора, которые ещё уменьшат объём и увеличат скорость, потом - 8086 и STM8.
Вам не сложно прикрутить к bmpc_z80.exe ключи -v и -h или /? а то все время путаешься какая версия запущена под Win32. Хотя версию он показывает вместе с компилируемым файлом на входе. И еще каким ассемблером(ами) ассемблируются его .asm? Когда он запускается без входного файла на консоль не выводится инфа о дальнейших действиях: то ли текст ему вводить( и в каком файле он тогда сохранится), то ли имя входного файла. По поводу объема и скорости ассемблерного кода. Это логичнее в отдельную прогу убрать. Или от программиста ничего не зависит в плане выбора стиля программирования на Паскале. По поводу STM8 ( не лучше ли сразу STM32 и других ARM процессоров).
А будет ли версия компилятора под nedoos? Очень нужно!
Вам не сложно прикрутить к bmpc_z80.exe ключи -v и -h или /?
...
Когда он запускается без входного файла на консоль не выводится инфа о дальнейших действиях: то ли текст ему вводить( и в каком файле он тогда сохранится), то ли имя входного файла.
Согласен, надо пояснить. Прикручу.
И еще каким ассемблером(ами) ассемблируются его .asm?
Я в Ubuntu пользуюсь z80asm, в мануале на ассемблер есть ссылка http://savannah.nongnu.org/projects/z80asm/
Или Zeus command line Z80 assembler, он поддерживает dup. Кстати, есть мысль сделать обработку dup...edup в ассемблерных вставках.
А вообще стараюсь текст максимально упростить, чтобы собиралось любым ассемблером. Ассемблерные вставки asm...end пока просто копируются в выходной файл.
По поводу объема и скорости ассемблерного кода. Это логичнее в отдельную прогу убрать. Или от программиста ничего не зависит в плане выбора стиля программирования на Паскале. По поводу STM8 ( не лучше ли сразу STM32 и других ARM процессоров).
Что именно убрать в отдельную прогу и что не зависит от программиста? Если речь идёт об оптимизации размер-скорость, то потом будут отдельные ключи для выбора режима оптимизации. А сейчас такого выбора нет, любое упрощение и уменьшает размер, и увеличивает скорость.
ARM пробовал, даже вывел текст на плате STM32F746G-DISCO, но там такое количество регистров и объём RTL, что оно отложено до лучших времён. А добавить STM8 не сложнее Z80.
А будет ли версия компилятора под nedoos? Очень нужно!
Кросс-компилятор с целевой платформой nedoos, или компилятор, запускающийся под nedoos? Запуск под nedoos - точно нет. Кросс-компиляция - если объясните что требуется в коде, то можно попробовать.
Хотя когда-то и была идея запустить компилятор на 64к, я от неё отказался.
В чём сложность запуска компилятора в таком окружении:
1. Чтобы запустить компилятор под NedoOS его надо скомпилировать под NedoOS. Нужна поддержка этой ОС в компиляторе.
2. Объём исполняемого файла превысит 64 килобайта однозначно. Можно переключать страницы, можно сделать оверлей, можно поделить компилятор на несколько частей...
3. Компилятор многопроходный, хранит в памяти информацию в виде деревьев и связных списков. Статистика по demo_z: 5313 строк, около 100 килобайт исходного кода, включая спрайты, 5549 узлов синтаксического дерева, в итоге около 12 килобайт исполняемого кода и 20 килобайт спрайтов. Компилятор для обработки такой программы использует почти 7 мегабайт оперативной памяти. Да, это 64-битные указатели. Да, можно перелопатить весь компилятор, экономя байты, можно работать с файлами на диске, можно сделать виртуальную память...
4. Сборку demo_z компилятор сейчас делает за 0,5 с на 64-битном процессоре с тактовой частотой 1,9 ГГц. На Z80 это будет минимум в 1000 раз медленнее. 8 минут, и это если всё в оперативке, без свопа и прочего. Оно такое надо?
Трезво оценивая свои способности и полученный результат готов взяться только за добавление целевой платформы, но не за попытку впихнуть невпихуемое :)
Да, печально. Но ведь было время запускался turbo pascal вместе с IDE на машинах с 640К памяти. И даже компилировал при этом и отлаживал. А первые версии вообще в 32к убирались.
Apple Pascal, 64 kb, 6502 1mgz
https://en.m.wikipedia.org/wiki/Apple_Pascal
Turbo Pascal имеет две особенности, которые позволяют ему так работать: он однопроходный, и наглухо прибит гвоздями к одной архитектуре.
Apple Pascal, видимо, тоже.
В 1-2 плоских мегабайта ещё можно попробовать уложиться. Но не в 64к с окнами, там половина тактов на переключение страниц уйдёт.
Или поднимаем тактовую, чтобы получить приемлемое время работы.
Или прибиваем гвоздями к Z80 и NedoOS, переписывая всё с нуля на ассемблере с использованием трюков для экономии байтов, тактов и регистров.
Что именно убрать в отдельную прогу и что не зависит от программиста? Если речь идёт об оптимизации размер-скорость, то потом будут отдельные ключи для выбора режима оптимизации. А сейчас такого выбора нет, любое упрощение и уменьшает размер, и увеличивает скорость.
ARM пробовал, даже вывел текст на плате STM32F746G-DISCO, но там такое количество регистров и объём RTL, что оно отложено до лучших времён. А добавить STM8 не сложнее Z80.
нужны операторы скобочные в Паскаль, чтобы они затем переходили в текст на ассемблере, а по ним эта прога-профайлер? определит время выполнения выделенного скобками фрагмента исходника( количество машинных циклов), задействованную память и регистры. Можно это все конечно добавить и в компилятор на своем ключе и генерить еще один файл.
Это подспорье программисту, который будет осваивать написание на нем эффективных программ. Мне не встречалось систем с дисплеями на STM8, хотя во Франции в 70-80е были компьютеры на ST6, ST7, и кажется это их предшественники архитектурно. На STM32 есть серия STM32 Primer с ЖКИ дисплеями. Там и операционка и игры были
http://www.stm32circle.com/resources/stm32primer2.php
и Паскаль с графикой там может быть в тему.
нужны операторы скобочные в Паскаль, чтобы они затем переходили в текст на ассемблере, а по ним эта прога-профайлер? определит время выполнения выделенного скобками фрагмента исходника( количество машинных циклов), задействованную память и регистры.
Теперь понял. Но... не понимаю зачем это именно в такой форме. Потому что код может меняться при изменении программы за пределами этого "оператора", и даже в другой версии компилятора, а программа на ЯВУ, подогнанная под один процессор, может быть очень медленной на другом.
Но если очень надо можно добавить, а потом уже пусть кто-нибудь пишет профайлер.
Мне не встречалось систем с дисплеями на STM8.
...
На STM32 есть серия STM32 Primer с ЖКИ дисплеями.
На STM32 много чего есть с дисплеями.
STM8 не обязательно должен быть с дисплеем и играми, он может выполнять и другие задачи.
Turbo Pascal имеет две особенности, которые позволяют ему так работать: он однопроходный, и наглухо прибит гвоздями к одной архитектуре.
Apple Pascal, видимо, тоже.
В 1-2 плоских мегабайта ещё можно попробовать уложиться. Но не в 64к с окнами, там половина тактов на переключение страниц уйдёт.
Или поднимаем тактовую, чтобы получить приемлемое время работы.
Или прибиваем гвоздями к Z80 и NedoOS, переписывая всё с нуля на ассемблере с использованием трюков для экономии байтов, тактов и регистров.
Судя по всему там какие-то космические технологии использовались, раз они в 32к убирались. А уж 1-2 мегабайта появились далеко не сразу, а всё это время паскаль работал и компилировал (из ИДЕ со встроенным дебаггером!).
В целом понял твою позицию. Я просто тему всю не прочитал, а думал ты делаешь компилятор именно под ZX, а оказывается это кросс.
О космических технологиях. Так, прикидочные расчёты, самому интересно. Движемся в обратную сторону.
Расход памяти при сборке demo_z.pas около 6.7 мегабайт.
Если переписать препроцессор и лексический анализатор, то можно убрать 1.7, останется 5 мегабайт.
Выбрасываем пост-оптимизацию, чтобы не хранить выходной текст в памяти, или сгружаем на диск - минус 2.6 мегабайта, остаётся 2.4 мегабайта.
Переделываем транслятор в промежуточный код, ограничиваем размер подпрограммы - минус 1.1 мегабайта, остаётся 1.3 мегабайта.
Выбрасываем смарт-линк и некоторые другие фичи, транслируем всё подряд - ещё минус 0.8, остаётся 0.5.
Много указателей, они сейчас 64-битные, если 32 бита - ну, раза в полтора уменьшится. 300 килобайт.
Хранить статически, а не в куче - будет ещё меньше.
Да можно вообще управиться за один проход и хранить только видимые идентификаторы - 100 килобайт.
16-битные указатели - вау, 64 килобайта.
То есть возможно, но это будет уже извращённое программирование и потеря многих функций.
Да, это кросс, который в той или иной степени уже может Z80, STM8, PIC24, PIC32 (MIPS), STM32 (ARM), и даже собирает сам себя под 80386 и потом запускается, но не до конца работает :)
поройтесь в интернетах, найдете дизассемблер Trubo Pascal(кажется, под Amstrad PCW) и попробуйте собрать.
Правда, полученный код слегка убогий.
Нашел уже, спасибо. Буду разбираться. Вместе с ним идёт хорошая дока - анализ работы компилятора, где подробно описывается его функционирование.
Ещё нашел исходники TP 7, но они на паскале )
Одна и та же программа на z80 и i8086 :)
Вычисляет простые числа от 1 до 1000.
69559 69560
Нету двойки. Я тоже просуммировал для интереса. Просто складывал простые числа. Получил 76127.
Спасибо на найденную ошибку :)
Ошибка не в компиляторе, ошибка в подсчёте суммы. Исправлено.
у меня другие числа почему-то
https://1.bp.blogspot.com/-UwAbf5De4aM/W9Q_FhMIa_I/AAAAAAAAD1I/Ok4E5IMQopk6m25738vQ669KiYuYgcxMwCLcBGAs/s640/%2521void.png
"Собрал" компилятор под Z80. Всё равно работать не будет, так, чисто поржать.
210 килобайт :)
Bolt, Так это что получается, если его таки заставить работать, типа на клоне с мегабайтом памяти; то он, чисто ZX, сможет собрать себя-же и под ZX и под что-то другое, например под ПиСи? И его можно будет гонять, профайлить, дебажить и оптимизировать, ужимая до ста килобайт и меньше? :)
Ну, теоретически, да :)
Практически упирается в размер необходимой RAM, в скорость работы на Z80, и в мою скорость работы :)
Теперь понял. Но... не понимаю зачем это именно в такой форме. Потому что код может меняться при изменении программы за пределами этого "оператора", и даже в другой версии компилятора, а программа на ЯВУ, подогнанная под один процессор, может быть очень медленной на другом. согласен, что ценно только в паре с профайлером. Но его писать универсальный для всех 8, 16, 32 битных систем сложновато. А для z80 можно сделать, но и тут все не тривиально, вон их сколько всяких разных железяк напридумывали. Сейчас пока после каждой компиляции надо просматривать ассемблерный текст, что он там нагенерил( да еще если ключи разные оптимизации появятся). Писать подробный мануал, как писать быстрый и оптимальный код, тоже вряд ли захочется. А так пусть каждый разработчик выеживается, как знает. Ассемблер кто-то подзабыл, кому-то "религия" не позволяет много времени терять на проект. Тем более, если он кого-то заинтересовал, то можно и переписать на ассемблере. А как эскизный проект в самый раз на ЯВУ.
Про STM8 я писал статью для журнальчика Compel-а в 2009 году, поверхностная получилась не было уже особого стимула писать, а после они регулярно что-то по этому семейству писали
https://www.compel.ru/lib/ne/2009/2/5-novyie-8-bitnyie-mikrokontrolleryi-semeystva-stm8s
Камушек интересный, но дисплейчики к нему цеплять графические это на мой взгляд черезчур. Да и смысл? Цена у них с STM32 различается не сильно, а готовых решений с дисплеями для STM32 вагон. Для популяризации кросс-компилятора вполне достаточно. Но это дело хозяйское. Паскаль же и графика естественный тандем или нет? Впрочем может к современным кросс-ассемблерам для z80 графические пакеты тоже легко цепляются. Правда еще нужен удобный IDE+отладчик.
Почему STM8? Потому что если сейчас займусь ещё и STM32, то утону в регистрах, драйверах и RTL. Z80, 8086, STM8, PIC24, и даже 80386, если не лезть в защищённый режим - это то, что для меня просто и понятно. На этих платформах отрабатываю общую структуру компилятора, багов и так достаточно, а потом можно будет переходить на ARM и MIPS, которые пока для меня не совсем привычны.
STM8 не обязательно должен быть с графическим дисплеем, он может быть и "автономным". Читать датчики, отправлять данные по UART, мигать светодиодом.
Паскаль это не только графика, но и, например, переносимость программ. Драйвер SD-карты и файловой системы ext2 прекрасно работает на PIC24 и PIC32, надо - и на Спектруме запустим :)
Уфф, скользкая стезя. Одно дело продвижение кросс-компилятора на других платформах, и совсем другое введение в обиход железа "24-битный программный счетчик, с помощью которого стало возможным адресовать 16-мегабайтное адресное пространство памяти с отображенными в него регистрами. Мощность вычислительного ядра возросла, конечно, не в той степени, чтобы способствовать увеличению адресного пространства (хотя по сравнению с семейством ST7 добавлены операции деления 16-бит на 16-бит и 16-бит на 8-бит и более быстрого знакового умножения 8-бит на 8-бит). Большинство инструкций выполняются быстрее за счет трехстадийного конвейера, раздельной внутренней 32-разрядной шины для выборки инструкций и 16-разрядной шины данных. В командах, работающих с содержимым памяти, совмещены в одном машинном цикле операции чтения и записи. Все это дает возможность получить производительность процессора до 20 MIPS при тактовой частоте 24 МГц".
Хотя был такой компьютер "Искра-226" где основной процессор был совместим с материнским Hewlett Packard, а втыкалось
в него что угодно и порой в разы более мощное. Но тогда надо выбирать какое-то спектрумовское железо с шиной, а то переговоры-тары-бары с авторами. Лампочки вкл./выкл? Можно конечно, но для z80 и STM8 можно считать ускорителем. В свое время мы с Игорем Мазницей и на AT90S1200 что-то пытались со спрайтами делать, пока его в Полигедрон не унесло.
"Собрал" компилятор под Z80. Всё равно работать не будет, так, чисто поржать.
210 килобайт :)
Вот это дело! Не бросай тему.
Не бросаю :)
Вопросы по теме.
1. В каком Спектрум-совместимом компьютере много памяти (хотя бы 512 килобайт), и можно отображать любую страницу в любое место?
2. Как в нём переключать страницы памяти?
3. Как в нём работать с файлами? (открыть, закрыть, прочитать, записать)
4. Где взять эмулятор этого компьютера, и желательно под Линукс?
Пользуюсь FUSE, в нём есть Pentagon 512k и Pentagon 1024k, но в них меняются только верхние 16к, и пока не могу придумать как там всё разместить.
Dart Alver
21.07.2019, 13:11
Вопросы по теме.
Не шибко много отвечу, но ...
1. Посмотри в сторону EVO, ATM и прочих недописей ))
2. Я особо не вникал (максимум дров совместимости на верхнюю память) там вроде даже не один вариант а несколько. Поспрашивай у тех кто в теме, или доки почти.
3. Либо под тырдос (как в тырдос), либо под не тырдос (тазисы, cp-емы и недооси)
4. Нативно под линь походу аналога Xpeccy не видел, но настроить придётся повозиться. А через вайн можно и унриал попользовать.
есть Fuse под линупс.
насчет чтения файла - пример тут (http://codezx.mybb.ru/viewtopic.php?id=4)
И кто-то ставил NedoOS под эмулятор? Если да, под какой? Правда это было бы чудо какое-то, если micro-SD заработали с файлами FAT32.
Error404
22.07.2019, 12:18
И кто-то ставил NedoOS под эмулятор? Если да, под какой?
На сайте nеdopc есть текстовик от DimkaM с конфигом для unreal.
Правда это было бы чудо какое-то, если micro-SD заработали с файлами FAT32.
Лет десять уже как есть порт и FatFS (это FAT32) и чуть меньше uIP (TCP/IP). На Спеке это делал DimkaM, знаю т.к. ранее тоже делал такое же на Орионе и с интересом следил за развитием темы на Спеке. И никому было не надо. С одной стороны можно понять - оно шибко медленное, тем более не понятно отчего никому было не надо, а тут вдруг такой хайп.
На Спеке это делал DimkaM, знаю т.к. ранее тоже делал такое же на Орионе и с интересом следил за развитием темы на Спеке. И никому было не надо. С одной стороны можно понять - оно шибко медленное, тем более не понятно отчего никому было не надо, а тут вдруг такой хайп.из Unreal с NedoOS как файлы сливать на реальный спек под NedoOS? Хотя стоп, реальный-то Спек скоростные флэшки microSD поддерживает? И какой емкости максимум? Сорри за оффтоп, если есть более подходящий тред, давайте туда ( Это я все пытаюсь понять, что на сегодняшний день есть для софтоваятеля)
С sd-картами большого размера проблем ни разу не было (16гиг макс проверял)
из Unreal с NedoOS как файлы сливать на реальный спек под NedoOS?
Если именно в такой конфигурации, то если на реале есть ZXNetUSB можно хоть напрямую - под унрил запускаем веб-сервер 3ws. На реальном запускаем wget с нужными параметрами и скачиваем через сеть.
Fat32 и Fat16 поддерживаются. Единственное ограничение - на SD карте должен быть хотя бы один раздел (а не fat в корень флехи). Так же в последних версиях недоос есть поддержка USB-флеш накопителей, вставляемых в ZXNetUSB
Если есть вопросы по разработке приложений под nedoos обращайся. Всегда рад рассказать что знаю.
Error404
22.07.2019, 16:22
Если есть вопросы по разработке приложений под nedoos обращайся. Всегда рад рассказать что знаю.
Лучше бы все знания свести в документацию. Струтурная схема ОС, карта памяти, вызовы BDOS/BIOS, существующие библиотеки, консоль и графика, пример приложения. Это не так много труда как кажется на первый взгляд. Но муторно, да.
OrionExt
22.07.2019, 16:50
Знания Error404, сложно оценить. Одно понятно – они есть, ой и какие немаленькие.
Снова пилят OS. Оцените комп MSX. Там все есть. Так нет. И опять пилят OS для ZX, CPC и РАДИО-86РК – будет трешь факт. И что удивительно не могут круче MSX.
Из прошлого. Когда с дискогрызы грузилась игруха и музон АУ играл в ZX.
тем более не понятно отчего никому было не надо, а тут вдруг такой хайп
просто дешевые понты.
Снова пилят OS. я понял так, что под ZX EVO в ней все драйвера есть? Кто и как делает многозадачность не понял. В 1998 году вроде признали, что z80 для многозадачности не совсем тот девайс, так как MMU на него не навесить. Но за 20 лет видимо изобрели что-то. Страницы отображаются это хорошо, но видимо они и защищены как-то. В общем полагаюсь на разработчиков ZX EVO и NedoOS. Если это все можно корректно попробовать под эмулятором - еще лучше. Ну и надеюсь, что Паскаль из треда возможно будет под этой осью работать столь же впечатляюще, как и под виндой.
я понял так, что под ZX EVO в ней все драйвера есть? Кто и как делает многозадачность не понял. В 1998 году вроде признали, что z80 для многозадачности не совсем тот девайс, так как MMU на него не навесить. Но за 20 лет видимо изобрели что-то. Страницы отображаются это хорошо, но видимо они и защищены как-то. В общем полагаюсь на разработчиков ZX EVO и NedoOS. Если это все можно корректно попробовать под эмулятором - еще лучше.
SymbOS заявлена как multitasking. Теоретически вопрос в приложениях или в страницах памяти.
Если приложения запускаются и работают параллельно, то ось должна нарезать им память и защищать ее, пока они не завершатся. Как там отрезаются куски от страниц это дело техники. Я не думаю, что авторы еще поддержали их загрузку и выгрузку на диски и уж тем более флэш, если других носителей нет. Внутри приложения брать и отдавать память тоже можно, если есть поддержка от операционки, если нет беда, правда операционка может с запасом выделить и защитить при запуске приложения. Тогда по идее никак ни стеком ни по другому куда не надо не залезешь. Про SymbOS не читал. Сейчас погуглю. Аннотацию просмотрел. Не совсем понятно, есть ли уже сейчас драйверы под ZX EVO? А так если есть грамотное сравнение обеих систем применительно к ZX EVO дайте ссылку пожалуйста.
Слышал, что сектанты дендиконфы(TS-Conf) мечтает заполучить ось в виде исходников.
Слышал, что сектанты дендиконфы(TS-Conf) мечтает заполучить ось в виде исходников.
если авторы и разработчики активны, то зачем им исходники? И насколько я помню это приставка и нафига там ось? У меня есть мой "Побег" http://andrewsatan.narod.ru/pobeg.html и далее его реализации мечта не простирается. В следующем году мне уже 60, но в конце этого года младшей дочке будет годик. Назвали Алисой. Идея средней дочери, но я ее подготовил, начиная с мультиков про Алису, заканчивая "Гостьей из будущего". Сорри за оффтоп. И не будем его продолжать.
Error404
23.07.2019, 22:49
Слышал, что сектанты дендиконфы(TS-Conf) мечтает заполучить ось в виде исходников.
git clone же
Если приложения запускаются и работают параллельно, то ось должна нарезать им память и защищать ее, пока они не завершатся. Как там отрезаются куски от страниц это дело техники. Я не думаю, что авторы еще поддержали их загрузку и выгрузку на диски и уж тем более флэш, если других носителей нет. Внутри приложения брать и отдавать память тоже можно, если есть поддержка от операционки, если нет беда, правда операционка может с запасом выделить и защитить при запуске приложения. Тогда по идее никак ни стеком ни по другому куда не надо не залезешь. Про SymbOS не читал. Сейчас погуглю. Аннотацию просмотрел. Не совсем понятно, есть ли уже сейчас драйверы под ZX EVO? А так если есть грамотное сравнение обеих систем применительно к ZX EVO дайте ссылку пожалуйста.
ОС многозадачная (вытесняющая многозадачность). На данный момент до 8 задач поддерживается
К сожалению в силу архитектуры Z80 невозможно сделать защищённой память от грубых посягательств. Но если пользоваться для подключения памяти исключительно вызовами ОС, то проблем не будет. Т.е. по умолчанию твоему приложению выделяются 4 странички памяти, которые сразу подключены в окна. Ты можешь запросить через системный вызов еще страницы и подключать их, с помощью опять же системных вызовов, в любые окна по своему усмотрению, кроме нижнего. С нижним возможно в будущем тоже решится.
По поводу загрузки-выгрузки. В ос есть сервис NMI который позволяет сделать снапшот памяти в файл на диске (флешке и т.п.). "Старые" TRD/SCL/TAP приложения так же запускаются не портя систему. Им выделяются стандартные страницы пентагона (вроде) и отдается управление. Посредством NMI опять же можно выйти из такого приложение в ОС. Или сделать снапшот. Так же можно не выходить, а переключиться на ОС.
Например рассмотрим ситуацию, когда у нас есть игра с 2 образами trd. В процессе работы ей нужно то одну то другую дискету совать в дисковод. А у нас дисковод виртуальный. И как же быть? Выходим через nmi в ОС, монтируем другой образ, запускаем nmi и возвращаемся в приложение.
ОС многозадачная (вытесняющая многозадачность). На данный момент до 8 задач поддерживается
К сожалению в силу архитектуры Z80 невозможно сделать защищённой память от грубых посягательств. Но если пользоваться для подключения памяти исключительно вызовами ОС, то проблем не будет.для игр, по-моему более чем. Приложение запущенное до запуска игры сохранится( время и прочее сохранится), если кто-то подключен к сети все сообщения о новой почте придут( мессенджеров полагаю для системы еще нет?) это 3 задачи. А в самой игре "сохранялка" текущего состояния при переключении на вышеперечисленное, сохранение принудительное перед трудным участком в игре, чтобы не выпасть по gameover, фоновая подготовка до 2 других экранов в зависимости от действий игрока, и еще даже поддержка сетевого противника если игра не с компьютером 5 задач и всего 8. Так что Паскалю надо поддержать системные вызовы и можно приступать.Видел на вашем сайте, что у вас тоже сделан компилятор ЯВУ?
Error404
24.07.2019, 11:36
ОС многозадачная (вытесняющая многозадачность). На данный момент до 8 задач поддерживается
К сожалению в силу архитектуры Z80 невозможно сделать защищённой память от грубых посягательств. Но если пользоваться для подключения памяти исключительно вызовами ОС, то проблем не будет. Т.е. по умолчанию твоему приложению выделяются 4 странички памяти, которые сразу подключены в окна. Ты можешь запросить через системный вызов еще страницы и подключать их, с помощью опять же системных вызовов, в любые окна по своему усмотрению, кроме нижнего. С нижним возможно в будущем тоже решится.
Все это прекрасно. Но на самом деле пользователям не очень интересно (кроме как повод для дискурса), т.к. со времен MP/M (т.е. примерно половину столетия) уже известно, и, как оказалось, мало кому нужно (сужу по собственному примеру т.к. шел тем же путем в 90-х). А вот что-то пока еще проектирующим гражданам типа меня, что-то из этого ПО было бы интересно для бэкпорта или эмуляции. И тут хотелось бы понимать ширину кругозора разработчиков, сколько подводных камней они заложили,а чего обошли. Например, видно, что наличие на АТМ CP/M сподвигло сделать совместимой область 0..100 (до чего не допер автор Symbos и остался с 10 программами), но есть сомнения что этим все и ограничилось. Например, разрешение использования Спеком верхней памяти (по 0FFFF) делает код его приложений в бинарном виде непригодным для эмуляции под многими (если не сказать что под большинством) системами на Z80 где в верхнем ОЗУ лежит BIOS. И я не помню в документе по ссылке DimkaM (который ИМХО так и останется единственной документаций) чтобы там это было оговорено (не исключено что я подзабыл, может и такое быть). А вот например приложения CP/M прекрасно выполняются в режиме эмуляции и под UZIX и под MP/M и еще много где, т.к. там образовались удобные соглашения использования ОЗУ, позволяющие системным программам как подрезать ОЗУ пользователя в пользу функционала BIOS, так и отдать по максимуму (хотя и не всё), и все это не каким-то навороченным менеджером памяти, а тупо прописанными регламентами ее использования.
читать про оси интересно же, но надо ближе к Паскалю (:
читать про оси интересно же, но надо ближе к Паскалю (:
согласен! пока автор Паскаля имеет желание портировать под EVO(ATM) не надо его расхолаживать. Что же до эмуляторов, то когда там во что-то упрется процесс, если упрется, тогда и решать имхо
согласен! пока автор Паскаля имеет желание портировать под EVO(ATM) не надо его расхолаживать. Что же до эмуляторов, то когда там во что-то упрется процесс, если упрется, тогда и решать имхо
Автор имеет желание :) но сейчас занят, и вообще о портировании говорить рано. Кросс - пожалуйста, если будет описание системных вызовов и на чём экспериментировать.
Реального железа у меня нет, с запуском на эмуляторе тоже пока никакой ясности.
- - - Добавлено - - -
То есть сначала конечно надо сделать кросс, вычистить глюки компилятора, потом как-то извернуться с самим компилятором, которому нужны мегабайты, и тогда уже будет компилятор, запускающийся на Z80.
все сообщения о новой почте придут( мессенджеров полагаю для системы еще нет?) это 3 задачи.
Из мессенджеров есть рабочий клиент IRC.
Видел на вашем сайте, что у вас тоже сделан компилятор ЯВУ?
Хм. Не слышал о таком. В процессе разработки компилятор ассемблера и Си-подобного языка. Они рабочие, но возможности весьма скромны и не очень удобны в использовании на реале. И нет монитора-дебаггера под ОС.
Все это прекрасно. Но на самом деле пользователям не очень интересно (кроме как повод для дискурса), т.к. со времен MP/M (т.е. примерно половину столетия) уже известно, и, как оказалось, мало кому нужно (сужу по собственному примеру т.к. шел тем же путем в 90-х). А вот что-то пока еще проектирующим гражданам типа меня, что-то из этого ПО было бы интересно для бэкпорта или эмуляции. И тут хотелось бы понимать ширину кругозора разработчиков, сколько подводных камней они заложили,а чего обошли.
От совместимости с CP/M пришлось отказаться.
Для чего нужно? Ну например как ты иначе на спектруме напишешь игру больше с ресурсами больше 1МБ? А мегадему как будешь запускать >1Мб? Без ОС тут не обойтись. Никто так же не отменял возможность создать нужные приложение, которые могут использовать всю память. Тот же компилятор паскаля сможет использовать все эти возможности.
Автор имеет желание :) но сейчас занят, и вообще о портировании говорить рано. Кросс - пожалуйста, если будет описание системных вызовов и на чём экспериментировать.
Реального железа у меня нет, с запуском на эмуляторе тоже пока никакой ясности.
ну тогда так хотя бы. Это все-равно поддержит систему и железо, если начинать писать. ZX EVO приобрести, как я понимаю, не проблема.
http://nedoos.ru/#market Хотя надо бы понять, кто делает, и как и кто продает. Есть ли техподдержка, гарантия и
ремонт.
Только что-то я не понял из найденных отзывов, работает ли он качественно на обычный vga монитор ЖКИ -ный? Другие пришлось под напором жены вынести на помойку. А на собственный офис я пока не решаюсь, хотя есть вариант аренды в Смольном институте на Полюстровском недорогой.
А вот это? ( про компилятор)
http://speccy.info/NedoLang
можно ведь развивать до С++ подобного?
Black Cat / Era CG
24.07.2019, 18:16
Только что-то я не понял из найденных отзывов, работает ли он качественно на обычный vga монитор ЖКИ -ный.
Там же в документации есть. Не всякий подойдет, монитор должен уметь 50Гц. Есть утилита-образ для теста мониторов.
- - - Добавлено - - -
Тут ссылки на документацию и там же на эту утилитку: http://nedopc.com/zxevo/zxevo.php
Там же в документации есть. Не всякий подойдет, монитор должен уметь 50Гц. Есть утилита-образ для теста мониторов.
видно это то же, что винда в свойствах монитора отображает. Хотя попробую и на более древних своих компах свой монитор посмотреть. Видеокарта на писи тоже ведь в процессе участвует, так что не факт, что монитор не умеет 50 гц. Вот второй моник вроде должен подойти BENQ FP71G+ Частота обновления:строк: 30-82 кГц; кадров: 50-76 Гц Тогда не зря я его столько лет от жены спасал ))
На 8086 компилятор ложится замечательно. На 80386 - тем более.
На eZ80 тоже не сложно, хоть и бинарник больше, и работать будет медленней.
В Пентагон вроде можно засунуть, но из-за постоянного переключения страниц скорость будет никакая. Может потом по ходу дела что-то придумается.
Или задумаемся в очередной раз о компьютере на eZ80, пусть даже несовместимом? С многозадачностью, защищённой памятью, и прочим.
Или задумаемся в очередной раз о компьютере на eZ80, пусть даже несовместимом?
чип на нем кто будет проектировать? На сам Zilog надежд мало, он почти загнулся и поглощен другой компанией. Проще самим прикрутить к z80 MMU. А вот Intel живее всех живых, за несанкционированные эксперименты с архитектурой вздрючат мама не горюй! А за лицензию могут заломить. Впрочем, если кто-то может выбить задешево эту лицензию...
Какой чип? Какие эксперименты с архитектурой? Какая лицензия? Ничего не понял.
Допустим ваш компилятор под операционку захотят купить 10 000 человек. Чтобы продукт был коммерческим его придется убрать в один чип ( откройте любую китайскую приставку). Если бы Zilog процветал было бы два пути: 1) правильный - вести с ними переговоры о производстве на основе их ядра по лицензии; 2) неправильный - просто включить их ядро. Если чип не делать самостоятельно, то надо проектировать печатную плату. Проектируете вы, а производят все кто угодно, начиная с очень шустрых китайцев. Все комплектующие должны быть доступны не только в 2020 году, но и в 2030, и в 2040. И цена на них не должна расти, что буржуи широко практикуют перед тем как снять компоненты с производства. Вот как-то так. К ядрам Intel нельзя подступать на ракетный выстрел, так как в России их адвокатов как собак нерезаных, затаскают по судам и оставят без штанов. А вот на z80 все давно рукой махнули, также как на PDP8, PDP11, 6800, 6502, 6809 и т.п. С ними можете делать все, что заблагорассудиться, во всяком случае в России.
При чём тут покупка компилятора, который я продавать и не собирался? Как компилятор убрать в один чип, чтобы до него не добрались китайцы? Откуда в рассуждениях вообще взялся Intel и его адвокаты?
Я, наверное, настолько далёк от коммерции, что вообще не могу понять о чём речь.
При чём тут покупка компилятора, который я продавать и не собирался? Как компилятор убрать в один чип чтобы до него не добрались китайцы? Откуда в рассуждениях вообще взялся Intel и его адвокаты?
если компилятор запускать не на z80, а на 8086 или 80386 это ядра Intel-а, которые придется добавить к ядру z80 в один с ним чип( чтобы комп оставался спектрум семейства). 80386 это конечно значительно больше вентилей, да и шина 32 битная. 8086, вернее 8088 с 8 битной шиной, поэтому теоретически тандем z80+8088 на одном чипе реализовать возможно. Вопрос только как помечать в объектном коде, что для одного ядра, а что для другого. И хитрые link+locate делать придется. Куда проще была бы архитектура состоящая из 2 или 4 как в Полигедроне, или 5 ядер z80. В этом случае одно ядро могло бы работать на привычной реальщикам скорости, другое(ие) на более высоких скоростях. Ядра можно было бы расширить специфическими командами(что-то под sound, что-то под video и т.д.). Компилятор в чип убирать не надо. Если его или какие-то другие приложения надо защитить, достаточно в чип добавить специфические регистры и команды, если не какой-нибудь декодер. Отлаживается все на подходящей Alter-а или Xilinx, затем отдается китайцам и они делают вам нужный ASIC. И вуаля можно выходить на мировой рынок. Правда не знаю,
требуется ли нотификация ASIC-ов в фсб. Импортные процы, кроме микропроцессоров вот прикол! в которых есть что-то отличное от стандартных архитектур подлежат обязательной нотификации в фсб.
Вот теперь понял.
Запихнуть на один кристалл 8086 и Z80 - это идея на сколько долларов?
Все же 8086 хочется, а не 8088? Надо поглядеть выложено ли оно где. Если да, то проблем с Intel не должно возникнуть. А так здесь на форуме умельцы есть чипы программировать. В их разделе надо мулькануть, если готовое ядро найдется. Пусть оценят в вентилях чего стоит, тогда можно глянуть, что надо на макет из Альтер или Xilinxов. Ну а ASIC это уже отдельная "тема". Возможно и на нашем сайте народ пробовал это ядро и лишнее из него убрал
http://www.ht-lab.com/cpu86.htm но вроде сайт живой и можно с ними списаться, чтобы z80 туда же прикрутили, но надо схему нарисовать. Само же z80 ядро у посетителей этого сайта вылизанное точно есть, не оптимизированных ядер полно свободных для скачивания например и вот здесь
https://opencores.org
и они эту же работу могут проделать не хуже HT-Lab и во всяком случае наверное не дороже. А можно ценник и сравнить ))
Ну и вот покойный разработчик Спринтера, мир праху его
https://zx-pk.ru/threads/18233-a-davajte-razrabotaem-sobstvennyj-z80-na-vhdl.html
не знаю перенял кто эти заделы, осилил ли, я тогда здесь совсем не появлялся. Это вообще по моему был первый человек, который уже в 1997 году что-то начал делать для Спектрума на Alter-а. Уж не знаю, кто не дал ему раскрыть свой талант. Руководство ли Петерс, или иные коммерсанты от Спектрума. Но расширить инструментарий для Спектрума кросс-средствами на 8086 такое от него во всяком случае в те годы слышать не доводилось. Фирма сама торговала во всю и писишками, впрочем как и Зонов в Скорпионе. А могли такое вот, чем вы сейчас интересуетесь, вполне сделать и одни, и другие уже к 2000 году. Команданте Немо не мог. У него другая стратегия и тактика были.
Поковырял я ht-lab овский свободный архив. Документация слишком лаконична! Черт бы их драл! Но вроде чтобы тестировать их ядро все есть. Можно запустить в симуляторе, можно загрузить в Xilinx, собрав версию Паскаля так в их корковом ROM-е так и загружая ее через прописанный в ROM bootloader через корковый UART. Здесь одно не зер гут. Дешевые xilinx платы не знаю продаются ли в Aliexpress и eBay за копейки. У меня дома такая для Alter-а валяется. Что за симулятор и как там все будет работать не знаю. В общем надо пробовать. Единственное придется ваш компилятор подрихтовать под работу с UART, хотя...там что-то про DOSBOX. Загляните в их раздел cpu86\Software чтобы оценить необходимость переделки. Про ограничения на объем память ROM и RAM я ничего не понял, так как они толком не описали. Придется лазать по исходникам vhdl. И версия не обновлялась с 2009 года. Жива ли у них вся эта история сейчас?
Во какую штуку придумал для проверки компилятора.
Есть у меня исходник симулятора Z80 на Паскале. Собирается компилятором Free Pascal под Linux, проходит ZEXDOC без ошибок, ещё один тест почти без ошибок.
А что если его собрать при помощи BM-Pascal и запустить на Z80? :) А в этом симуляторе запустить ZEXDOC? :v2_dizzy_biggrin2:
Да, я извращенец :v2_tong:
Andrew771
09.10.2019, 22:38
А что если его собрать при помощи BM-Pascal и запустить на Z80? А в этом симуляторе запустить ZEXDOC?
намальная тема. :)
Я правильно понимаю что для переключения страниц в Basic-128 достаточно "poke 23388,16+n"? Мне чтобы загрузить несколько блоков bytes по разным страницам.
Oleg N. Cher
10.10.2019, 15:46
А разве не "OUT 8189,16+n" ? Или "OUT 253,16+n", если с неполной адресацией (я не знаю, поддерживается ли в Бейсике полная).
Просто out не работает, сам Бейсик постоянно порт переписывает, поэтому спрашиваю.
Bolt, Oleg N. Cher, Воистину параноидально нужно так: сначала POKE, чтобы бейсик знал и не попортил; потом, на бейсик не надеявшись, самолично OUT.
Bedazzle
11.10.2019, 07:03
Просто out не работает, сам Бейсик постоянно порт переписывает, поэтому спрашиваю.
Как не работает, если куча игрушек именно через ауты в бейсике и грузила файлы.
:/
OUT не работает. И в 128, и в 48.
70290
Bolt, А если в 128 после usr0?
А если, как я написал, сначала POKE, а потом OUT (в 128-м)?
USR 0 не работает, хотя по идее должно. Но зачем мне USR 0 в загрузчике с ленты? :)
POKE вроде достаточно даже без OUT.
70292
Нашёл инфу, что ПЗУ 128 вызывает интерпретатор из ПЗУ 48, а при переключении, так как порт не работает на чтение, использует содержимое памяти 23388.
http://hype.retroscene.org/blog/851.html
Симулятор в 32 килобайта укладывается. Сначала попробую запустить на 48к RAM с виртуальными 16к RAM, то есть с адресами 0000...7FFF будет работа напрямую, а в адресах 8000...FFFF сам симулятор и стек, запись в симуляторе заблокирована. Потом доделаю для 128к и запущу симуляцию 48к, в которой запущу тесты.
Как происходит отладка.
Есть симулятор на Паскале.
FreePascal(sim.pas)=sim.elf
bm-pascal(sim.pas)=sim.tap
А теперь запускаем sim.tap в sim.elf :)
https://zxpress.ru/article.php?id=1687
управлять переключением страниц из Бейсика можно путем занесения байта в системную ячейку BANK_M (подавать байт в порт в этом случае не нужно)
Вот на этом и остановимся.
Оно работает! Симуляция 16k на 48k :) То есть тот "интерпретатор" инструкций Z80 с кучей if...then, который я выкладывал, транслируется bm-pascal и запускается на Z80.
Два файла, TAP и часть исходника, чтобы примерно понимать что способен обработать bm-pascal.
TAP запускать только если совсем скучно. Сброс, выполнение ROM: тест памяти, интерпретатор Бейсика... Скорость работы примерно 1/3000, тест памяти длится около часа :) Запускать на эмуляторах на скорости 1000% или в режиме турбо.
70311
70310
Зачем это нужно? Это такой тест компилятора, теперь можно дальше заниматься кодогенератором и оптимизаторами.
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot