Компилятор языка Паскаль - планы на будущее

[Shiny]

В общем, пробуйте, если что-то не работает - пишите, буду думать.

Есть что ешё сказать конкретно по этой версии? Или "не смотрел, но осуждаю"? Тогда давай прекратим этот диалог.

шаблон затрещал, но лопнул. пока что компилятор подавился на:

{$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.

[Bolt]

Вот, это конструктивный разговор, с исходниками
У меня уже давно "глаз замылился", поэтому и выложил, чтобы попробовали другие люди.
Например, сразу понял, что процедуры вывода текста лучше включить в mysystem.inc, заодно и переименовать его.
По коду...
1. В конце строки 17 закрыть оператор символом ";". Не знаю как именно правильно с точки зрения языка, буду посмотреть.
2. Для результата функции я везде использую переменную result. Если писать так как в исходнике возникает некая неоднозначность, которую я пока не придумал как разрулить. У меня в todo это есть.
3. Дополнил код, см. приложенный файл.

И да, с signed типами у меня там всё плохо, буду доделывать. Unsigned должны корректно работать.
Ещё неожиданно обнаружился баг с выводом чисел больше чем 1 429 496 729.

В архиве исправленный и дополненный исходник, .bin и .tap. Почему .bin такой большой? Да потому что в нём весь mysystem.inc. "Умная линковка" в очереди.

1.zip

[Shiny]

ладно, оставлю в покое тогда.
mysystem.inc не корректный. По идее inc(a) это a:=a+1, inc (a,5) это a:=a+5

и вопрос по ассемблерным вставкам: можно ли обращаться к переменным? например, LD DE,@a ?

[Bolt]

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]

Текстового редактора (IDE) нет и не планируется.

Рискну вызвать гнев автора (ибо не смотрел т.к. кажется еще рано), но влезу с пожеланиями.
Если сделать кодогенератор с генерацией отладочной информации и файлов символических ссылок, и добавить к этому движок эмулятора Z80 с делегацией функций дебугера (как минимум брикпоинты и загрузку в эмуль кода/окружения - простейшая задача для тутошних авторов эмуляторов), то можно сравнительно малой кровью прикрутить готовые несложные интерфейсы типа ProgrammersNotepad и получить source-level debugger IDE с редактором, подсветками, проектами и т.п. Такой опыт уже был у меня (я типа давал ТЗ ) и b2m (он допиливал свой эмулятор), и не взлетело это (ну как не взлетело, промежуточный результат был, но порой промахивался мимо брикпоинтов) исключительно из-за убожества SDCC (это такой кросс компилятор C с претензиями, под который делалось) и невозможности его допиливания в онлайне (да и в офлайне). Т.е. главное - наличие покладистого и головастого писателя компилятора, остальное найдем.

[b2m]

промежуточный результат был, но порой промахивался мимо брикпоинтов

Если отключить оптимизацию, то вроде не промахивался. Лично мне не нравилось, что плагин к ProgrammersNotepad - это один большой костыль. Тут надо копать в сторону протокола gdb и поддерживающих его IDE.

Но в одном ты прав - полнота отладочной информации от компилятора, это базис, без которого не стоит и начинать. А SDCC на тот момент предоставлял не всю нужную информацию, да и с локальными переменными там какой-то косяк был.

[OrionExt]

Error404, простейшая ли? Не видал таких. Отладочную инфу гнать по стандадарту. И возможно ли это. Платформы 8-бит даже от одного родителя сами себе противоречат. Вроде были попытки, но воз и ныне там. Хотя тема очень актуальная, для меня уж точно. Так и живем.

[Error404]

Если отключить оптимизацию, то вроде не промахивался. Лично мне не нравилось, что плагин к ProgrammersNotepad - это один большой костыль. Тут надо копать в сторону протокола gdb и поддерживающих его IDE.

Но в одном ты прав - полнота отладочной информации от компилятора, это базис, без которого не стоит и начинать. А SDCC на тот момент предоставлял не всю нужную информацию, да и с локальными переменными там какой-то косяк был.

SDCC на тот момент уже десятилетие разрабатывался, на секундочку. И содержал на выходе кучу всякого мусора, как в коде, так и в отладочной информации, что отражало отсутствие в головах разработчиков порядка. Когда я вижу такие вещи, то последующие метания авторов меня не интересуют (научился отсекать маргиналов на подлёте, чем немало сэкономил ресурсов и здоровья), так что не могу сказать полегчало там сейчас или нет (хотя помнится много позже в тредах по UZIX видел что таки не полегчало, т.к. UZIX собирается только какой-то особой промежуточной версией SDCC с неким опытным путем подобранным набором промежуточных же UZIX-only патчей).

[Bolt]

Рискну вызвать гнев автора (ибо не смотрел т.к. кажется еще рано), но влезу с пожеланиями.

Может и рано... Смотря что вы ожидаете там увидеть

Если сделать кодогенератор с генерацией отладочной информации и файлов символических ссылок

Да лехко. Но, наверное, не в этом году 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

[Shiny]

строчки с комментариями как раз то, что нужно.