Вид для печати
соглашусь, хотя при наличии нормальной и документированной асмовой библиотеки, выигрыш в скорости разработки будет не очень большойЦитата:
Сообщение от boo_boo
СИ не знает, знает компилятор :) кста, большинство твоих "притензий" относятся к кривым компиляторам, а не к языку/библиотекамЦитата:
Сообщение от Robus
Ха ... Ещё бы ... Исключительно к компиляторам ... Так же как и ПиЦи, если бы его "кодеры" были порядочными, то и на ПиЦи было бы большенство шедевров.Цитата:
Сообщение от elf/2
"Притензии" к людям которые подходят к языку с точки зрения школьной программы. Тестирование заполнения экрана FF'ами, это кощунство. Никто не трёт память FOR'ом ии WHILE'ом. Только отдельно написанная процедура затирания куска памяти на !!!асме!!!. Вот меня и коробит, когда я это вижу. Просто, более серьёзный подход должен быть. А по-скольку 99% людей к таким вещам подходят как начинающий программист, я просто уверен что для таких нужно поставить рамки не более 10% кода на СИ !!! Конечно я такое делать не буду, но каждый уважающий себя CODER обязан свою работу доводить до идеала. Этим и славились Speccy, Atari и подобные монстры. Эти машины взростили примеры на которые по сей день равняются все ... А ПиЦи взростил комерческий подход и винду со всякой хренью. Вот поэтому в этом посте постоянно шла речь о том, что "где-то нельзя выкладывать кряк", или "там денег стоит" или ещё что-то в подобном жанре. А если создатель печётся о доходе а не о профессионализме, то тут только руками можно развести.
Ибо Мир делится на Созедателей и Потребителей. А деньги это потебление.
И сколько не говоите мне "Лень двигатель прогресса", двигают его трудом а не ленью. Вам это колесо кто-то придумает, а у вас едиственная фраза на всё будет - "зачем его изобретать заново". Ну спалите все книги к чёрту ... Чё их хранить, есть в электронном виде, можно экранизацию псмотреть ... Прогресс же ... Перестаньте читать ... Вот вам и лень ...
Так что мой компилятор будет всё учитывать ...
Добавлено через 13 минут
О самом главном: Кто пользуется "mak" файлами ??? В котором описание проекта, типа там путь к INCLUDE'ам, какой файл является MAIN'ом ???
Дело в том, что объем проектов сильно вырос (я тут не считаю программирование микроконтроллеров - это отдельный сегмент) и если заниматься вылизыванием кода, то программистам в пересчете на человеко-час будут платить очень мало - на хлеб не хватит. Поэтому раз железо позволяет неоптимальный код, то хвала такому железу. :)Цитата:
Сообщение от Robus
Очень нужен ANSI-совместимый С (С99 совместим или нет? Я не шибко силен в стандартах) для Z80 (в идеале, работающий на собственно 8-битке) с прямой, т.е. некорявой и неглючной поддержкой 32-битных целочисленных типов. Я пока ни одного такого не видел. Чем все прочие немного ближе к идеалу HiTech C (хотя бы ANSI-совместим), но он страшно глючный (имеется в виду CP/M версия).Цитата:
Сообщение от Robus
вот я пишу демокод... первые 10% времени занимает чисто создание эффектов - 90% кода по объему - потом 90% времени уходит на собирание и фикс этих эффектов в кучу (дему), настройка переменных для эффектов и прочая дребедень - это даже меньше 10% кода в результате, но занимает процентов 90 времени.
короче - все как положено =)
в принципе последний этап может было бы проще писать на каком-нить языке выше ассемблера - чтобы малейшая ошибка в цифре не приводила к сбросу.
Привет ROB F! Приятно видеть что кровь в твоих жилах все еще _кипит_ как и много лет назад в начале 90-х ! :) Более того забавляет _ВСЕ ЕЩЕ ТО!_ рвение переписать всех и вся на ASM-e.Цитата:
Сообщение от Robus
Слабо мне верится что ты проникнешся моим коментарием по поводу твоего рвения создать СВЕРХ оптимальный С-компилер для Z80. Поэтому ПРОШУ! все кто со мной согласен скажите что я прав а те кто не согласен скажите что не прав. А коментарий такой:
1. не надо лазить в make file-ах и писать свой жутко оптимальный "gnu make" на ASM-e;
2. не нaдо писать свой С компилер с нуля на ASM-e;
3. нужно разобратся немного с open source компилерами типа sdcc и gcc, посмотреть какие есть недостатки у текущих генераторов кода для Z80, внести улучшения и выложить свои patch-и для других на обсуждение (если что-то толковое сделаешь - поверь народ вкомитит твои изменения);
Во блин ... Заинтригован ... Кто это ??? Мне да же не стало обидно что "ROB F" без точки !!!Цитата:
Сообщение от bigral
Не буду ... Будет на TMT-Pascal'е, и да же под всвеми любимую винду !!!Цитата:
Сообщение от bigral
Компилятор будет безусловно на TMT-Pascal'е, но, прости, сам компилятор уже начат и он на асме ... Не всё, основа анализа стринга, и подобное только на асме, то есть основное мясо !!! Собственно это уже сделано ... Это просто ... Щас библиотеку приоритетных команд сделаю, потом макросы, а там уже и первая версия ...Цитата:
Сообщение от bigral
На это тратить время не буду ... Мне и так на работе за простой влетит ... А не достатки я и сам понимаю, уже писал компилятор ASAM, кстати, практически язік программирования ...Цитата:
Сообщение от bigral
Безусловно !!! Это очевидно !!!Цитата:
Сообщение от Error404
Для этого я уже сделал ASAM там вообще ничего не надо собирать, автоматом любіе лоадеры компилятся !!! Но традиция останется старая, Linker будет в виде асмасково кода, компилирующийся моим же ASAM'ом, то есть будет выполнять тривиальную задачу ... Но, вообще-то, советую обратить внимание на ASAM, покрайненй мере со сборкой проблем не будет ... Странно, я думал что эти проблемы уже решены в SjASMPlus ...Цитата:
Сообщение от psndcj
Добавлено через 5 минут
Кстати ... В последней версии ASAM'а я выложил MATH модуль ... Я так же на праздниках делал дему ... Убил около стни зайцев одним выстрелом, дописывая этот модуль ... Любую математику можно реализовать ... Вообщем в последнем эффекте сделал всё за пару часов ...
Robus, так ты кросс-компилятор хочешь написать? а зачем, хочешь, чтобы он генерил более оптимальный код, чем sdcc/z88dk/gcc/IAR etc...? надо ли оно... все равно критичные по ресурсам части проги на асме писать, а для некритичных частей и существующие кросс-компилеры подходят.Цитата:
Сообщение от Robus
(...а твой компилятор, подозреваю, под дос будет? а то для юниксоидов/макосников дос ваще не вариант, и для виндузоидов неудобно :rolleyes:)
эх, вот если б нативный спектрумовский компилятор С99, вот это я понимаю :v2_rolley
проблема не в подключении лоадера - это как раз делается на раз в любом ассемблереЦитата:
Сообщение от Robus
основное время занимает распихивание эффектов по банкам и обработка взаимодействия между модулями... ну и всякий мелкий код - типа управление перемещениями, то есть работа с переменными...
Более того, написаный на асме цомпилятор будет абсолютно непортируемым.
Ну ... От этого практически не уйти ... Это и есть искусство программирования на Speccy ... Однако я тебя очень хорошо понимаю, и сам по сегодняшний день в каждом новом проекте пытаюсь применить новые способа решения подобных задач. В мучаемом мною уже два года CuberDie, я использовал макросы для заполнения банков.Цитата:
Сообщение от psndcj
В итоге код выглядит так:
Ну а распаковка становится банальна, знаешь адрес в странице, знаешь куда "FreeSpace" ...Код:;Выбираем сегмент в который мы поместим эффект (кусок) демки для будущего исполнения
;Мой "SEG" переключится на страницу 17 и установит адрес компиляции (ORG) в предыдущий для этой странице, допустим сейчас это 49152, этот адрес будет храниться в переменной "BP17.S" но из этого значения вычитается 49152, то есть размер блока для 17-ой страницы составляет "0"
SEG 17
SuperEffect_2 ;Адрес эффекта в сегменте
;Адрес компиляции останется в 49152, но компилятор будет думать что весь код помещается по адресу "FreeSpace", допустим это 35000. Этот адрес указывает на свободное место для исполнения эффектов. Допустим у нас их 10-ть. Первый уже тут лежал, в "FreeSpace" исполнился и освободил память. То есть каждый эффект будет компилироваться с учёт адреса на "FreeSpace".
PHASE FreeSpace
;Далее, собственно, эффект ... Ну типа покажем на экране мега картинку.
HALT
LD HL,22528
LD DE,22529
LD BC,767
LD (HL),L
LDIR
LD HL,MegaPicture
LD DE,16384
LD BC,6144
LDIR
WaitLinePos (16,3) ;Типа ждём музыку
LD B,3
LDIR
RET
MegaPicture IncTRD "GFX\gfx.trd","pic.c" ;Загружаем мегакартинку из TRD модуля
UNPHASE
;Далее самое главное. Пакуем то что накодили. Сейчас адрес $=49152+6912+??? короче много.
DSQ.Pack SuperEffect_2,$-SuperEffect_2
;Теперь адрес $=49152+??? вообщем теперь меньше.
EndSeg ;Теперь в "BP17.S" сохранён новый размер этого блока
Единственное, что нужно - следить за размером блока в странице, что бы не вылез за 16384 !
Как ты сам понимаешь, сам эффект можно хранить как отдельный файл, его инклудить между PHASE и UNPHASE ... Таким образом легко автоматизировать труд. И главное - постоянно запакованная дема до последнего битика.
А вот как такое реализовывать в СИ я не представляю. А в асме нет ограничений и можно писать практически на языке высокого уровня. Да и что над от него ? Математику, возможность в скобках получать значения из процедур. Это главное. А это всего 10%.