Если бы у Медноногова был БК ?..

[Oleg N. Cher]

3 причины не пользоваться IAR. Даже если закрыть глаза на то, что вам придётся хрензна откуда его скачивать и долго крякать.

• 1. Есть в IAR регистровые параметры? Нет. В SDCC есть. Кстати, появились за последние 10 лет.

• 2. Есть там разные модели вызова? Нет. В SDCC есть ещё три модели вызова, помимо родной __cdecl

• 3. IAR ложит два байтовых параметра в виде двух слов. SDCC в виде двух байтов.

Всё это весьма, знаете ли, важно, когда стыкуешь Си с ассемблером. Где важно экономить, особенно скорость, которая и так невелика.

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

SDCC улучшают постоянно. Вы просто не следите. Ваше очень ценное мнение зафиксировано 10 лет назад и с тех пор не пересматривалось. Но это, согласитесь, Ваша проблема.

Байтовые параметры на стек ложить не может сам Z80.

Одной командой не может, а двумя запросто.

PUSH AF
INC SP

Но главное: IAR ложит два байтовых параметра как два слова. Это уродски.

Да. Именно это и грустно.

А я о чём. УМХО. Упоротое мнение хрен оспоришь.

Он вообще не меняется. Там 0 прогресса. Как 10 лет назад генерил нерабочий уродский код, таким и остался.

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

Кстати, уверен, что Вы не сделали никакого вклада в развитие SDCC. Складывается впечатление, что весь Ваш вклад в развитие компайлеров Си свёлся к тому, что Вы просто спёрли IAR и собрали им три хелоуорлда.

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

а зачем использовать Паскаль если на БК есть бейсик ?

1. Бейсик был не на всех БК, на некоторых был прошит Фокал.

2. Даже если делать на Бейсике и закрыть глаза на то, что на части БК работать не будет, всё равно не обойтись без кодовых вставок. Бейсик жрёт доп. память и снижает скорость работы программы.

3. Тогда как скомпилированный GCC машкод рулит на всю мощь. И я настолько стараюсь обойти несовместимости разных моделей БК, что не юзаю ПЗУ вообще.

Хватит причин?

[Advertiser]

[Sayman]

1. Есть в IAR регистровые параметры? Нет. В SDCC есть. Кстати, появились за последние 10 лет.

SDCC, вплоть до версии 4.1.0 не умеет "в стоке", без использования "соглашений" использовать регистровые параметры. только снапшот 4.1.12 этому научился. IAR это умеет 20 лет как без всяких соглашений. почитай мануал хоть к нему, чтоли. там всё расписано.

В SDCC есть ещё три модели вызова, помимо родной __cdecl

начиная с 4.1.12 он автоматом применяет новую модель вызовов и то, только к генерируемым функциям. функции в его родной либе всё ещё в старой модели. хоть 10 моделей пусть будет, это без толку, т.е. его родная либа это кошмар! банальный mul/div long для Z80 написан на СИ(!!!), какая уж там оптимизация?!

3. IAR ложит два байтовых параметра в виде двух слов. SDCC в виде двух байтов.

IAR, как и любой компилятор сей/паскалей для Z80 всегда делает PUSH RR, где RR какая то регистровая пара. НО, IAR, если параметры не динамические, сначала будет юзать регистры и только потом стек. опять таки - RTFM.

PUSH AF
INC SP

ОООЙ, это так важно, положить 1 байт на стек и и потратить потом ещё 6 тактов на inc sp. что за чушь?

SDCC улучшают постоянно. Вы просто не следите.

я могу с вами поспорить, что кодогенерация между 3.4.0 и 4.1.0 байт в байт одинаковая! так где изменения и улучшения?

но, во всём этом самое забавное то, что старый Solid C, написанный ещё в 1995 году для MSX и портированный под Спринтер в 2004 году, выдаёт код более компактный и быстрый, чем SDCC, хотя местами и есть у Солида затупы, но какой си без затупов то?!)))
а пресловутый пипхоле - чего там, чего? если посмотреть в его исходники, то становится очевидно, что вся оптимизация сводится к перебору шаблонов которые вкомпилированы. и можно задавать хоть 2000000 глубину этой пипки, результата не будет, а время компиляции растягивается на несколько минут.

я тут сижу над FatFS, переделки там кое какие, оптимизации. так вот, sdcc, Solid-C, IAR участвуют в этом. на текущий момент, SDCC даёт самый худший результат (и это на 4.1.12). даже Солид, у коиторого отродясь нет лонгов, путём вкарячивания "внешней" имитации умудряется обгонять SDCC. При этом, у SDCC весьма странная любовь к индексным регистрам, не смотря на попытку использовать static. А вот IAR и Solid весьма легко от индексных регистров отказываются.

который бы сам запилил оптимизирующий компилятор

оптимизатор может быть внешним, в виде отдельного ехешника. почти все существовавшие компиляторы (большая их часть) сей для z80 имели именно отдельные оптимизаторы. IAR, SDCC, Solid как раз те, в которых оптимизатор внутренний.