мне думается, что под cp/m Turbo Pascal 3 удобнее.
мне думается, что под cp/m Turbo Pascal 3 удобнее.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Чего вы срётесь? Я в SDC-NOINIT больше концепцию сборки разрабатывал. В принципе - не так важно какая модель.
Если писать на чистом С - вообще не важно какая модель. Их всего две:
1. вызывающая процедура освобождает стек.
2. Вызываемая процедура освобождает стек.
И ни там ни там явно не указано сколько стека занято.
Раз кто-то придумал опции, позволяющие обе модели, значит комуто это было надо.
Без разницы как он написан. Прелесть инструмента разработки в его открытости, отзывчивости разработчиков и доступности. Смысла в бубнах и register переменных для параметров нет и не было. Кроме того, есть стандарты на модель вызова. А ещё хайтех имеет кривой и глючной оптимизатор, который использовать нельзя вообще. Вы его как юзаете? без оптимизатора или с ним? Беда, беда.
Всех желающих меня учить тонкостям хайтеха приглашаю в команду разработки подсистемы ZXDev3, на нём основанной. Что уже доказывает, что я ему уделил больше 5 минут. А хотя нет, отзасратыххайтек-совместимых мозгов лучше держаться подальше. Вот sayman хотел выставить идиотами меня и разработчиков SDCC и z88dk, а выставил клиническим дураком себя.
Мы пишем для Z80, значит весь низкий уровень в кодах. И доля его больше в сравнении с прикладным слоем.
Есть больше моделей, например, передача в регистрах. Но не везде, ибо такая модель непереносима.
В Паскаль-модели (__stdcall или в z88dk __z88dk_callee) и вызывающий, и вызываемый код точно знают, сколько параметров и каких типов используется. Именно поэтому процедура сама освобождает стек, зная, сколько именно надо освободить. Если ты имеешь в виду прямо из своего машкода узнать сколько стека занято, то в этой модели ты можешь точно узнать - посчитай сумму байт, занимаемую параметрами.
Сишная модель вызова (__cdecl или в z88dk обычная, по умолчанию) характерна тем, что вызываемый код точно не знает, сколько занимают параметры (функции с переменным числом параметров). Поэтому функция может вытащить один, а может несколько, сколько ей нужно. А вот вызывающий код всё равно ведь знает, сколько параметров ложил на стек, поэтому он их и снимает сам.
Для Z80 на машкодовых функциях эффективнее Паскаль-модель, почему - я уже говорил. На Си-функциях вообще неэффективно работать с параметрами, но лучше не придумали. Наверно всё же сишная модель маленько предпочтительнее, ибо не нужно снимать параметры (через адрес возврата, который лежит первее их), а сделать это можно только после завершения рабочего тела, в конце функции.
Ну да.
SfS, извини за ликбез, раз тебе это не надо, умолкаю. Не знал, что эти упыри набегут.
Последний раз редактировалось Oleg N. Cher; 27.05.2018 в 04:10.
О! Щикарно! 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 и __stdcall для sdcc как китайская грамота. но зато решили исковеркать и всё обозвать по своему. ништяг чё. и кстати, это не модель вызова, а соглашение вызова. чтобы более точнее понимать что это такое, вот:(__cdecl или в z88dk обычная, по умолчанию)
раз
два
Последний раз редактировалось Sayman; 27.05.2018 в 08:06.
Я про SDCC. Там входящие параметры - считай только стек. Возвращаемые - L или HL. Усё. Нельзя вернуть структуру. Нельзя передать структуру. Только указатель...
- - - Добавлено - - -
Я могу посчитать, конечно. А как быть с функциями с переменным числом аргументов?
- - - Добавлено - - -
Да почему) я это - про С-модель и пасквиль-модель в институте проходил. Просто не знал, что в SDCC есть и пасквиль-модель.
На самом деле всё сводится к SP-=N и SP+=N. Делает это вызывающая или вызываемая процедура - не так уж важно. Спор остро-тупоконечников получается
Кстати, а насколько будет сложно написать свой компилятор с подкидным и школьницами? Наподобие 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
Последний раз редактировалось mastermind; 27.05.2018 в 17:02.
А где ещё входящие параметры - не только стек?
В SDCC есть 32-байтный тип long. Результат этого типа возвращается в DE:HL
А как ты видишь передачу целой структуры? Ещё можно понять, если в ней два элемента по байту. А если много? Ведь эффективнее же по указателю работать с такой структурой.
Я не уверен, что хоть какой-то компилятор для Z80 их поддерживает. Но если бы поддерживал, ты же в курсе как работать с такими параметрами? Через макросы va_list, va_start, va_arg и va_end. Я не ковырял их, как они устроены, но думаю, что они сами не знают, сколько и каких параметров передано.
А тебе для чего это вообще нужно? Я бы предложил не париться с проблемой, которой в Си для Z80 даже нет.
Раньше не было. Решили сделать для улучшения совместимости с z88dk.
- - - Добавлено - - -
Не жалуюсь. А если хочешь лучше - напиши сам, будет лишний повод тебя поругать.
Ну уж! Куда лучше - старые версии, старые баги. ;-)
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 навсегда.
ну вот я так и думал, что ты именно к этим двум функциям придерёшься. ОК. csv - делает то, что sdcc делает стандартно (соглашение __cdecl), но внутри каждой функции - выравнивает стек. налицо растрата памяти со стороны sdcc, в то время как хайтех экономит, заменяя это всё на 3 байта вызова csv. Аналогично и jp cret - обратное выравнивание стека после выхода из функции - sdcc снова тратит память. но ты упускаешь оджин момент - когда ты говоришь про sdcc, то ты подразумеваешь использование асмовых библиотек и вставок. Почему в контексте хайтеха ты это пропускаешь? тебе никто не запрещает делать внутри своей функции на асме popush для выравнивания стека или ld hl,2:add hl,sp и т.д. При выходе сделать ret без обращения к cret. Да, у хайтеха только __cdecl соглашение работает. когда его делали, __stdcall не существовало в природе. sdcc так же как и сам хайтех внутри сишного кода всегда использует ix, постоянно.csv: pop hl ;return address
push iy
push ix
ld ix,0
add ix,sp ;new frame pointer
indir: jp (hl)
Я не знаю кто это, но команде z88dk не верю, т.к. их компилятор, мягко говоря, плохой. на порядок хуже качество кода, даже чем у sdcc. поэтому список багов оптимизатора хайтеха в студию.Про баги в оптимизаторе мне писал Элвин Албрехт из команды z88dk, и я ему верю.
Последний раз редактировалось Sayman; 27.05.2018 в 20:03.
Ты не следишь за развитием SDCC, но хуже то, что ещё и вводишь людей в заблуждение своими устаревшими взглядами. Если использовать ключик --opt-code-size, то SDCC использует ровно те же 3 байта:
Но, в отличие от htc, не будет сохранять IY, выигрывая на этом такты.Код:call ___sdcc_enter_ix
А если код критичен по скорости (--opt-code-speed), то будут выигрываться такты, htc опять в пролёте, ибо так не умеет. Ну упс.
А потому что я использую Си только как бэк-энд и не имею желания играться с распихиванием асм-кода в сто разных файлов.
Раз ты уж пропагандируешь юзать вставки на асме, то покажи-ка тут всем нам как их использовать без того, чтобы htc для асм-функций генерил call csv. В SDCC для этого есть __naked.
Опять же, две дополнительных модели передачи аргументов весьма экономят на кодовых функциях. И если ты так и не понял, как их юзать, это исключительно твои проблемы.
Но зато может не использовать IY. Это большой профит.
Я не занимаюсь исследованием глюков htc.
Лучше список багов SDCC в студию. Вместе с примерами кода для их воспроизведения. Сделай хоть что-то полезное, а то только ноешь. Исходники свои на Си покажь, что ли. Посмотрим как ты круто кодишь на htc ;-)
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)