Оберон-клуб «ВЄДАsoft»

Твердыня модульных языков
Текущее время: 17 дек 2017, 15:53

Часовой пояс: UTC + 2 часа

Начать новую тему Ответить на тему  [ Сообщений: 3 ] 
Автор Сообщение
 Заголовок сообщения: Z88DK news
СообщениеДобавлено: 13 янв 2017, 02:30 
Не в сети
Аватара пользователя

Сообщения: 846
Откуда: Днепропетровская обл.
Z88DK v1.99B Released at Sourceforge:

It's been a year since the last release so it was time for another. This is another transitional release on the way to version 2.0 and hopefully we'll get there for the next one.

Some notes:

Z88DK - v1.99B 10 Jan 2017

Z88dk is a development kit for z80 computers that contains the tools and assembly language libraries necessary to develop code in either C or assembly language for z80-based machines.

Over 50 different z80 machines have CRTs in the toolkit, allowing C programs to be compiled for them out-of-the-box.

There are two C compilers supported (sccz80 and sdcc), two independent C libraries included (the classic and new), an assembler/linker/librarian (z80asm), and a data compression tool (zx7).

This is the second transition release in anticipation of v2.0.

Install Instructions:

Home Page:
Includes link to the nightly builds.


Introduction to Compiling Using the Classic C Library:
Examples in z88dk/examples

Introduction to Compiling Using the New C Library:
Examples in z88dk/libsrc/_DEVELOPMENT/EXAMPLES

Compiling for Generic z80 Embedded Systems Using the New C Library:

--8<----- list of changes below -----------------------


* The win32 and osx packages are complete and now include the zsdcc & zsdcpp binaries. zsdcc is z88dk's customization of the sdcc compiler. Other users can compile zsdcc from source.

* A VS2015 solution file is now available in z88dk/win32 for building all z88dk binaries except zsdcc & zsdcpp. Instructions for building zsdcc & zsdcpp can be found in the install instructions link above.

ZCC - Compiler Front End

* M4 has been added as an optional macro pre-processor. Any filename ending with extension ".m4" will automatically be passed through M4 and its output written to the original source directory with the ".m4" extension stripped prior to further processing. The intention is to allow source files like "foo.c.m4", "foo.asm.m4", "foo.h.m4" and so on to be processed by M4 and then that result to be processed further according to the remaining file extension.

* In conjunction with the above, a collection of useful M4 macros has been started in "z88dk.m4" that can be included in any ".m4" file processed by zcc. Currently macros implementing for-loops and foreach-loops are defined.

* List files ending with extension ".lst" can be used to specify a list of source files for the current compile, one filename per line. The list file is specified on the compile line with prefix @ as in "@foo.lst". List files can contain any source files of any type understood by zcc and individual lines can be commented out with a leading semicolon. Paths of files listed in list files can be made relative to the list file itself (default) or relative to the directory where zcc was invoked (--listcwd). List files can list other list files, identified with leading '@'.

* zcc now processes all files it is given to the final output file type specified. For example, with "-E" specified, all listed .c files will be run through the C pre-processor individually and all output copied to the output directory. Previous to this, only the first file listed was processed unless a binary was being built.

* -v gives more information on what steps zcc takes to process each source file.

* -x now builds a library out of the source files listed.

* -c by itself will generate individual object files for each input source file. However, if -c is coupled with an output filename as in "-o name", a single consolidated object file will now be built instead of individual ones. The intention is to provide a means to generate identical code in separate compiles by allowing this single object file to be specified on different compile lines.

* Better error reporting for source files with unrecognized types.

* Better parsing for compile line pragmas; pragma integer parameters can now be in decimal, hexadecimal or octal.

* -pragma-include added to allow a list of compile time pragmas to be read from a file as in "-pragma-include:zpragma.inc". This way projects can consolidate pragmas in one location; this is especially important for the new c library which uses pragmas extensively to customize the crt.

* -pragma-export added, is similar to -pragma-define but the assembly label defined as a constant on the compile line is made public so that its value is visible across all source files.

* --list will generate ".lis" files for each source file in a compile to a binary. The ".lis" file is an assembly listing of source prior to input to the linker.

* --c-code-in-asm causes C code to be interspersed as comments in any generated assembly listing associated with C source files.

* ".s" files are now understood by zcc to be asz80-syntax assembly language source files. This allows sdcc project files written in assembly language to be assembled by z88dk. asz80 mnemonics are non-standard so zcc attempts to translate to standard zilog mnemonics before assembling. You can see the translation to standard zilog form by using "-a" on a compile line. This is still a work-in-progress feature.

* --no-crt allows compiles to proceed without using the library's supplied crt for a target. The first file listed on a compile line will stand in as the crt and will be responsible for initialization and setting up the memory map.

* Temporary files are always created in the temp directory. The option "-notemp" has been removed.

* Library and include search paths have been fixed to honour the order specified on the compile line. This allows the user to override library functions when desired.

* Source files are now processed from their original location so that includes can be properly resolved. Previously this was only done for .c files but this now applies to other file types.

* clang/llvm compilation is in an experimental state.

Known issues:

* Spaces in paths or filenames can be a problem.

* When --c-code-in-asm is active, unicode characters from .c source files appearing as comments in translated asm may cause the tools to crash.

SCCZ80 - Native C Compiler

* Correct floating point constant handling.

* New __SAVEFRAME__ function decorator to allow saving of ix during a function call.

* -standard-escape-chars to make \n and \r output standard character codes

ZSDCC - Customization of SDCC C Compiler

* Updated to SDCC 3.6.5 #9824.

* SDCC's native C pre-processor is now used so that line numbers corresponding to reported errors are accurate.

* Peephole-z80 fixed to accurately report registers affected by instructions, allowing accurate application of peephole rules.

* inSequence('stride' %1 %2 %3 ...) added as peephole rule qualifier to allow testing whether consecutive bytes in memory are being accessed.

* Peephole-z80 made aware of z88dk special functions which represent code inlined by the library.

* Approximately 300 new peephole rules added to the aggressive peephole set (-SO3).

* Peephole rules added to fix some known code generation bugs and to fix SDCC's critical sections for nmos processors.

* --opt-code-size now significantly reduces code size for programs using 32-bit longs, 64-bit longlongs and floats.

* chars have been made unsigned by default. Use --fsigned-char to change to signed.

* For loops can now declare variables in the initializer statement.

* An rodata section has been properly implemented so that all constant data generated by sdcc is assigned there.

Z80ASM - Assembler, Linker, Librarian

* Handle input files more predictably: link .o files; assemble any other extension; append a .asm or .o option to the file name to allow just the basename.

* Make a consolidated object file with -o and not -b: all the object modules are merged, the module local symbols are renamed <module>_<symbol>

* Link the library modules in the command line sequence (it was depth-first).

* Add directory of assembled file to the end the include path to allow includes relative to source location.

* Remove all generated files at start of assembly to remove files from previous runs.

* Remove deprecated directives: XREF and LIB (replaced by EXTERN), XDEF and XLIB (replaced by PUBLIC), OZ (keep CALL_OZ).

* Rename DEFL to DEFQ to reserve DEFL for macro variables; rename DS.L by DS.Q

* Constants for section sizes: prune empty sections, rename ASMHEAD, ASMTAIL and ASMSIZE to __head, __tail and __size respectively, rename ASM<HEAD|TAIL|SIZE>_<section_name> to __<section_name>_<head|tail|size>

* Environment variables no longer used: Z80_OZFILES, Z80_STDLIB

* Command line option -r, --origin: accept origin in decimal or hexadecimal with '0x' or '$' prefix

* Command line options: -i, -x: require a library name

* Command line options: remove -RCMX000, keep only --RCMX000

* Command line options: remove -plus, keep only --ti83plus

* Command line options: remove -IXIY and --swap-ix-iy, keep --IXIY

* Command line options: remove --sdcc, -nm, --no-map, -ng, --no-globaldef, -ns, --no-symtable, -nv, --no-verbose, -nl, --no-list, -nb, --no-make-bin, -nd, --no-date-stamp, -a, --make-updated-bin, -e, --asm-ext, -M, --obj-ext, -t

* Make symbol files, map files and reloc files optional; do not merge symbols in the list file; do not paginate and cross-reference symbols in list file; rename list file to file.lis (@file.lst is used as project list)

* Unify format used in map files, symbol files and global define files, output list of symbols only once.

* Include symbols computed at link time in the global define file.

* Simplify output of --verbose

APPMAKE - Processes Output Binaries to Target Suitable Form

* +rom can now generate binaries for ROM chips mapped into a specific address range.

* +sms now generates bankswitched .sms files as output.

* +zx now has option to generate headerless .tap files.

* Appmake now understands three compile models -- ram (destined for ram, no stored data section), rom (destined for rom, stored data section is a copy) and compressed rom (destined from rom, stored data section is compressed) -- and will form output files accordingly.


* SDCC can now be used to compile using the classic library.

* Rewritten and modular printf core, added (v)snprintf.

* Rewritten and modular scanf core.

* Ports are now section aware.

* Support for compressed data section model.

* Support for copied data section model.

* User overridable fputc_cons.

* New target: Microbee. Support for various GFX modes and 1 bit sound.

* New target: Robotron kc. Support for various GFX modes and 1 bit sound.

* New target: z1013. Support for various GFX modes and 1 bit sound.

* New target: z9001. Support for various GFX modes and 1 bit sound.

* CP/M Plus on Spectrum.

* CP/M extenstions forced to upper case.

* CP/M extensions improved on Aussie Byte, trs-80 and Epson PX.

* GFX Library: improved the vector rendering functions, now bigger pictures can be drawn and higher resolutions are supported. Various fixes.

* Custom text configuration (font, resolution) can be done at compile time for targets with ansi VT support on graphics display.


* 64-bit integers are now fully supported in the library.

* The fprintf/fscanf cores can now have conversion specifiers individually enabled or disabled at compile time. This allows the printf/scanf cores to be tailored to the minimum size required.

* fprintf %aefg precision formatting corrected.

* Intrinsics have been introduced as a method to inline assembly code without disturbing optimization. This provides a means to insert assembly labels (whose addresses will appear in map files), simple assembly instructions such as "di" and "ei", and atomic loads/stores into C code without affecting the compiler's optimizer. See https://www.z88dk.org/wiki/doku.php?id=libnew:intrinsic

* The library has had a preserves_registers attribute attached to every function that informs sdcc which registers will not be affected by a library call and allows sdcc to generate better code around library calls.

* aplib added as another data decompression utility.

* setjmp/longjmp state increased to include the value of IY for sdcc compiles. This was necessary as sdcc sometimes requires the value of IY to be preserved at points in the program.

* New target: rc2014 (preliminary). This target is still being developed by rc2014 users.

* New target: Sega Master System. The target is able to automatically create bankswitched rom cartridges with signatures.

* ZX Spectrum target: interfaces to the bifrost and nirvana multicolour sprite engines added.

* The CRT startup code has been made more flexible, allowing a wide range of features to be selected via pragmas at compile time. See https://www.z88dk.org/wiki/doku.php?id=libnew:target_embedded#crt_configuration

Вернуться к началу
Ответить с цитатой  
 Заголовок сообщения: How is zsdcc different from sdcc ?
СообщениеДобавлено: 31 янв 2017, 15:14 
Не в сети
Аватара пользователя

Сообщения: 846
Откуда: Днепропетровская обл.
How is zsdcc different from sdcc ?

    • A distinction is made between extern and public symbols. Current sdcc relies on the assembler being able to distinguish the two at assemble time. This can be a problem for assembler backends that do not make such an accommodation and was a problem for z88dk for a while until z88dk/z80asm was modified to accept a global directive. Apart from assembler difficulties, the failure to make the distinction means the linker cannot catch errors where local symbols are undefined (they are made global) and can cause silent linking errors especially when assembler is mixed with c in projects.

    • Label names are made compatible with z88dk/z80asm.

    • A proper rodata section is implemented. sdcc currently mingles all read-only data with the code section.

    • inSequence(stride,params..) is added as a peephole rule qualifier. This allows z88dk to determine when successive bytes in memory are read or written so that it can substitute lengthy code with short replacements when --opt-code-size is selected.

    • peephole-z80 is fixed so that it can determine exactly what registers are modified or not by individual z80 instructions. sdcc has bugs in this area that prevents it from applying peephole rules properly. This deficiency is not clear in native sdcc because its peephole set is small but it has major impact in application of z88dk's peephole set which is many times larger.

    • peephole-z80 is made aware of many z88dk intrinsic functions. These are library functions that are used when z88dk tries to perform further code size reduction; the peepholer is made aware of register preservation so that it can better optimize around them.

Вернуться к началу
Ответить с цитатой  
 Заголовок сообщения: Re: Z88DK news
СообщениеДобавлено: 06 мар 2017, 17:03 
Не в сети
Аватара пользователя

Сообщения: 846
Откуда: Днепропетровская обл.
Alcoholics Anonymous писал(а):
Hi Oleg,

I finished the few benchmarks I have so far with IAR if you are interested:


Just click on the directory and read the displayed readme.txt.

The code quality looks very good and seems the best on cursory inspection but it doesn't seem to perform better on dhrystone and sieve where a majority of the execution time is in compiler-generated code. With dhrystone, against sdcc (and mainly zsdcc which is quicker) the difference could be down to sdcc's inlining of some string operations. It also looks like IAR may have weaker c libraries.

The 32-bit math is as slow as sdcc's and it can only be that slow by being written in c (see pi benchmark). It wins on the whetstone benchmark (floating point) but it should be faster over z88dk since it's employing a 24-bit mantissa float versus a 40 bit mantissa in z88dk. At that speed the float package must be written in asm but I would expect it to be a lot faster against z88dk than it is.

I've done most combinations of z88dk (I took a break after 2/3 finished -- there are 4 different combinations of compiles and that becomes annoying after a while :P ), Hitech cpm 309, Iar z80 406A, sdcc. I'll see if I can get Zilog Dev Studio working for the ez80 generating z80 code.

Thanks again Oleg!

Вернуться к началу
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 3 ] 

Часовой пояс: UTC + 2 часа

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2

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

Создано на основе phpBB® Forum Software © phpBB Group
Тех.поддержка phpBB