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

Твердыня модульных языков
Текущее время: 21 апр 2018, 11:24

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




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

Сообщения: 877
Откуда: Днепропетровская обл.
Z88DK v1.99B Released at Sourceforge:
https://sourceforge.net/projects/z88dk/

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:
https://www.z88dk.org/wiki/doku.php?id=temp:front#installation

Home Page:
https://www.z88dk.org/forum/
Includes link to the nightly builds.

Forum:
https://www.z88dk.org/forum/forums.php

Introduction to Compiling Using the Classic C Library:
https://www.z88dk.org/wiki/doku.php
Examples in z88dk/examples

Introduction to Compiling Using the New C Library:
https://www.z88dk.org/wiki/doku.php?id=temp:front
Examples in z88dk/libsrc/_DEVELOPMENT/EXAMPLES

Compiling for Generic z80 Embedded Systems Using the New C Library:
https://www.z88dk.org/wiki/doku.php?id=libnew:target_embedded


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


=======
PACKAGE
=======

* 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.


=================
CLASSIC C LIBRARY
=================

* 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.


=============
NEW C LIBRARY
=============

* 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 
Не в сети
Аватара пользователя

Сообщения: 877
Откуда: Днепропетровская обл.
Цитата:
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.
https://github.com/z88dk/zsdcc


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

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

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

https://github.com/z88dk/z88dk/tree/master/libsrc/_DEVELOPMENT/EXAMPLES/benchmarks

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!


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Z88DK news
СообщениеДобавлено: 03 фев 2018, 13:47 
Не в сети
Аватара пользователя

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

Try the newlib instead. You have much tighter control over everything.

zcc +zx -vn -startup=31 -clib=sdcc_iy -SO3 --max-allocs-per-node200000 hello.c -o hello -pragma-include:zpragma.inc

The startup value chooses a specific crt to use and for the zx target is mainly used to select pre-set drivers on stdin, stdout, stderr. You can see a little talk about this here:
https://github.com/z88dk/z88dk/blob/master/doc/ZXSpectrumZSDCCnewlib_02_HelloWorld.md
You can always instantiate your own drivers on stdin, stdout (and more whose names you invent) so it's possible to have many windows on screen with various dimensions, for example. But the startup numbers are an easy way to get a default. startup=31 uses a crt with nothing on stdin,stdout,stderr so that printf and scanf will not work.

-v instead of -vn will show you what zcc is doing.

-clib=sdcc_iy chooses sdcc as compiler and the newlib's iy version of the library. This gives ix to sdcc and reserves iy for the library. The "--reserve-regs-iy" flag is also used in the compile. We find this leads to the best code generation.

-SO3 uses aggressive peephole rules. (-SO2 is the default). --max-allocs-per-node200000 is the same as sdcc. You can also add --opt-code-size

"hello.c" is the source file but there can be any number of source files listed, .c, .asm, etc. If there are a lot you can create a file that lists them one per line and then name that file on the compile line with something like "@project.lst".

"-o hello" selects the root of the output name.

"-pragma-include:zpragma.inc" tells zcc to read the file "zpragma.inc" to find project pragmas. Pragmas are how you communicate to the crt about what options you do or do not want.

Some other options you may want to add:

--fsigned-char
-m : generate map file
--list : generate .lis file for each source file showing the translated asm
--c-code-in-asm : put c code in .lis or .asm files as comments

For the "zpragma.inc" file, here is a set of pragmas you may want to use to reduce the crt size.
Most generic pragmas are described here: https://www.z88dk.org/wiki/doku.php?id=libnew:target_embedded#crt_configuration
but targets can have their own too. For the zx the extra pragmas control the org of memory banks and the behaviour of the default terminal drivers.
The default settings of the pragmas for zx ram compiles (as opposed to if2 cartridges or esxdos dot commands) is here:
https://github.com/z88dk/z88dk/blob/master/libsrc/_DEVELOPMENT/target/zx/crt_config.inc#L22

"zpragma.inc"

#pragma output CLIB_MALLOC_HEAP_SIZE = 0 // do not create a heap so that malloc() will not work
#pragma output CLIB_STDIO_HEAP_SIZE = 0 // cannot open files

Other ones that might be useful are to change "CRT_ON_EXIT" so that on program exit, the program does a reset by jumping to zero. It is set up to return to basic which makes the crt bigger because it has to take care of some housekeeping to do that. "REGISTER_SP" sets the initial stack pointer. It's set just below the UDGs to be compatible with basic but it's better to put it at -1 (leave at the position set by CLEAR in the basic loader) or 0 (move SP to the top of memory - remember SP decrements before writing a value) if you do not return to basic. If you start using printf and scanf, you can control which % converters you want to include in the compile. See https://www.z88dk.org/wiki/doku.php?id=libnew:target_embedded#printf_and_scanf_configuration

===

For output, z88dk always creates binaries. You will see a "hello_CODE.bin" file in the output. That is the binary that is orged at 32768 by default. If you start defining sections or you start to build for the 128k spectrum there may be more binaries generated.

The output binaries plus the map file are communicated to another tool in z88dk called "appmake" to build the final output. By adding "-create-app" to the compile line, zcc will automatically invoke "appmake +zx" with a default setting to build a tap out of the main output binary. You can change that to sna by adding "-subtype=sna" and there are other specialized output forms too. If you want to make an intel hex file, there is "appmake +hex" that can help with that but for the zx you don't really want that. You don't have to add "-create-app" to the compile line and you can stick to the raw binary output instead. Or you can use appmake separately to process the output binaries as you see fit.


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Z88DK news
СообщениеДобавлено: 03 фев 2018, 13:48 
Не в сети
Аватара пользователя

Сообщения: 877
Откуда: Днепропетровская обл.
Alvin писал(а):
Цитата:
Another question: can I use ZSDCC without ZCC? And then how can I build binary (or hex) output?

When you replace "-vn" with "-v" in the compile line you can see what zcc is doing. You can always invoke the tools separately but zcc makes it all simple and it always knows what to do. For zsdcc in particular, you have to call zpragma to process pragmas which may be inlined in c code, then the preprocessor, then zsdcc with the correct optimization rules to use, then copt to translate asz80 syntax to standard zilog for z80asm, then copt again to perform platform-specific optimizations and sdcc bugfixes, then z80asm to make an object file, then z80asm to link all the source files in the compile, then optionally appmake to build the output. It's much easier to just have zcc do everything.

You can always ask zcc to stop earlier in the process. For example "-a" will stop after .c files have been translated to asm (output is .c.asm) and "-c" will stop at an object file .o. You can also get zcc to build libraries with "-x" if you want to make a runtime library.


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: ZSDCC & .rel
СообщениеДобавлено: 04 фев 2018, 13:42 
Не в сети
Аватара пользователя

Сообщения: 877
Откуда: Днепропетровская обл.
Alvin писал(а):
Цитата:
can ZSDCC create or use standard SDCC's .rel files? Can I use ZCC/ZSDCC to compile separate .c-files to combine the output of SDCC and ZSDCC?

No you can't really share object files between z88dk and sdcc. z88dk has a different implementation of the compiler primitives than sdcc and they use different calling conventions (callee / fastcall whereas sdcc is usually implementing primitives in C with standard linkage). So even if the object files could be translated somehow, the compiled C would not be using the same calling conventions for many things.

You can create .o object files (z80asm format) using zcc like this:
zcc +zx -vn -c -clib=sdcc_iy -SO3 --max-allocs-per-node200000 foo.c bar.c baz.c
You will get one object file per .c or .asm input file: foo.o bar.o baz.o

A consolidate object file creates one object file for all source input:
zcc +zx -vn -c -clib=sdcc_iy -SO3 --max-allocs-per-node200000 foo.c bar.c baz.c -o together
The output will be one object file together.o that contains all the source files.

A library can be built too:
zcc +zx -vn -x -clib=sdcc_iy -SO3 --max-allocs-per-node200000 foo.c bar.c baz.c -o mylib
The output will be one library mylib.lib which you can link against in compiles by adding "-lmylib"

Object files added to a compile will have all their code added to the output binary. Libraries, on the other hand, are incrementally linked so that only functions called and their dependencies will be extracted from the library to be added to the output binary.

The list of source files can be as long as you want and can mix any types like .c, .asm, .c.m4, .asm.m4, etc. Instead of listing each file on the compile line you can store the filenames in a .lst file, one per line, and then add "@mylist.lst" to replace the list of source files in the zcc commands above.


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Z88DK news
СообщениеДобавлено: 05 фев 2018, 15:33 
Не в сети
Аватара пользователя

Сообщения: 877
Откуда: Днепропетровская обл.
Alvin писал(а):
Oleg N. Cher писал(а):
Now I have another question. This output for my project compiled in zsdcc instead of sdcc

Error at file 'Durak.c' line 7420: syntax error
Error at file 'Durak.c' line 5403: symbol '_strcpy_callee' not defined
2 errors occurred during assembly
Errors in source file Durak.c:
Error at file 'Durak.c' line 7420: syntax error
^ ---- (null)Error at file 'Durak.c' line 5403: symbol '_strc
py_callee' not defined
^ ---- (null) .

strcpy definitely works. Maybe you want to check if one of the generic examples in z88dk works.

Go to z88dk/libsrc/_DEVELOPMENT/EXAMPLES and compile eliza.c (it uses strcpy).
zcc +zx -vn -SO3 -startup=8 -clib=sdcc_iy --max-allocs-per-node200000 eliza.c -o eliza -create-app

As for why it's not working, I'm wondering if you have your own "string.h" that is being included before z88dk's that's not right. Or you're building a binary without "+zx" so that z88dk's library is not being linked and strcpy can't be found. Or you have a previous z88dk install and the environment variables ZCCCFG and PATH are pointing into the old z88dk instead of the new one. This is especially tricky with PATH because an older install will be ahead of the new install's binary path if you add the new path to the end of the PATH variable. If you have an old z88dk install, maybe rename it to make sure the new install is being run.

If it's none of the above, can you give a link to the source?

Цитата:
Invoking line (please comment):

SET Lib=%XDev%\ZXDev\Lib

zcc +zx -vn -startup=31 -clib=sdcc_iy Durak.c -oDurak -I..\C -I..\C\include -I..\Lib -I%Lib%\C -I%Lib%\Obj -L%Lib% -create-app -compiler=sdcc -SO3 --oldralloc -pragma-include:zpragma.inc

P.S. "-clib=sdcc_iy" don't use IY, correct?

Yes, "cllib=sdcc_iy" means "-compiler=sdcc --reserve-regs-iy" + use newlib and its iy library. sdcc itself will try not to use iy but it will occasionally anyway. The difference is it will no longer require iy to be preserved. newlib's iy library means that the library code *will* use iy when an index register is needed instead of ix. If you're wondering about compatibility with the basic rom, z88dk always starts spectrum programs with interrupts disabled so that it doesn't have to worry about problems with changing iy. Usually people who want the interrupt routine to run want the basic rom to gather key input. You can do that instead by using the key input routines in input.h, for example "in_inkey()" to return an ascii code after a key scan. Or you can create your own im2 isr that preserves iy and calls the basic interrupt routine but z88dk intentionally divorces itself from the basic rom as much as possible. There is a pull request that I am looking at now that makes it easy to create an im2 interrupt routine that calls into basic's isr https://github.com/z88dk/z88dk/pull/568/files#diff-b20943c0cc7003c84dca1b3374b4856dR75 .

The compile line:

zcc +zx -vn -startup=31 -clib=sdcc_iy Durak.c -oDurak -I..\C -I..\C\include -I..\Lib -I%Lib%\C -I%Lib%\Obj -L%Lib% -create-app -SO3 -pragma-include:zpragma.inc

--oldralloc should not be used; I'm not sure what will happen if you do use it. It probably won't cope well with the different function call linkages.

-SO3 is best used in combination with higher --max-allocs-per-node but it should still make a difference. The rules in SO3 are tuned for max-allocs=200000 which has a somewhat different code generation pattern compared to lower optimization settings.

The -I are include paths for .h files and the search order will be the order you list followed by the z88dk header files. So if you have a string.h it will be used in preference to z88dk's string.h.

The -L is the library search path. Your library will be searched before z88dk's library so that you can override functions implemented in the library. If you provide your own _strcpy_callee, it will be used instead of z88dk's.


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Z88DK news
СообщениеДобавлено: 06 фев 2018, 14:00 
Не в сети
Аватара пользователя

Сообщения: 877
Откуда: Днепропетровская обл.
Alvin писал(а):
Цитата:
Can I disable the output of warning 85? --disable-warning 85 doesn't work.

zcc doesn't understand that option. If you look at the zsdcc invokes when zcc is given -v instead of -vn you can see all the switches being passed to zsdcc to confirm that --disable-warning is not making it there.

Instead you can specifically tell zcc to pass something to zsdcc with the -Cs switch: -Cs"--disable-warning 85"


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Z88DK news
СообщениеДобавлено: 06 фев 2018, 21:51 
Не в сети
Аватара пользователя

Сообщения: 877
Откуда: Днепропетровская обл.
Alvin писал(а):
Цитата:
P.S. You wrote about code from libraries - to target binary added only really used functions and variables. So there is no need to keep the code of each function in a separate source? As I do it for SDCC. And more interesting is how you solved the problem of visibility of static variables from outside.

We have the same problem as sdcc - the linking step is done at file granularity so you do have to separate individual functions into independent files before building a library. It is on our to-do list to accommodate this and involves introducing multiple module directives in a file to the assembler but this was slated for the next version of z80asm by Paulo so I'm not sure how far in the future that is. Perhaps a year or more unfortunately.

As for visibility, it follows the C pattern. A label is either global or local to a file and that's controlled by the PUBLIC directive (asz80 does .globl). You can refer to a global symbol from any other file with the EXTERN directive (asz80 does .globl for this too). So a file has control over what is made globally visible and it has control over what external labels it can see. This is a very common pattern among linkers and asz80 works the same way.

The fact asz80 (or rather sdcc as it only understands .globl) is using .globl for both is a potential point of error.


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

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


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

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


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

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Group
Тех.поддержка phpBB