Ищу Си для Z80

[Shiny]

мне думается, что под cp/m Turbo Pascal 3 удобнее.

[Advertiser]

[SfS]

Чего вы срётесь? Я в SDC-NOINIT больше концепцию сборки разрабатывал. В принципе - не так важно какая модель.
Если писать на чистом С - вообще не важно какая модель. Их всего две:

1. вызывающая процедура освобождает стек.
2. Вызываемая процедура освобождает стек.

И ни там ни там явно не указано сколько стека занято.

Раз кто-то придумал опции, позволяющие обе модели, значит комуто это было надо.

[Oleg N. Cher]

но он, извините, написан в сжатые сроки и при царе горохе (и как написан!)

Без разницы как он написан. Прелесть инструмента разработки в его открытости, отзывчивости разработчиков и доступности. Смысла в бубнах и register переменных для параметров нет и не было. Кроме того, есть стандарты на модель вызова. А ещё хайтех имеет кривой и глючной оптимизатор, который использовать нельзя вообще. Вы его как юзаете? без оптимизатора или с ним? Беда, беда.

Всех желающих меня учить тонкостям хайтеха приглашаю в команду разработки подсистемы ZXDev3, на нём основанной. Что уже доказывает, что я ему уделил больше 5 минут. А хотя нет, от засратых хайтек-совместимых мозгов лучше держаться подальше. Вот sayman хотел выставить идиотами меня и разработчиков SDCC и z88dk, а выставил клиническим дураком себя.

Если писать на чистом С - вообще не важно какая модель.

Мы пишем для Z80, значит весь низкий уровень в кодах. И доля его больше в сравнении с прикладным слоем.

всего две:

1. вызывающая процедура освобождает стек.
2. Вызываемая процедура освобождает стек.

Есть больше моделей, например, передача в регистрах. Но не везде, ибо такая модель непереносима.

И ни там ни там явно не указано сколько стека занято.

В Паскаль-модели (__stdcall или в z88dk __z88dk_callee) и вызывающий, и вызываемый код точно знают, сколько параметров и каких типов используется. Именно поэтому процедура сама освобождает стек, зная, сколько именно надо освободить. Если ты имеешь в виду прямо из своего машкода узнать сколько стека занято, то в этой модели ты можешь точно узнать - посчитай сумму байт, занимаемую параметрами.

Сишная модель вызова (__cdecl или в z88dk обычная, по умолчанию) характерна тем, что вызываемый код точно не знает, сколько занимают параметры (функции с переменным числом параметров). Поэтому функция может вытащить один, а может несколько, сколько ей нужно. А вот вызывающий код всё равно ведь знает, сколько параметров ложил на стек, поэтому он их и снимает сам.

Для Z80 на машкодовых функциях эффективнее Паскаль-модель, почему - я уже говорил. На Си-функциях вообще неэффективно работать с параметрами, но лучше не придумали. Наверно всё же сишная модель маленько предпочтительнее, ибо не нужно снимать параметры (через адрес возврата, который лежит первее их), а сделать это можно только после завершения рабочего тела, в конце функции.

Раз кто-то придумал опции, позволяющие обе модели, значит комуто это было надо.

Ну да.

SfS, извини за ликбез, раз тебе это не надо, умолкаю. Не знал, что эти упыри набегут.

[Sayman]

Прелесть инструмента разработки в его открытости, отзывчивости разработчиков и доступности.

О! Щикарно! SDCC прям настолько открыт и его разрабы прям отзывчивы-отзывчивы и прям так доступны, что даже вот прям на любое msg отвечают и бегут править все-все баги. ага. удачки. на тот случай если ты не в курсе - автору sdcc давно плевать на компиляцию кода для z80. более того, новые версии - новые баги.

от sayman хотел выставить идиотами меня и разработчиков SDCC и z88dk, а выставил клиническим дураком себя.

лолшто? уважаемый, у вас проблемы с матчастью. не знаешь даже как стек работает. предлагаешь людям два раза делать инкремент стека - один раз компилятор в момент засовывания аргументов на стек и второй раз когда снимать нужно.

Кроме того, есть стандарты на модель вызова.

в эти стандарты __z88dk__чего-тотам не входит и никогда не входило. при этом htc как я помню может использовать регистры a, hl и iy когда переменная register.

глючной оптимизатор, который использовать нельзя вообще.

Давай конкретнее, какие баги в оптимизаторе? или ты не видишь разницы между asm файлом до и после оптимизатора?

Если говорить конкретно про баги sdcc, то вот мой список, который твои любимые афтары sdcc игнорят годами и исправлять не желают:
1. конструкция if(!(val = func1())) func2(); при которой val получает отрицательное число - не работает, т.к. компилятор упорно делает проверку через or a, т.е. на 0, не понимая, что результат может быть отрицательным. при этом с хайтех всё ОК.
2. sdcc не умеет работать с массивами вида char val[]; длинна которых явно не указана, но инициализируется позже. Примером является игра robo от hippiman`а. Эта игра собирается на старом sdcc 2.9.0, где такой проблемы нет. На всех версиях позже игра не работает, хотя и собирается 10 минут. в хайтехе с этим проблем нет!
3. в версии 3.7.0 сломали цикл while().
дальше даже продолжать нет желания. да, нет сомнений, sdcc полезный инструмент, местами и временами. он работает нативно под вендами, что очень удобно. и у хайтеха тоже есть не очень хорошие моменты меня бесящие (типа сколько-то байт мусора в конце файла). но, как уже сказали ранее, ты и 5 минут с ним не работал.
Остальное без комментариев))).

(__stdcall или в z88dk __z88dk_callee)

(__cdecl или в z88dk обычная, по умолчанию)

вот это вообще рукалицо. разрабы видимо вообще не знают стандартов языка и на ходу придумывают свои. __cdecl и __stdcall для sdcc как китайская грамота. но зато решили исковеркать и всё обозвать по своему. ништяг чё. и кстати, это не модель вызова, а соглашение вызова. чтобы более точнее понимать что это такое, вот:
раз
два

[SfS]

Есть больше моделей, например, передача в регистрах. Но не везде, ибо такая модель непереносима.

Я про SDCC. Там входящие параметры - считай только стек. Возвращаемые - L или HL. Усё. Нельзя вернуть структуру. Нельзя передать структуру. Только указатель...

- - - Добавлено - - -

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

Я могу посчитать, конечно. А как быть с функциями с переменным числом аргументов?

- - - Добавлено - - -

SfS, извини за ликбез, раз тебе это не надо, умолкаю.

Да почему) я это - про С-модель и пасквиль-модель в институте проходил. Просто не знал, что в SDCC есть и пасквиль-модель.

На самом деле всё сводится к SP-=N и SP+=N. Делает это вызывающая или вызываемая процедура - не так уж важно. Спор остро-тупоконечников получается

[Shiny]

Кстати, а насколько будет сложно написать свой компилятор с подкидным и школьницами? Наподобие ACTION! ?

[mastermind]

Кстати, а насколько будет сложно написать свой компилятор с подкидным и школьницами? Наподобие ACTION! ?

На Хаскеле, пожалуй, относительно несложно. Т.к. есть уже готовый парсер для C, препроцессор, и в общем язык для таких задач очень хорош. См.:
1. https://hackage.haskell.org/package/language-c
2. https://hackage.haskell.org/package/cpphs
3. https://stackoverflow.com/questions/...anguage-easier
4. http://www.stephendiehl.com/llvm/

Информация о Haskell на русском: https://github.com/bitemyapp/learnha...er/guide-ru.md

[Oleg N. Cher]

Я про SDCC. Там входящие параметры - считай только стек. Возвращаемые - L или HL. Усё. Нельзя вернуть структуру. Нельзя передать структуру. Только указатель...

А где ещё входящие параметры - не только стек?

В SDCC есть 32-байтный тип long. Результат этого типа возвращается в DE:HL

А как ты видишь передачу целой структуры? Ещё можно понять, если в ней два элемента по байту. А если много? Ведь эффективнее же по указателю работать с такой структурой.

Я могу посчитать, конечно. А как быть с функциями с переменным числом аргументов?

Я не уверен, что хоть какой-то компилятор для Z80 их поддерживает. Но если бы поддерживал, ты же в курсе как работать с такими параметрами? Через макросы va_list, va_start, va_arg и va_end. Я не ковырял их, как они устроены, но думаю, что они сами не знают, сколько и каких параметров передано.

А тебе для чего это вообще нужно? Я бы предложил не париться с проблемой, которой в Си для Z80 даже нет.

Просто не знал, что в SDCC есть и пасквиль-модель.

Раньше не было. Решили сделать для улучшения совместимости с z88dk.

- - - Добавлено - - -

О! Щикарно! SDCC прям настолько открыт и его разрабы прям отзывчивы-отзывчивы

Не жалуюсь. А если хочешь лучше - напиши сам, будет лишний повод тебя поругать.

более того, новые версии - новые баги.

Ну уж! Куда лучше - старые версии, старые баги. ;-)

htc использует регистр IY редко и почти никогда, а сохраняет его в каждом входящем фрейме. Каждая сишная функция в htc выполняет при входе код:

csv:	pop	hl		;return address
	push	iy
	push	ix
	ld	ix,0
	add	ix,sp		;new frame pointer
indir:	jp	(hl)

А при выходе из функции - такой:

cret:	ld	sp,ix
	pop	ix
	pop	iy
	ret

Всегда, Карл! Забудь про быструю работу с аргументами как страшный сон.

Кодовые функции напрямую в Си-исходник вставлять нельзя, нужны отдельные асм-файлы. Про баги в оптимизаторе мне писал Элвин Албрехт из команды z88dk, и я ему верю.

Всего этого лично для меня этого достаточно, чтобы закопать htc навсегда.

[Sayman]

csv: pop hl ;return address
push iy
push ix
ld ix,0
add ix,sp ;new frame pointer
indir: jp (hl)

ну вот я так и думал, что ты именно к этим двум функциям придерёшься. ОК. csv - делает то, что sdcc делает стандартно (соглашение __cdecl), но внутри каждой функции - выравнивает стек. налицо растрата памяти со стороны sdcc, в то время как хайтех экономит, заменяя это всё на 3 байта вызова csv. Аналогично и jp cret - обратное выравнивание стека после выхода из функции - sdcc снова тратит память. но ты упускаешь оджин момент - когда ты говоришь про sdcc, то ты подразумеваешь использование асмовых библиотек и вставок. Почему в контексте хайтеха ты это пропускаешь? тебе никто не запрещает делать внутри своей функции на асме popush для выравнивания стека или ld hl,2:add hl,sp и т.д. При выходе сделать ret без обращения к cret. Да, у хайтеха только __cdecl соглашение работает. когда его делали, __stdcall не существовало в природе. sdcc так же как и сам хайтех внутри сишного кода всегда использует ix, постоянно.

Про баги в оптимизаторе мне писал Элвин Албрехт из команды z88dk, и я ему верю.

Я не знаю кто это, но команде z88dk не верю, т.к. их компилятор, мягко говоря, плохой. на порядок хуже качество кода, даже чем у sdcc. поэтому список багов оптимизатора хайтеха в студию.

[Oleg N. Cher]

налицо растрата памяти со стороны sdcc, в то время как хайтех экономит, заменяя это всё на 3 байта вызова csv.

Ты не следишь за развитием SDCC, но хуже то, что ещё и вводишь людей в заблуждение своими устаревшими взглядами. Если использовать ключик --opt-code-size, то SDCC использует ровно те же 3 байта:

	call	___sdcc_enter_ix

Но, в отличие от htc, не будет сохранять IY, выигрывая на этом такты.

А если код критичен по скорости (--opt-code-speed), то будут выигрываться такты, htc опять в пролёте, ибо так не умеет. Ну упс.

когда ты говоришь про sdcc, то ты подразумеваешь использование асмовых библиотек и вставок. Почему в контексте хайтеха ты это пропускаешь?

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

Раз ты уж пропагандируешь юзать вставки на асме, то покажи-ка тут всем нам как их использовать без того, чтобы htc для асм-функций генерил call csv. В SDCC для этого есть __naked.

Опять же, две дополнительных модели передачи аргументов весьма экономят на кодовых функциях. И если ты так и не понял, как их юзать, это исключительно твои проблемы.

sdcc так же как и сам хайтех внутри сишного кода всегда использует ix, постоянно.

Но зато может не использовать IY. Это большой профит.

список багов оптимизатора хайтеха в студию.

Я не занимаюсь исследованием глюков htc.

Лучше список багов SDCC в студию. Вместе с примерами кода для их воспроизведения. Сделай хоть что-то полезное, а то только ноешь. Исходники свои на Си покажь, что ли. Посмотрим как ты круто кодишь на htc ;-)