Важная информация

User Tag List

Страница 7 из 7 ПерваяПервая ... 34567
Показано с 61 по 66 из 66

Тема: Осваиваем Hi-Tech C v3.09 для CP/M

  1. #61
    Guru
    Регистрация
    16.12.2008
    Адрес
    Kharkov, Ukraina
    Сообщений
    2,111
    Спасибо Благодарностей отдано 
    0
    Спасибо Благодарностей получено 
    4
    Поблагодарили
    4 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Alcoholics Anonymous Посмотреть сообщение
    На самом деле, вы, вероятно, можете получить 80% пути к идеальной компиляции, не прибегая к мегабайтам интеллекта. Это последние 20%, которые нуждаются в большом анализе и обработке. Sdcc имеет большую часть этого процесса, но он еще далек от совершенства, поэтому вы будете иногда видеть, как он избивается в сравнении с «более простыми» компиляторами.
    Поддерживаю на сто процентов.

    Эта фраза подтолкнула меня продолжить любительские суждения о кодогенерации вокруг Z80.

    Если пойти дальше и начать рассматривать такие продукты как НТС v7.80 pl2 и SDCC. Первое что я бы их "в лоб" не сравнивал. НТС v7.80 pl2 и SDCC преследовал / преследует разную конечную цель. Это главная мысль.

    От этого и с заядлым постоянством вспыхивающий тут холивар. Чем тоже грешил. Потому что не правильно позиционировал компилятор для себя. Конечно проще написать ???? и сказать "фу какая хрень".

    Вернемся к кодогенерации. Оба компилятора успешно подошли к планке 90% эффективности генерирования кода.

    НТС v7.80 pl2 коммерческий продукт с конечным финансированием и в дальнейшем товар, от которого получали прибыль. Остановился в своем развитии. И достаточно стабильным и прогнозируемым генерируемым кодом на выходе. Сужу на основе разбираемого мною дизассемблера НТС 3.09 с отключенной оптимизацией (о оптимизации чуть позже). Это мой выбор.

    SDCC исследовательский (научный) продукт с открытым кодом. Который преследует цель превысить 90% планку эффективности генерирования кода. И как показала не прекращаемая многолетняя работа над ним, постоянное шатание (отсюда не совместимость в версиях) и как тут было написано "прибегая к мегабайтам интеллекта" - пока с переменным успехом. А так современный компилятор вполне работоспособен при правильном подходе к нему. Что бы я отметил. Не подходит для новичков и у профессионалов с ним периодический происходят трудности в использовании.

    По поводу эффективных и не эффективных библиотек и ловли блох у каждого из компиляторов. Ставить одну библиотеку над другой и определенные ходы в кодогенерации, думаю, не стоит. Все они преследуют определенные цели в узких рамках Z80.

    Ага, оптимизатор. Новичкам я бы посоветовал его отключить. У меня на начальном освоении компилятора с ним возникли большие трудности, я долго не мог понять, что происходить и отчего так выборочно "плющит" генерируемый код. Оптимизатор может исказить сгенерированный код после кодогенератора до неузнаваемости.

    Ну и не все с этими оптимизаторами так просто
    Цитата Сообщение от Alcoholics Anonymous Посмотреть сообщение
    Я бы сделал то же самое, если бы работал в Hitech Существует больше шансов, что ошибки появятся с включенной оптимизацией, поэтому безопасным делом было бы скомпилировать компилятор с выключенной оптимизацией, если это так и было сделано.
    Я почти уверен, что НТС 3.09 ушел в релиз с выключенной оптимизацией. Надо только вспомнить, найти папку с проделанной работай и проверить. У кого "заряжены" инструменты может сделать это и сам.

    Ух, выговорился
    Последний раз редактировалось OrionExt; 30.03.2017 в 16:03.
    Электроника КР-02, MSX YIS-503IIR, Орион-128, Ленинград-2 (в работе), Pentagon-128k, MSX2 YIS-503IIIR, MSX-EXT, ...

  2. #61
    С любовью к вам, Yandex.Direct
    Размещение рекламы на форуме способствует его дальнейшему развитию

  3. #62
    Master Аватар для Oleg N. Cher
    Регистрация
    24.08.2007
    Адрес
    Днепропетровская обл.
    Сообщений
    928
    Спасибо Благодарностей отдано 
    213
    Спасибо Благодарностей получено 
    13
    Поблагодарили
    10 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Я не совсем согласен, что SDCC не подходит для новичков. Чем больше сообщество - тем лучше продукт, как правило. Даже новички могут получить от его использования свою пользу при подходе первого рода. И даже новички могут улучшить компилятор, дав, например, баг-репорт при подходе второго рода.

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

    Было бы интересно увидеть новичка, ковыряющегося с эмулятором CP/M или DosBox и Hi-Tech C. :-)

    По сути же наверно один z88dk даёт хотя бы генерацию в tap. А для SDCC же надо освоить хотя бы hex2bin.

    Впрочем, пускай новички прокачивают опыт, тоже хорошо. Правда, мы об абстрактных новичках, я что-то их деятельности не наблюдаю.

  4. #63
    Member
    Регистрация
    21.05.2006
    Адрес
    Canada
    Сообщений
    71
    Спасибо Благодарностей отдано 
    0
    Спасибо Благодарностей получено 
    0
    Поблагодарили
    0 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от OrionExt Посмотреть сообщение
    Вернемся к кодогенерации. Оба компилятора успешно подошли к планке 90% эффективности генерирования кода.
    Я думаю, что это слишком великодушно Мой ручной код asm намного лучше, в 3 раза меньше и быстрее в сложных функциях. Частично причина заключается в том, что все эти компиляторы начинаются с препятствия - они уже решили, что локальные переменные будут в стеке, и они будут проиндексированы с индексным регистром. В очень небольших функциях, как sdcc, так и HTC могут покончить с этим. Это совершенно противоположное тому, что происходит, когда я пишу сборку от руки. Я начинаю с того, что не хочу использовать индексные регистры, если мне это не нужно. Это одно решение вносит большой вклад в разрыв между компиляторами и людьми при написании кода z80.

    Учитывая ограничение стекового фрейма, производительность компилятора обычно не ужасна. Иногда я приятно удивлён кодом sdcc, который появляется в небольших плотных циклах с 8-битными величинами. Иногда я вижу нечто, что производит обратное впечатление: P Эти вещи я стараюсь исправить в пост-обработке. HTC более шаблонный и предсказуемый в своем поколении кода. Это редко будет действительно плохой код, но вы редко будете так что-то действительно умный. Когда я вижу вывод sdcc, ясно, что генератор кода z80 не рассматривает множество опций и не требует правильного использования индексных регистров (поэтому z88dk может получить намного лучший код из sdcc с помощью -reserve-regs- Iy "). Имейте в виду, что современный компилятор разделен между интерфейсом, в котором происходит весь анализ, и фоновым объектом, где лежит генератор кода. Это генератор кода, который, как я считаю, все еще имеет возможности для улучшения.

    Скрытый текст


    I think that is being much too generous My hand written asm code is much better, in the range of 3x smaller and faster in complex functions. Part of the reason is all these compilers begin with an impediment - they have already decided local variables will be on the stack and they will be indexed with an index register. In very small functions, both sdcc and HTC may do away with this. This is quite the opposite to what happens when I write assembly by hand. I begin by saying I don't want to use the index registers unless I really have to. That one decision contributes a great deal toward the gap between the compilers and humans when writing z80 code.

    Given the stack frame constraint, the compiler performances are not usually terrible. Sometimes I am pleasantly surprised by code sdcc comes up with in small tight loops involving 8-bit quantities. Sometimes I see something that makes the opposite impression :P These things I try to fix up in post-processing. HTC is more formulaic and predictable in its code generation. It will rarely be really bad code but also you will rarely so something really clever. When I see sdcc's output, it's clear that the z80 code generator is not considering many options and doesn't cost the use of index registers properly (this is why z88dk can get much better code out of sdcc with "--reserve-regs-iy"). Keep in mind a modern compiler is divided between a front-end where all the analysis happens and a back-end where the code generator lies. It's the code generator that I believe still has room for improvement.
    [свернуть]


    По поводу эффективных и не эффективных библиотек и ловли блох у каждого из компиляторов. Ставить одну библиотеку над другой и определенные ходы в кодогенерации, думаю, не стоит. Все они преследуют определенные цели в узких рамках Z80.
    Компилятор C состоит из двух частей - переводчика языка и библиотеки. Оба одинаково важны, чтобы позволить программисту выполнить что-либо. Вы можете попробовать делать программы с GCC без GLIBC, но вы не очень далеко. Аналогично попытайтесь построить что-нибудь с помощью Visual Studio, не связывая время выполнения c microsoft или его код win32 gui. Библиотека является неотъемлемой частью компилятора, и поэтому стандарт C определяет, что должно быть там, как минимум. Если компиляторам не хватает больших порций, их полезность уменьшается.

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

    Я могу показать вам результаты нескольких тестов, которые показывают, какой код библиотеки различий может сделать. Zsdcc будет использовать библиотеку языков ассемблера, а sdcc будет использовать свою собственную библиотеку, написанную на C. Имейте в виду, что zsdcc - это sdcc с некоторыми улучшениями, так что это почти сравнение равных.

    Скрытый текст


    A C compiler has two parts - the language translator and the library. Both are equally important to allow a programmer to accomplish anything. You can try to make programs with GCC without GLIBC but you won't get very far. Likewise try to build anything with Visual Studio without linking microsoft's c runtime or its win32 gui code. The library is an essential part of the compiler and that's why the C standard specifies what has to be in there at minimum. If compilers are missing large portions, their usefulness is decreased.

    On the z80, the libraries take on a new importance because the compilers are not able to generate nearly as good code as hand written assembler.

    I can show you a few benchmark results that demonstrate the difference library code can make. zsdcc will be using an assembly language library and sdcc will be using its own library written in C. Keep in mind zsdcc is sdcc with some improvements so this is almost a comparison of equals.
    [свернуть]


    PI BENCHMARK (mainly testing 32-bit integer math)

    Код:
    Z88DK March 2, 2017
    zsdcc #9833 / new c library / small int math
    6246 bytes less page zero
    
    cycle count  = 5278798872
    time @ 4MHz  = 5278798872 / 4*10^6 = 22 min 00 sec
    
    *****
    
    SDCC 3.6.5 #9842 (MINGW64)
    6844 bytes less page zero
    
    cycle count  = 8700157418
    time @ 4MHz  = 8700157418 / 4*10^6 = 36 min 15 sec
    
    SDCC implements its 32-bit math in C.
    Это на 63% медленнее, а дополнительные 600 байтов исходят из того факта, что 32-битная математика sdcc написана на C.

    Если мы сможем принять большой размер кода, zsdcc может быть скомпилирован с использованием библиотеки с быстрыми целыми числами:

    Скрытый текст


    That's 63% slower and an extra 600 bytes coming from the fact sdcc's 32-bit math is written in C.

    If we can accept a large code size, zsdcc can be compiled using a fast integer library:
    [свернуть]


    Код:
    Z88DK March 2, 2017
    zsdcc #9833 / new c library / fast int math
    8997 bytes less page zero
    
    cycle count  = 1739403552
    time @ 4MHz  = 1739403552 / 4*10^6 = 7 min 15 sec
    Это теперь в пять раз быстрее, чем sdcc. И снова основное различие - библиотека.


    Еще один большой результат - математика с плавающей запятой. Это из ЭТАПЫ WHETSTONE:

    Скрытый текст


    That's now five times faster than sdcc. Again the main difference is the library.


    Another large result is in floating point math. This is from the WHETSTONE BENCHMARK:
    [свернуть]


    Код:
    Z88DK March 2, 2017
    zsdcc #9833 / new c library / math48 float package
    24 bit mantissa + 8 bit exponent (internally 40+8)
    6153 bytes less page zero
    
    cycle count  = 916537242
    time @ 4MHz  = 916537242 / 4x10^6 = 229.1343 seconds
    KWIPS        = 100*10*1 / 229.1343 = 4.3643
    MWIPS        = 4.3643 / 1000 = 0.0043643
    
    *****
    
    SDCC 3.6.5 #9842 (MINGW64)
    24 bit mantissa + 8 bit exponent
    14379 bytes less page zero
    
    cycle count  = 2184812093
    time @ 4MHz  = 2184812093 / 4x10^6 = 546.2030  seconds
    KWIPS        = 100*10*1 / 546.2030 = 1.8308
    MWIPS        = 1.8308 / 1000 = 0.0018308
    
    SDCC implements its float library in C.

    Sdcc более чем в два раза медленнее с плавающей библиотекой, написанной на C (и посмотрите на разницу в размерах). Это намного хуже, чем то, что появляется на поверхности. В z88dk математическая библиотека внутренне реализует 48-битное число с плавающей точкой с 40-битной мантиссой. Библиотека sdcc должна иметь дело только с 32-битным плавающей точкой и 24-битной мантиссой. Это значительное преимущество в производительности. Плавающая библиотека sdcc должна иметь более чем у z88dk. На самом деле цифры должны быть наоборот.


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

    По крайней мере, столь же важным, как скорость выполнения, является размер программы. В больших программах существуют очень большие различия в размере кода между sdcc и zsdcc. Частью этого является улучшение генерации кода (улучшение размера кода на 5-10%, хотя есть случаи с краями до 50%), но большая часть кода библиотеки. Я видел экономию 10 тыс. И более на больших скомпилированных программах, главным образом из-за различий в размере кода библиотеки. В программе размер, HTC и другие, как правило, избивают SDCC. И снова это обычно сводится к размеру кода библиотеки. У HTC и других есть свод библиотечного кода, реализованного в ассемблере, тогда как sdcc имеет очень мало этого. В этих сравнениях z88dk также выигрывает у HTC и других в размере кода, в значительной степени благодаря тому, что z88dk имеет намного больший объем библиотечного кода, написанного на ассемблере.


    Постобработка кода не вносит такой же вклад в экономию средств. Я считаю, около 5-10% размера является типичным. Воздействие на время выполнения может быть больше, если преобразования происходят внутри циклов. Одной из важных функций этих преобразований является исправление некоторых ошибок генерации кода sdcc, что позволяет нам надежно использовать «-reserve-regs-iy» и получать улучшенную генерацию кода из самого sdcc.

    Скрытый текст


    sdcc is more than twice as slow with a float library written in C (and look at the size difference). It's much worse than what appears on the surface. In z88dk, the math library internally implements a 48-bit float with a 40-bit mantissa. sdcc's library only has to deal with a 32-bit float and a 24-bit mantissa. That's a significant performance advantage sdcc's float library should have over z88dk's. In fact the numbers should be the other way around.


    These two benchmarks show an obvious difference because most of the running time is in the library code rather than the compiler-generated code. In most code, execution time won't be dominated so much by library code but this library performance advantage will penetrate everywhere.

    At least as important as the execution speed is the program size. In large programs there are very big differences in code size between sdcc and zsdcc. Part of it is better code generation (~5-10% code size improvement although there are fringe cases up to 50%) but a larger part is the library code. I have seen savings of 10k or more on large compiled programs mainly due to differences in library code size. In program size, HTC and others tend to beat sdcc as well. And again this is usually down to library code size. HTC and others do have a body of library code implemented in assembler whereas sdcc has very little of this. In these comparisons, z88dk also beats HTC and others in code size due in large part to the fact z88dk has a much larger body of library code written in assembler.


    The post-processing of code doesn't contribute as much to savings. I find around 5-10% size is typical. The impact on running time can be larger if the transformations happen inside loops. One important function of these transformations is to fix some of sdcc's code generation bugs that allows us to reliably use "--reserve-regs-iy" and get improved code generation out of sdcc itself.
    [свернуть]


    SDCC...Что бы я отметил. Не подходит для новичков и у профессионалов с ним периодический происходят трудности в использовании.
    Я не уверен, что я полностью согласен с этим. Его проще использовать в том смысле, что он лучше соответствует стандартам и может компилировать больше программ, чем другие компиляторы z80. Запуск на современной машине, а не, скажем, CP / M отнимает искусственные ограничения на размер программы.

    По сравнению с HTC и IAR, чего ему действительно не хватает, это несколько стандартных crts. Я видел, что многие люди борются с этим просто потому, что они не знали, как писать crt. После компиляции у вас есть .ihx-файл, который легко превратить в двоичный файл с помощью HEX2BIN. Кроме этого, я бы оценил его равным в простоте использования с IAR и HTC 309 (без учета ограничений, введенных CPM). У HTC 750 есть простая IDE, которая может понравиться некоторым пользователям, но я нахожу только отягчающей.

    Z88DK имеет преимущества перед всеми этими компиляторами: - передний интерфейс позволяет легко смешивать c, asm, макросы и т. Д. Он может хранить отдельные библиотеки для любой машины z80 с выделением из строки компиляции. Крошки уже сделаны. Постобработка включает в себя шаг с использованием «APPMAKE», который может превращать выходные двоичные файлы в COM, ROM, TAP, DSK, независимо от цели. Одна строка для компиляции любого количества исходных файлов в требуемую форму вывода, и для экспертов есть много вариантов. ZSDCC работает внутри этой инструментальной цепи, поэтому «SDCC» также можно использовать в этом простом режиме.

    Скрытый текст


    I'm not sure I'd wholly agree with that. It's easier to use in the sense it has better standards conformance and can compile more programs than the other z80 compilers. Running on a modern machine instead of, say, CP/M takes away artificial limits on program size.

    In comparison with HTC and IAR what it is really lacking is a few more standard crts. I've seen many people struggle with it simply because they did not know how to write a crt. After a compile you have an .ihx file which is easy to turn into a binary with HEX2BIN. Other than that I'd rate it equal in ease of use with IAR and HTC 309 (ignoring the limits introduced by CPM). HTC 750 has a simple IDE that some may like but I only find aggravating to use.

    Z88DK has usage advantages over all these compilers :- the front end makes it easy to mix c, asm, macros, etc. It can hold separate libraries for any z80 machine with selection from the compile line. The crts are already made. The post processing involves a step using "APPMAKE" that can turn the output binaries into COM, ROM, TAP, DSK, whatever the target needs. One line to compile any number of source files to the required output form and there's a lot of options in between for experts. ZSDCC runs inside this toolchain so "SDCC" can be used in this easy manner too.
    [свернуть]

  5. #64
    Master Аватар для Oleg N. Cher
    Регистрация
    24.08.2007
    Адрес
    Днепропетровская обл.
    Сообщений
    928
    Спасибо Благодарностей отдано 
    213
    Спасибо Благодарностей получено 
    13
    Поблагодарили
    10 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Alcoholics Anonymous, Ваши сообщения на форуме всегда очень подробны и интересны. Благодарю!

  6. #65
    Guru
    Регистрация
    16.12.2008
    Адрес
    Kharkov, Ukraina
    Сообщений
    2,111
    Спасибо Благодарностей отдано 
    0
    Спасибо Благодарностей получено 
    4
    Поблагодарили
    4 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Alcoholics Anonymous, cпасибо. Очень полезные посты для понимания нюансов построения компиляторов для Z80.

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

    z88dk уникальный проект, который рассчитан именно на Z80 платформу.
    Электроника КР-02, MSX YIS-503IIR, Орион-128, Ленинград-2 (в работе), Pentagon-128k, MSX2 YIS-503IIIR, MSX-EXT, ...

  7. #66
    Guru Аватар для Shiny
    Регистрация
    19.01.2017
    Адрес
    г. Арзамас
    Сообщений
    2,119
    Записей в дневнике
    36
    Спасибо Благодарностей отдано 
    0
    Спасибо Благодарностей получено 
    13
    Поблагодарили
    6 сообщений
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    где бы раскопать процедурку printf? Получается .AS без печати.

Страница 7 из 7 ПерваяПервая ... 34567

Информация о теме

Пользователи, просматривающие эту тему

Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)

Похожие темы

  1. Осваиваем микрокомпьютер (1 и 2 ч.)
    от kas29 в разделе Пресса
    Ответов: 2
    Последнее: 06.02.2020, 01:27
  2. Видеоподкаст: "Old Gold Tech"
    от unbeliever в разделе Разное
    Ответов: 1
    Последнее: 12.06.2010, 13:41

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •