[z88dk-dev] Adapting appmake to the SDCC compile chain

Bridge to the z88dk-developers mailing list
Post Reply
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

[z88dk-dev] Adapting appmake to the SDCC compile chain

Post by stefano »

Starting from scratch (still trying to stay in my "comfort zone") I found the compile hints in the example code, say, very rich.
I just inserted a hack into appmake which helps it in spotting the proper binary file. I know this is far from your original idea of supporting multiple blocks but now the "-create-app" option is usable in the simpler case also with SDCC.

The current version compares the given bin file and a possible variant with the "_CODE.bin" suffix. It works on the binary file dates and sizes to choose the right one.
If you think it is too simplistic then it can now be fixed, improved or just reverted by adjusting a single function in appmake.c.

The "-zorg" option is still needed to help appmake.. ideas for it ?



------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
User avatar
dom
Well known member
Posts: 2076
Joined: Sun Jul 15, 2007 10:01 pm

Post by dom »

Starting from scratch (still trying to stay in my "comfort zone") I found the compile hints in the example code, say, very rich.
I just inserted a hack into appmake which helps it in spotting the proper binary file. I know this is far from your original idea of supporting multiple blocks but now the "-create-app" option is usable in the simpler case also with SDCC.

The current version compares the given bin file and a possible variant with the "_CODE.bin" suffix. It works on the binary file dates and sizes to choose the right one.
If you think it is too simplistic then it can now be fixed, improved or just reverted by adjusting a single function in appmake.c.

The "-zorg" option is still needed to help appmake.. ideas for it ?
As a quick note, appmake continues to work with the classic library and SDCC.

Doing some work on appmake to make it work for the more segmented new library is worthwhile, even at the very simple level of (taking the spectrum as an example), creating a single .TAP that can be loaded easily. The .sym file contains all the ASMHEAD and ASMTAIL values for each section so the memory model can be built from the fragments.



------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

Starting from scratch (still trying to stay in my "comfort zone") I found the compile hints in the example code, say, very rich.
I just inserted a hack into appmake which helps it in spotting the proper binary file. I know this is far from your original idea of supporting multiple blocks but now the "-create-app" option is usable in the simpler case also with SDCC.
create-app might be usable for the most common compiles.

There are three kinds:

* ram model (0). This one creates one output binary "*_CODE.bin" and a binary named "*" (without suffix) that should be zero size. It might be nice to emit a warning if that file is not zero size. "*" collects code and data that has not been assigned to a section, which is an error.

* rom model (1). This one creates three output binaries "*_CODE.bin", "*_DATA.bin" and "*_BSS.bin" and the binary "*". Again, a non-zero size "*" is an error. To form the final binary "*_DATA.bin" must be concatenated to "*_CODE.bin".

* compressed rom model (2). The same binaries are output as for the rom model: "*_CODE.bin", "*_DATA.bin" and "*_BSS.bin" and the binary "*". This time the data section must be compressed with zx7 before it is appended to "*_CODE.bin" to form the final binary.

You may be able to determine which model is active from the output filenames but this information is also available via the "CRT_MODEL" constant defined in the crt (it would have the 0,1,other values listed above).

All the targets will have some variation of these standard 64k model outputs. The zx target is normally a ram model compile (as would be most home computers of the area) but it also has rom model and compressed rom model (preferred) startups for if2 cartridges. The embedded target is meant for generic z80 machines. It defaults to the compressed rom model since it's most likely the output binary is destined for rom. cpm would almost exclusively be the ram model compile.


But after these standard compiles, everything can be customized by the user, so I think create-app would only apply to the above. In the case of the zx, the user might be assigning code/data to different memory banks on the 128k machine. In these cases, there will be multiple binaries output, one per bank and all with the same org $c000. Even looking at the map file it won't be possible to determine which bank each binary belongs to without manual input. There are other cases where more user-defined sections might be created. After the program is loaded, the program may want to store variables in the basic area just after the display file. The name of the output binary can vary and you could get org and length from the map file but you can't load that area via a basic loader. You may also not want to load that area at all -- this example http://www.z88dk.org/wiki/doku.php?id=l ... es:sp1_ex1 creates the heap in this low memory area and we don't want to load tha!
t area
at all since it's initialized by the crt at startup.
The "-zorg" option is still needed to help appmake.. ideas for it ?
zorg will continue to work actually but the correct method to determine start address is by looking at "CRT_ORG_CODE" defined in the crt. I'm not sure how zorg is communicated to appmake when -zorg does not appear on the compile line but maybe something similar could be done with these new c lib variables?



------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

The zx target is normally a ram model compile (as would be most home computers of the area) but it also has rom model and compressed rom model (preferred) startups for if2 cartridges.
I should add that the output for an if2 cart is a 16k .rom (binary file). It may also be desirable to generate a compressed rom model program run from ram -- since ram model programs do not initialize the bss and data sections, they can only run once, so if the program must restart or be able to run again after exit, it must use one of the rom models. So it's not enough to look at CRT_MODEL to determine for the zx whether a tap or rom should be produced -- you'd also want to look at the startup value to find out if tap or rom is the appropriate output format.



------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

There were a few minor problems to get appmake to compile but I committed the changes for tonight's build. In a handful of files, a FILE* variable "fpin" was introduced without being declared or used other than assignment after an fopen and succeeding code was using a different FILE* handle. You may have been thinking about changing to fpin in the source but didn't finish or commit?

I tried create-app with a new c lib compile but it complains about a missing sym file.



------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

Wow.. I was fooled by the make tool not refreshing the compilation for the files I changed :(
I'm fixing it now.. I have no idea on the reason for the "missing sym file" error, I'll try to understand.



------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

Ok, I see you've fixed it already :/
Sorry for the mess .. <blush>



------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

Ok, I see you've fixed it already :/
I hope you don't mind... it was just a few minor problems so I just committed the fixes.

I have no idea on the reason for the "missing sym file" error, I'll try to understand.
I think it could be looking at the wrong sym file. It has to be the one associated with "*_CODE.bin" as that file will contain the crt and all the build defines.
From the sym file for "*_CODE.bin" you can find these relevant defines. Note the symbol names must be exact as these symbol names will be substrings in other symbols.
__crt_org_code = org address

__crt_model = 0 (ram model, "*_CODE.bin" is final binary), 1 (rom model, append "*_DATA.bin" to "*_CODE.bin" for final binary), >=2 (compressed rom model, append zx7("*_DATA.bin") to "*_CODE.bin" to form final binary)

startup = zx (>=31 for if2 16k *.rom image as output, <31 for *.tap file as output), cpm (change name of final binary to *.com), embedded (change name of final binary to *.bin)

The filename "*" (without extension) must be zero size. If it is looked at, maybe emit a warning that "some code or data may not be assigned to sections" if it's non-zero size.



------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

I hope you don't mind... it was just a few minor problems so I just committed the fixes.
I don't absolutely ..I'm just a bit ashamed :)
I have no idea on the reason for the "missing sym file" error, I'll try to understand.
I think it could be looking at the wrong sym file. It has to be the one associated with "*_CODE.bin" as that file will contain the crt and all the build defines. (...)
Almost got it, I'll have a look.. thank you!
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

Ok, I believe the "sym" file is not changing with SDCC.
As you said, we have enough information to use it to fix appmake in the simpler behavior (the good old single monolithic block).

This works for me and I think that adding another global function will suffice with the "minor" targets, so if you don't mind I'd go ahead.

Code: Select all

                        if ( ( pos = parameter_search(crtfile,".sym","myzorg") ) == -1 ) {
if ( ( pos = parameter_search(crtfile,".sym","__crt_org_code") ) == -1 ) {
myexit("Could not find parameter ZORG (not z88dk compiled?)\n",1);
}
}
------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

This works for me and I think that adding another global function will suffice with the "minor" targets, so if you don't mind I'd go ahead.

Code: Select all

                        if ( ( pos = parameter_search(crtfile,".sym","myzorg") ) == -1 ) {
if ( ( pos = parameter_search(crtfile,".sym","__crt_org_code") ) == -1 ) {
myexit("Could not find parameter ZORG (not z88dk compiled?)\n",1);
}
}
Maybe switch the order to handle cases where both are defined? Right now myzorg takes precedence in the new c lib (__crt_org_code = myzorg) but in case that ever changes, changing the order will prevent problems.

I found the missing sym file issue. If you add "--list" to the compile line, the crt is copied into the working dir before appmake runs and it seems this also removes the sym file.

If you're not looking at it now, I think I will have a look at handling the other main compile cases (rom and compressed rom) in the next couple of days. Then -create-app could work in the majority of compile cases.



------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

Maybe switch the order to handle cases where both are defined? Right now myzorg takes precedence in the new c lib (__crt_org_code = myzorg) but in case that ever changes, changing the order will prevent problems.
No problem. This code is now global so all the targets needing to peek a dynamic value for ORG will evolve automatically.

I found the missing sym file issue. If you add "--list" to the compile line, the crt is copied into the working dir before appmake runs and it seems this also removes the sym file.

If you're not looking at it now, I think I will have a look at handling the other main compile cases (rom and compressed rom) in the next couple of days. Then -create-app could work in the majority of compile cases.
Hoping I did not break something again :/ I'm not thinking to do much more on appmake in the immediate future.

In the the today's version I should have restored the legacy effects of the "-create-app" flag, so that a simple ZCC session can do the full build in a single line.
I also put in few warnings: the one you suggested for the root binary file not being totally empty and two related to "conflicting CRT model" conditions in zx.c and rom.c

The _DATA related work at the moment is only represented by an unlinked "fopen_data" function in appmake.c



------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

The "--list" vs ".sym" issue is in z80asm and I'm afraid it is by design:

Code: Select all

static void do_assemble( char *src_filename )
{
int start_errors = get_num_errors();     /* count errors in this source file */

/* create list file or symtable */
if (opts.list)
list_open(get_lst_filename(src_filename));        /* set '.lst' extension */
else if (opts.symtable)
list_open(get_sym_filename(src_filename));        /* set '.sym' extension */
else
{
}                                                                                                        /* no list file */

(...)
I'd try to simply make ZCC aware of the conflict and issue the proper warning.



------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
pscust
Well known member
Posts: 194
Joined: Thu Jun 23, 2011 3:34 pm

Post by pscust »

I would say that it is rather by legacy than by design. I agree that the
same info should always be in the same output file.

Should I change z80asm design to put symbols always in .sym? I can do it
over the weekend.


On Fri, Jun 24, 2016 at 8:26 AM, Stefano Bodrato (
stefano_bodrato@...) <lists@...> wrote:
The "--list" vs ".sym" issue is in z80asm and I'm afraid it is by design:

Code: Select all

static void do_assemble( char *src_filename )
{
int start_errors = get_num_errors();     /* count errors in this
source file */

/* create list file or symtable */
if (opts.list)
list_open(get_lst_filename(src_filename));      /* set
'.lst' extension */
else if (opts.symtable)
list_open(get_sym_filename(src_filename));      /* set
'.sym' extension */
else
{
}
/* no list file */

(...)
I'd try to simply make ZCC aware of the conflict and issue the proper
warning.




------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

If so.. yes please ! :)

By the way, if you find any problem to do it ...to forcefully limit zcc is possible:


if (createapp) {
if (lston) {
fprintf(stderr, "Application cannot be created when the '--list' option is active\n");
} else {


Stefano


From: pauloscustodio@...
Date: Fri, 24 Jun 2016 09:34:26 +0100
To: lists@...
CC: z88dk-developers@...
Subject: Re: [z88dk-dev] Adapting appmake to the SDCC compile chain

I would say that it is rather by legacy than by design. I agree that the same info should always be in the same output file.

Should I change z80asm design to put symbols always in .sym? I can do it over the weekend.


On Fri, Jun 24, 2016 at 8:26 AM, Stefano Bodrato (stefano_bodrato@...) <lists@...> wrote:
The "--list" vs ".sym" issue is in z80asm and I'm afraid it is by design:


Code: Select all

static void do_assemble( char *src_filename )

{

int start_errors = get_num_errors();     /* count errors in this source file */



/* create list file or symtable */

if (opts.list)

list_open(get_lst_filename(src_filename));      /* set '.lst' extension */

else if (opts.symtable)

list_open(get_sym_filename(src_filename));      /* set '.sym' extension */

else

{

}                                                                                                       /* no list file */



(...)
I'd try to simply make ZCC aware of the conflict and issue the proper warning.
pscust
Well known member
Posts: 194
Joined: Thu Jun 23, 2011 3:34 pm

Post by pscust »

I have looked into the code and the options handling is rather odd:

1) opts.symtable is by default TRUE (a symbol list is generated), and is
set to FALSE with -ns or --no-symtable; the options -s and --symtable
exist, but are not necessary. The symbol list is either in a file.sym or
file.lst, if a list file is also generated.

I would prefer that a symtable is only generated if requested by -s or
--symtable, and it should always be written to file.sym. Options -ns and
--no-symtable can be removed.

2) opts.list is by default FALSE (a list file is not generated) and is set
to TRUE with -l or --list; the options -nl and --no-list exist but are not
necessary. The list file is file.lst.

I would remove options -nl and --no-list.

3) opts.map is similar to opts.symtable - default TRUE and map file
generated.

I would prefer that a map file is only generated if requested by -m or
--map, and options -nm and --no-map can be removed.

4) file.reloc is only required in some platforms and is always generated.

I would prefer to only generate it if requested by a new option
--reloc-info.

5) Why is appmake looking at the file.sym? file.map should contain the same
info and is more machine-friendly - no pagination and headers.

6) Pagination in list and sym files, and map files with two copies of the
symbols, one ordered by address and one by name are anachronisms of a time
where you had to work with printed output copies on paper instead of grep
and sort.

I would prefer to remove pagination info and keep only one copy of the
symbols in the map file.


Please comment. Can I push through and simplify z80asm, or will something
break in the tool chain?

Regards,
Paulo


On Fri, Jun 24, 2016 at 11:22 AM, Stefano Bodrato <
stefano_bodrato@...> wrote:
If so.. yes please ! :)

By the way, if you find any problem to do it ...to forcefully limit zcc
is possible:


if (createapp) {
if (lston) {
fprintf(stderr, "Application cannot be created when the
'--list' option is active\n");
} else {


Stefano


------------------------------
From: pauloscustodio@...
Date: Fri, 24 Jun 2016 09:34:26 +0100
To: lists@...
CC: z88dk-developers@...
Subject: Re: [z88dk-dev] Adapting appmake to the SDCC compile chain

I would say that it is rather by legacy than by design. I agree that the
same info should always be in the same output file.

Should I change z80asm design to put symbols always in .sym? I can do it
over the weekend.


On Fri, Jun 24, 2016 at 8:26 AM, Stefano Bodrato (
stefano_bodrato@...) <lists@...> wrote:

The "--list" vs ".sym" issue is in z80asm and I'm afraid it is by design:

Code: Select all

static void do_assemble( char *src_filename )
{
int start_errors = get_num_errors();     /* count errors in this
source file */

/* create list file or symtable */
if (opts.list)
list_open(get_lst_filename(src_filename));      /* set
'.lst' extension */
else if (opts.symtable)
list_open(get_sym_filename(src_filename));      /* set
'.sym' extension */
else
{
}
/* no list file */

(...)
I'd try to simply make ZCC aware of the conflict and issue the proper
warning.
pscust
Well known member
Posts: 194
Joined: Thu Jun 23, 2011 3:34 pm

Post by pscust »

In the mean time I have fixed just the issue requested - now the symbols
list is always written to file.sym.


On Sat, Jun 25, 2016 at 1:03 AM, Paulo Custodio <pauloscustodio@...>
wrote:
I have looked into the code and the options handling is rather odd:

1) opts.symtable is by default TRUE (a symbol list is generated), and is
set to FALSE with -ns or --no-symtable; the options -s and --symtable
exist, but are not necessary. The symbol list is either in a file.sym or
file.lst, if a list file is also generated.

I would prefer that a symtable is only generated if requested by -s or
--symtable, and it should always be written to file.sym. Options -ns and
--no-symtable can be removed.

2) opts.list is by default FALSE (a list file is not generated) and is set
to TRUE with -l or --list; the options -nl and --no-list exist but are not
necessary. The list file is file.lst.

I would remove options -nl and --no-list.

3) opts.map is similar to opts.symtable - default TRUE and map file
generated.

I would prefer that a map file is only generated if requested by -m or
--map, and options -nm and --no-map can be removed.

4) file.reloc is only required in some platforms and is always generated.

I would prefer to only generate it if requested by a new option
--reloc-info.

5) Why is appmake looking at the file.sym? file.map should contain the
same info and is more machine-friendly - no pagination and headers.

6) Pagination in list and sym files, and map files with two copies of the
symbols, one ordered by address and one by name are anachronisms of a time
where you had to work with printed output copies on paper instead of grep
and sort.

I would prefer to remove pagination info and keep only one copy of the
symbols in the map file.


Please comment. Can I push through and simplify z80asm, or will something
break in the tool chain?

Regards,
Paulo


On Fri, Jun 24, 2016 at 11:22 AM, Stefano Bodrato <
stefano_bodrato@...> wrote:
If so.. yes please ! :)

By the way, if you find any problem to do it ...to forcefully limit zcc
is possible:


if (createapp) {
if (lston) {
fprintf(stderr, "Application cannot be created when the
'--list' option is active\n");
} else {


Stefano


------------------------------
From: pauloscustodio@...
Date: Fri, 24 Jun 2016 09:34:26 +0100
To: lists@...
CC: z88dk-developers@...
Subject: Re: [z88dk-dev] Adapting appmake to the SDCC compile chain

I would say that it is rather by legacy than by design. I agree that the
same info should always be in the same output file.

Should I change z80asm design to put symbols always in .sym? I can do it
over the weekend.


On Fri, Jun 24, 2016 at 8:26 AM, Stefano Bodrato (
stefano_bodrato@...) <lists@...> wrote:

The "--list" vs ".sym" issue is in z80asm and I'm afraid it is by design:

Code: Select all

static void do_assemble( char *src_filename )
{
int start_errors = get_num_errors();     /* count errors in this
source file */

/* create list file or symtable */
if (opts.list)
list_open(get_lst_filename(src_filename));      /* set
'.lst' extension */
else if (opts.symtable)
list_open(get_sym_filename(src_filename));      /* set
'.sym' extension */
else
{
}
/* no list file */

(...)
I'd try to simply make ZCC aware of the conflict and issue the proper
warning.
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

I've added changes to appmake that allow rom model programs to be properly created using -create-app.

1. embedded target: ram, rom and compressed rom binaries have output file with .rom extension.

2. cpm target: .com is the extension. rom model programs seem to crash the cpm emulators I have but I don't think there is anything wrong with them and may actually be shortcomings in the emulators. rom model programs don't make a lot of sense in cpm anyway.

3. zx target: .tap file is the extension and rom model programs work fine. I haven't added if2 cartridge output yet.

The compressed rom model requires zx7 to be called to compress the data section. I'm doing that with a system() call so that should probably be verified to work on all installs after the nightly builds the binaries.


A sample compile for the zx target might be:

// zcc +zx -vn -SO3 -startup=31 -clib=sdcc_ix --reserve-regs-iy --max-allocs-per-node200000 circ.c -o circ -create-app

#include <arch/zx.h>
#include <input.h>

#pragma output CRT_MODEL = 2
#pragma output CRT_ORG_DATA = 40000

unsigned char colour;

unsigned char pattern[][8] = {
{ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }, // solid
{ 0xaa, 0x55, 0xaa, 0x55, 0xaa, 0x55, 0xaa, 0x55 }, // hash
{ 0x88, 0x44, 0x22, 0x11, 0x88, 0x44, 0x22, 0x11 }, // striped
{ 0x99, 0x66, 0x66, 0x99, 0x99, 0x66, 0x66, 0x99 }, // checker
};

static void spec_plot(unsigned int x, unsigned int y)
{
unsigned char *address;

address = zx_pxy2saddr(x,y);
*address |= zx_px2bitmask(x);

*zx_saddr2aaddr(address) = colour;
}


static void CircleOptimized(int xc, int yc, int r)
{
unsigned int x = r;
unsigned int y = 0;//local coords
int cd2 = 0; //current distance squared - radius squared

if (!r) return;


spec_plot(xc-r, yc);
spec_plot(xc+r, yc);
spec_plot(xc, yc-r);
spec_plot(xc, yc+r);


while (x > y) //only formulate 1/8 of circle
{
cd2-= (--x) - (++y);
if (cd2 < 0) cd2+=x++;

spec_plot(xc-x, yc-y);//upper left left
spec_plot(xc-y, yc-x);//upper upper left
spec_plot(xc+y, yc-x);//upper upper right
spec_plot(xc+x, yc-y);//upper right right
spec_plot(xc-x, yc+y);//lower left left
spec_plot(xc-y, yc+x);//lower lower left
spec_plot(xc+y, yc+x);//lower lower right
spec_plot(xc+x, yc+y);//lower right right
}
}


void main(void)
{
unsigned int r;

in_wait_nokey();

for (r=5; r<88; r+=10)
{
colour = (r & 0x3) + PAPER_WHITE;
CircleOptimized(127,87,r);
in_pause(500);
}

in_wait_nokey();

for (r=0; r<88; r+=10)
{
zx_pattern_fill(127,87+r,&pattern[(r/10) & 0x3],300); // ~3*300 bytes of stack space
in_pause(500);
}

in_wait_nokey();
}



------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

I agree with all of the following. Stop creating files that are not requested, get rid of pagination, map file has one copy of symbols (I'd go for an address order listing), sym file is in alphabetical order and global defs in address order.

appmake is looking at the sym file because it's only interested in searching for defc symbols rather than labels in general and the sym file is much shorter.

This change will affect the compile chain :- zcc is depending on files being generated without asking for them so it will have to add options to z80asm to generate files that it needs. We'd also have to look at how the z80 libraries are generated to make sure there's nothing affected there.

I vote go ahead with it.

I have looked into the code and the options handling is rather odd:

1) opts.symtable is by default TRUE (a symbol list is generated), and is set to FALSE with -ns or --no-symtable; the options -s and --symtable exist, but are not necessary. The symbol list is either in a file.sym or file.lst, if a list file is also generated.


I would prefer that a symtable is only generated if requested by -s or --symtable, and it should always be written to file.sym. Options -ns and --no-symtable can be removed.


2) opts.list is by default FALSE (a list file is not generated) and is set to TRUE with -l or --list; the options -nl and --no-list exist but are not necessary. The list file is file.lst.


I would remove options -nl and --no-list.


3) opts.map is similar to opts.symtable - default TRUE and map file generated.


I would prefer that a map file is only generated if requested by -m or --map, and options -nm and --no-map can be removed.


4) file.reloc is only required in some platforms and is always generated.


I would prefer to only generate it if requested by a new option --reloc-info.


5) Why is appmake looking at the file.sym? file.map should contain the same info and is more machine-friendly - no pagination and headers.


6) Pagination in list and sym files, and map files with two copies of the symbols, one ordered by address and one by name are anachronisms of a time where you had to work with printed output copies on paper instead of grep and sort.


I would prefer to remove pagination info and keep only one copy of the symbols in the map file.



Please comment. Can I push through and simplify z80asm, or will something break in the tool chain?
------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
pscust
Well known member
Posts: 194
Joined: Thu Jun 23, 2011 3:34 pm

Post by pscust »

OK. I will go ahead.

Just one clarification: sym files contain a useless cross-reference list
with the pages in the list file where each symbol is used and where it is
defined are defined. This is the page number, not the source line number!
Again, this comes from a time where you had to look at source code in paper.

The list of symbols in the different files are as follows:
- map-file contains all symbols result from link phase, with symbol name,
value and indication if local or global, e.g. "start = 0000, G: test"
- def-file contains all global address symbols from the link phase, i.e. no
DEFCs, in source format, e.g. "DEFC start = $0000 ; Module test"
- sym-file contains all the local and used global symbols of one module in
two separate tables, followed by the cross-reference list, e.g. "start =
0000 : 1*"

In the change I will:
1) get rid of pagination
2) get rid of cross-reference list of symbols
3) standardize the output of map and sym files, adding one '$' before the
value (hex) and adding the Global/Local and module indication to the sym
file
4) only generate files that are requested by options
5) get rid of --no--FILE options
6) map file has only one list of symbols, ordered by address
sym file is in alphabetical order and global defs in address order.
I would rather keep the sym-file in address order, same as the map file,
and the user can sort to get an alphabetic order. Do you agree?

Regards,
Paulo



On Sun, Jun 26, 2016 at 7:00 AM, alvin (alvin_albrecht@...) <
lists@...> wrote:
I agree with all of the following. Stop creating files that are not
requested, get rid of pagination, map file has one copy of symbols (I'd go
for an address order listing), sym file is in alphabetical order and global
defs in address order.

appmake is looking at the sym file because it's only interested in
searching for defc symbols rather than labels in general and the sym file
is much shorter.

This change will affect the compile chain :- zcc is depending on files
being generated without asking for them so it will have to add options to
z80asm to generate files that it needs. We'd also have to look at how the
z80 libraries are generated to make sure there's nothing affected there.

I vote go ahead with it.

I have looked into the code and the options handling is rather odd:

1) opts.symtable is by default TRUE (a symbol list is generated), and is
set to FALSE with -ns or --no-symtable; the options -s and --symtable
exist, but are not necessary. The symbol list is either in a file.sym or
file.lst, if a list file is also generated.
I would prefer that a symtable is only generated if requested by -s or
--symtable, and it should always be written to file.sym. Options -ns and
--no-symtable can be removed.
2) opts.list is by default FALSE (a list file is not generated) and is
set to TRUE with -l or --list; the options -nl and --no-list exist but are
not necessary. The list file is file.lst.
I would remove options -nl and --no-list.


3) opts.map is similar to opts.symtable - default TRUE and map file
generated.
I would prefer that a map file is only generated if requested by -m or
--map, and options -nm and --no-map can be removed.
4) file.reloc is only required in some platforms and is always generated.


I would prefer to only generate it if requested by a new option
--reloc-info.
5) Why is appmake looking at the file.sym? file.map should contain the
same info and is more machine-friendly - no pagination and headers.
6) Pagination in list and sym files, and map files with two copies of the
symbols, one ordered by address and one by name are anachronisms of a time
where you had to work with printed output copies on paper instead of grep
and sort.
I would prefer to remove pagination info and keep only one copy of the
symbols in the map file.
Please comment. Can I push through and simplify z80asm, or will something
break in the tool chain?




------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

- def-file contains all global address symbols from the link phase, i.e. no
DEFCs, in source format, e.g. "DEFC start = $0000 ; Module test"
Except it does include defc resolved by the linker, ie ones that are addresses rather than quantities.

Eg, aliases for function labels might be created in the library.

PUBLIC myfunc_alias
EXTERN myfunc
defc myfunc_alias = myfunc

...


PUBLIC myfunc

myfunc:
...
ret


and those aliases I'd like to keep in the global defs list.


I plan to use the global defs list to park portions of the library in different memory banks. The global defs list could be used (with PUBLIC declarations) on the compile line to link against in preference to library code so that code calls into the memory banks rather than having the linker statically attach more copies of the lib code.

sym file is in alphabetical order and global defs in address order.
I would rather keep the sym-file in address order, same as the map file,
and the user can sort to get an alphabetic order. Do you agree?
I'm just thinking in terms of how I would use it. The sym file is really being used by zcc/appmake to look up compile time options and as a human that's probably what I would use it for so alphabetical order would be most convenient. But also as a human, I've never actually used it :P

I'm not married to alphabetical order, address order would be fine too.



------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

Short note..
Please comment. Can I push through and simplify z80asm, or will something
break in the tool chain?

Regards,
Paulo
Making the ".sym" file optional will break the tool chain to adjust zcc accordingly is not a problem.
Feel free to evolve z80asm if it makes it better.



------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
pscust
Well known member
Posts: 194
Joined: Thu Jun 23, 2011 3:34 pm

Post by pscust »

OK.
Alvin's request to include the DEFC symbols in the .def file is already
checked-in. I'm looking at the sym-file now.

Another option in z80asm that has always bugged me is -rHHHH, to set the
ORG from the command line, accepting the address in hex only. This poses
problems when the address is a parameter from another tool.

I would like to change -r to accept a decimal number, or a hex number with
a '0x' or '$' prefix.

This issue was brought to my attention again after seeing this commit
message:
"allow numerical parameters on command line to be in hex, in particular
-zorg=xxxx"


On Tue, Jun 28, 2016 at 8:22 AM, Stefano Bodrato (
stefano_bodrato@...) <lists@...> wrote:
Short note..
Please comment. Can I push through and simplify z80asm, or will something
break in the tool chain?

Regards,
Paulo
Making the ".sym" file optional will break the tool chain to adjust zcc
accordingly is not a problem.
Feel free to evolve z80asm if it makes it better.




------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

Making the ".sym" file optional will break the tool chain to adjust zcc accordingly is not a problem.
Feel free to evolve z80asm if it makes it better.
I committed changes to zcc yesterday that should ensure things work when z80asm's changes are completed.



------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
Post Reply