Это все да, но код-то он продолжает генерить для i8080 и поддержка возможностей z80 не появится :) Кроме того, кажется bdsc сразу компилит в бинарный код, без ассемблерного текста, что не есть хорошо.Цитата:
Сообщение от caro
Вид для печати
Это все да, но код-то он продолжает генерить для i8080 и поддержка возможностей z80 не появится :) Кроме того, кажется bdsc сразу компилит в бинарный код, без ассемблерного текста, что не есть хорошо.Цитата:
Сообщение от caro
Вообще-то int в С для всех 8 и 16битных процов, какие я знаю - 16 бит, а не 32 (AVR, PIC, I196 и т.п.). Так зачем это менять ? Пользуйся 32х битным long int или 64битным long long int. Причем, только там, где это надо. Это оптимальнее.Цитата:
Сообщение от Error404
Я так понял, что никто и не предлагал менять, проблема в том, что в некоторых недокомпиляторах C тип long int отсутствует как класс или равен тоже 2-м байтам :)Цитата:
Сообщение от SfS
Про long long я вообще молчу :)
AFAIK хрена с два ты его найдешь. Насколько я понимаю, оного существовать не может, по крайней мере для классического z80. Может для eZ80 разве что... У gcc тоже есть свои ограничения - он ориентирован на 32-бит/64-бит архитектуры и Flat memory Model. На ZX нет ни того ни другого.Цитата:
Сообщение от Vitamin
Есть другие открытые компиляторы, в том числе и z80-targetted.
К тому же C для ZX был бы действительно интересен, если бы еще и работал на самом ZX (я сторонник нативных систем). А даже если и представить себе, что gcc неким образом существует на Спеке, то Hello world он компилировал бы несколько суток. gcc - слишком сложная система с использованием нескольких промежуточных представлений.
Шутите? :v2_biggr:Цитата:
Сообщение от SfS
Оффтоп: Встречает "новый русский" (HP) "старого русского" (СР):
НР: - Кака дела?
СР: - Да вот, не ел три дня...
НР: Ну, братан, надо же себя как-то заставлять....
:smile:
А если серьезно: рад бы воспользоваться, да не могу: не знает тип long (32bit) большинство 8080/Z80 С-компиляторов (по крайней мере нативных, не писюковых) . Естественно я имел ввиду long... Т.е. принципиальную возможность использовать нативный целочисленный тип 32bit.
нативного типа такого нет. а для нативных типов int(16) и char(8) определены только операции + и -. Все остальное (*/%) пишется ручками. Равно как и весь перечень операций для long(32) и float(32). Будет поддержка- будет и тип.Цитата:
Сообщение от Error404
Пишется все что угодно и без привязки к процессору. Причем тут аппаратная поддержка? Любая арифметика делается. Только заниматься этим должно ядро компилятора (это я имел ввиду под определением "нативные типы" - с терминологией беда :smile: ). Чтобы не изобретать в дополнительных библиотеках порнографию вида:Цитата:
Сообщение от Vitamin
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-версии) и, похоже, единственное более-менее пригодное к употреблению.
Насколько С++ шаг вперед по отношению к С (class::operator ...), настолько и эти компилеры шаг назад от того же С...Цитата:
Сообщение от Error404
В нормальных компилерах есть runtime-библиотека, где определены функции типа __inttofloat __add32 etc, и компилятор занимается их вызовом. Т.е. обеспечиваются все нативные (для языка) типы, причем глубоко пофиг какой разрядности целевая машина.
Грустно, что такого не сделали...
"Комментарии в теле цикла замедляют его работу".Цитата:
Сообщение от Vitamin
А ты не знал? Низачот.
Я в принципе и сейчас бы помахал. В асме реализуются зачастую концепции недоступные в недоязычках вроде паскаля. Или C. Хотя в последнем не всё так уж и плохо, по сравнению с некоторыми... Тоже прикручиваются внешние макропроцессоры. Или можно потихоньку мигрировать в сторону C-два-креста.Цитата:
Я тоже когда-то бегал и махал флагом "асм рулит, С для ленивых". Но
Java. Там этих страшных указателей нет. И выделение памяти абсолютно-безопасносное (пока OOM killer не отстрелит).Цитата:
Так что для промышленного программирования лучше С пока ничего не придумали.
Да нет, самое главное конечно не это. Самое главное -- что
Java обучаются даже бабуины. Вся суть в этом.
www.htsoft.com? Никто не отменял. Только Z80 супротив современных RISC цпу, даже самых мелких мелкоконтроллеров,Цитата:
ЗЫ. Все-таки на спеке не хватает С с приличной средой разработки...
сильно проигрывает. В том смысле, на него C с его парадигмой распределения памяти хреновенько ложится.
Ага, DPTR. Мне уже второй год страшно в листинги из-за этого заглядывать. Вот я и не заглядываю. В small model оно, к слову, гораздо веселее.Цитата:
Сообщение от Vitamin
Несколько лет назад в инете искалось и у меня сохранился патч на GCC старой (2.x, вроде 2.95 примерно) версии GCC. Другое дело, что тут очень много зависит от:Цитата:
Кто-нибудь находил версию GCC для зетника? А то перерыл дофига ссылок- одни огрызки информации, ни сорцов ни бинарника. А то была
1) кодогенерирующего backend'а. А он явно плох.
2) стиля кодирования. Он от писишного должен отличаться.
Я бы сказал, на 50% возможность использования компилятора определяется программистом. И на 50% компилятором. Компилятор -- повторяюсь -- hitech. Лучше для Z80 (и PIC) нет.
small C compiler.Цитата:
маза собрать его же исходники для спека :) Ибо писать с нуля- весьма ресурсозатратно...