Языки программирования

[maximk]

Без проблем конвертится в исходник с мнемоникой Z80.
Я его кстати выкладывал на форуме в составе ZXCPM, перекомпилировав для работы с адреса 6100h.

Это все да, но код-то он продолжает генерить для i8080 и поддержка возможностей z80 не появится Кроме того, кажется bdsc сразу компилит в бинарный код, без ассемблерного текста, что не есть хорошо.

[SfS]

Нормально будет работать. А нужно это затем, чтобы не изобретать велосипеды, а брать готовый код с любых платформ. Есть готовые реализации, к примеру, TCP/IP или FAT32 на С, причем в минималистской форме (специально для 8-биток). Да и вообще, я часто натыкался на необходимость в 32 bit int, а перелопачивать и отлаживать код из-за того, что компилер не может - это сильно на любителя.

Вообще-то int в С для всех 8 и 16битных процов, какие я знаю - 16 бит, а не 32 (AVR, PIC, I196 и т.п.). Так зачем это менять ? Пользуйся 32х битным long int или 64битным long long int. Причем, только там, где это надо. Это оптимальнее.

[maximk]

Так зачем это менять ?

Я так понял, что никто и не предлагал менять, проблема в том, что в некоторых недокомпиляторах C тип long int отсутствует как класс или равен тоже 2-м байтам
Про long long я вообще молчу

[Sonic]

Кто-нибудь находил версию GCC для зетника? А то перерыл дофига ссылок- одни огрызки информации, ни сорцов ни бинарника. А то была б маза собрать его же исходники для спека Ибо писать с нуля- весьма ресурсозатратно...

AFAIK хрена с два ты его найдешь. Насколько я понимаю, оного существовать не может, по крайней мере для классического z80. Может для eZ80 разве что... У gcc тоже есть свои ограничения - он ориентирован на 32-бит/64-бит архитектуры и Flat memory Model. На ZX нет ни того ни другого.

Есть другие открытые компиляторы, в том числе и z80-targetted.
К тому же C для ZX был бы действительно интересен, если бы еще и работал на самом ZX (я сторонник нативных систем). А даже если и представить себе, что gcc неким образом существует на Спеке, то Hello world он компилировал бы несколько суток. gcc - слишком сложная система с использованием нескольких промежуточных представлений.

[Error404]

Вообще-то int в С для всех 8 и 16битных процов, какие я знаю - 16 бит, а не 32 (AVR, PIC, I196 и т.п.). Так зачем это менять ? Пользуйся 32х битным long int или 64битным long long int. Причем, только там, где это надо. Это оптимальнее.

Шутите?
Оффтоп: Встречает "новый русский" (HP) "старого русского" (СР):
НР: - Кака дела?
СР: - Да вот, не ел три дня...
НР: Ну, братан, надо же себя как-то заставлять....


А если серьезно: рад бы воспользоваться, да не могу: не знает тип long (32bit) большинство 8080/Z80 С-компиляторов (по крайней мере нативных, не писюковых) . Естественно я имел ввиду long... Т.е. принципиальную возможность использовать нативный целочисленный тип 32bit.

[Vitamin]

Т.е. принципиальную возможность использовать нативный целочисленный тип 32bit.

нативного типа такого нет. а для нативных типов int(16) и char(8) определены только операции + и -. Все остальное (*/%) пишется ручками. Равно как и весь перечень операций для long(32) и float(32). Будет поддержка- будет и тип.

[Error404]

нативного типа такого нет. а для нативных типов int(16) и char(8) определены только операции + и -. Все остальное (*/%) пишется ручками. Равно как и весь перечень операций для long(32) и float(32). Будет поддержка- будет и тип.

Пишется все что угодно и без привязки к процессору. Причем тут аппаратная поддержка? Любая арифметика делается. Только заниматься этим должно ядро компилятора (это я имел ввиду под определением "нативные типы" - с терминологией беда ). Чтобы не изобретать в дополнительных библиотеках порнографию вида:

typedef LONG char*
void plus32(LONG op1, op2, result)
{}
...
char[4] a,b,c;
...
plus32(a,b,c); /* c=a+b */

А этим занимаются почти все компиляторы для 8080/Z80 - сделают 3 типа, а остальное - "сделай сам". Понятно, что при таком подходе никакие сторонние исходники не используешь (везде принято писать c=a+b , а не plus32(a,b,c) ), да и тормозит такая "прикрученная сбоку" арифметика жутко.
У авторов Hitec C в CP/M-версии компилятора, к примеру, хватило ресурсов реализовать все наиболее часто требуемые типы на все том же z80. Пока это лучшеее, что я видел из бесплатного (считая и PC-версии) и, похоже, единственное более-менее пригодное к употреблению.

[Vitamin]

А этим занимаются почти все компиляторы для 8080/Z80 - сделают 3 типа, а остальное - "сделай сам".

Насколько С++ шаг вперед по отношению к С (class:perator ...), настолько и эти компилеры шаг назад от того же С...
В нормальных компилерах есть runtime-библиотека, где определены функции типа __inttofloat __add32 etc, и компилятор занимается их вызовом. Т.е. обеспечиваются все нативные (для языка) типы, причем глубоко пофиг какой разрядности целевая машина.
Грустно, что такого не сделали...

[fk0]

Расскажи пожалста, каким это образом макросы могут замедлить прогу?

"Комментарии в теле цикла замедляют его работу".
А ты не знал? Низачот.

Я тоже когда-то бегал и махал флагом "асм рулит, С для ленивых". Но

Я в принципе и сейчас бы помахал. В асме реализуются зачастую концепции недоступные в недоязычках вроде паскаля. Или C. Хотя в последнем не всё так уж и плохо, по сравнению с некоторыми... Тоже прикручиваются внешние макропроцессоры. Или можно потихоньку мигрировать в сторону C-два-креста.

Так что для промышленного программирования лучше С пока ничего не придумали.

Java. Там этих страшных указателей нет. И выделение памяти абсолютно-безопасносное (пока OOM killer не отстрелит).
Да нет, самое главное конечно не это. Самое главное -- что
Java обучаются даже бабуины. Вся суть в этом.

ЗЫ. Все-таки на спеке не хватает С с приличной средой разработки...

www.htsoft.com? Никто не отменял. Только Z80 супротив современных RISC цпу, даже самых мелких мелкоконтроллеров,
сильно проигрывает. В том смысле, на него C с его парадигмой распределения памяти хреновенько ложится.

[fk0]

8051@1Мгц вполне терпимо исполняет код, собранный из С. И это с учетом одного-единственного 16-разрядного регистра.

Ага, DPTR. Мне уже второй год страшно в листинги из-за этого заглядывать. Вот я и не заглядываю. В small model оно, к слову, гораздо веселее.

Кто-нибудь находил версию GCC для зетника? А то перерыл дофига ссылок- одни огрызки информации, ни сорцов ни бинарника. А то была

Несколько лет назад в инете искалось и у меня сохранился патч на GCC старой (2.x, вроде 2.95 примерно) версии GCC. Другое дело, что тут очень много зависит от:

1) кодогенерирующего backend'а. А он явно плох.

2) стиля кодирования. Он от писишного должен отличаться.

Я бы сказал, на 50% возможность использования компилятора определяется программистом. И на 50% компилятором. Компилятор -- повторяюсь -- hitech. Лучше для Z80 (и PIC) нет.

маза собрать его же исходники для спека Ибо писать с нуля- весьма ресурсозатратно...

small C compiler.