Z80AS - new Z80 assembler, compatible with the HiTech tools

[ladislau szilagyi]

Hi,

I allways considered the ZAS assembler as the weak point of the HiTech C compiler.

The biggest ZAS problem is related to its size (38KB), and because of this ZAS is unable to assemble large source files (too small free space remains for the symbols).

 

For example, ZAS fails to assemble the CP/M BDOS source.

Often, using HiTech’s C compiler to compile large C files is not possible because ZAS fails to assemble the intermediate file produced by the compiler (“out of memory” error message).

Recently, I noticed on GitHub an interesting item: the Hector Peraza's ZSM4 assembler.

Unfortunately, it was not well suited to "replace" ZAS: it allowed only uppercase symbols (limited to 6 chars, when written to object code), and the object code format was .REL, compatible with Microsoft's L80 or Digital Research's LINK linkers.

I started to work on this, and I finally succeded to modify-it and test-it.

The result is Z80AS. It runs on Z80-based computers, assembles Z80 source code and is compatible with the HiTech C compiler, ZAS assembler and LINK linker.

Z80AS succeeds to assemble the CP/M BDOS + BIOS, concatenated in a single file (~ 600 symbols ! ).

Z80AS will assemble any file produced by the HiTech's C compiler, when using the -S command line option.

The object code produced by Z80AS is compatible with HiTech's LINK.

I succcessfuly re-compiled (using the -S compiler command line option) and linked the TE editor sources, using Z80AS instead ZAS, and it works.

Z80AS is compatible with ZAS command line & source syntax.

I consider-it a better assembler, compared to ZAS, not only because it can handle larger files, but also because:

·         The undocumented Z80 instructions are supported.

·         Supports conditional assembly. Conditionals may be nested up to 8 levels.

·         Supports a complete standard macro facility including IRP, IRPC, REPEAT, local variables and EXITM. Nesting of macros is limited only by memory.

Please take look at the manual.

Z80AS is published on GitHub at https://github.com/Laci1953/Z80AS 

regards,

Ladislau

[hper...@gmail.com]

Excellent job! But why is Z180 and Z280 support commented out? There is a Z280 front-end to the Hi-Tech C compiler and a set of optimizer rules to emit Z280 opcodes, so Z280 support would be desired.

[ladislau szilagyi]

Thanks Hector for your kind words!

On the topic of Z180 & Z280: I wanted as a first target only support for Z80, and also to keep the size of the assembler al low as possible.

I do not have any Z180 nor Z280 based computer, and I never programmed a Z180 nor Z280. 

As you mentioned, I just "commented out", not erased the Z180 & Z280 -related code. 

If anyone wants to continue to add support to Z180 & Z280, I wish him success! 

I published all the sources.

regards,

Ladislau

[Tony Nicholson]

Great job Ladislau!

I haven't looked at your source yet - but I'll add to Hector's comments that maybe the option to build a version with Z180 and Z280 opcode support would be usefile (and I could get the Z280 optimiser for HI-TECH C to emit instruction mnemonics instead of a bunch of DEFB's in the instruction stream - see https://github.com/agn453/HI-TECH-Z80-C ).

Also curious whether Z80AS implements the absolute to relative branch optimisation of HI-TECH ZAS (-J option).  This is useful for squeezing code-size (requires a 3 pass assember to catch all the forward references though and do symbol table adjustments).

Tony

[Tony Nicholson]

On Friday, January 21, 2022 at 8:53:20 AM UTC+11 Tony Nicholson wrote:

[snip] 

Z180 and Z280 opcode support would be usefile

Damn the spell corrector/my typing - your brain should work out this is USEFUL !

Tony

[ladislau szilagyi]

Hi all,

Fixed a last-minute bug (thanks, mecparts!)

The final proof: I assembled Z80AS using Z80AS, linked and tested the resulting COM. It works.

Enjoy!

Ladislau

[ladislau szilagyi]

Hi Tony,

unfortunately,  relative branch optimisation of HI-TECH ZAS (-J option) is not provided in Z80AS.

And, again:

If anyone wants to continue to add support to Z180 & Z280, I wish him success! 

I published all the sources.

Ladislau

[ladislau szilagyi]

Hi all,

I made a final test: assembled all RTM/Z80 sources with Z80AS, and builded some RTM/Z80 executables, including RTMDEMO. 

Compared the .COM files with the old ones, obtained with ZAS. All identical (except for the DSEG's - which Z80AS initializes with 0).

I added as a new feature the option to use 'custom' PSECT's (PSECT's different from text,data or bss).

I published the up-to-date Z80AS executable.

Z80AS Manual was also updated.

Ladislau 

[ladislau szilagyi]

Hi all,

I added -J as command line option. It will mark in the listing all the places where JP can be substituted with JR.

By the way, I discovered that ZAS has a bug related to his -J option.

Here is the proof:

-------------------------------------------------------

J>zas -j -lcon: x.as


HI-TECH SOFTWARE Z80 Macro Assembler: X.AS
                                                                      Page   1


   1    0000  C3 0082           jp x
   2    0003                    defs 127
   3    0082                    x:
   4
   5    0082  18 7F             jr y
   6    0084                    defs 127
   7    0103                    y:



HI-TECH SOFTWARE Z80 Macro Assembler:
                                                                      Page   2



                      ---------- Symbol Table ----------

 (ABS) 0103#       x 0082        y 0103

0 jump optimizations


J>z80as -j -lcon: x.as
Z80AS Macro-Assembler V4.6

ZSM 4.6 Source file: X                                  Page    1

J 0000' C3 0082'                jp x
  0003' ( 007F )                defs 127
  0082'                         x:

  0082' 18 7F                   jr y
  0084' ( 007F )                defs 127
  0103'                         y:


Errors: 1

ZSM 4.6 Source file: X                                  Page    2

Symbols:
x ................................ 0082'  y ................................ 0103'
Finished.

J>

------------------------------------------------- 

As you noticed, ZAS does not identify the first JP as a possible "jump optimization"; That's wrong (see the JR below in the source file).

In contrast, Z80AS succeeds to identify the first JP as a possible "jump optimization" (the J on the left of the line is the "mark" indicating this; it is flagged as an error to be noticed easily)

I updated the Z80AS executable, source files, tests folders, and the manual.

I dropped ZAS; I will use only Z80AS.

Now, at last, I have a good development environment: CP/M running on RC2014 with 512RAM+512ROM board, HiTech C + Z80AS, and of course TE as editor.

regards,

Ladislau

[ladislau szilagyi]

Hi all,

I have a request for all of you: Please give me a feedback about Z80AS !

I received until now only feedback type "nice, but please add THIS or THAT".

A much more useful feedback would be: "I tested something and it failed..." or "I've found a bug on line xxx in the source file yyy.as".

I know that all of you have your priorities. 

I know that an assembler is a sensitive topic. It must be trusted, otherwise it can become risky to be used.

Exactly that's the issue here. 

Please take a look at the tests included in the TESTS folder. 

I do not assume here any merit, Hector Peraza had done the major work, I simply added some tests.

I tested-it as carefully as I could. But, as you all know, that's not enough.

If not subjected to extensive testing, some bugs can escape un-noticed.

And it would be a shame. The retro computing community deserves the best tools. If something better can be done, it MUST be done.

Thanks for your understanding.

bye,

Ladislau

[Андрей Никитин]

Ladislau

You have done a useful job.

However, compatibility with Hi Tech C ZAS.COM not achieved. Z80AS.COM does not optimize conditional transitions.

You have added the -J option, with which  mark as an error the places where optimization is possible. This is very small and quite inconvenient, since manual editing of the source file is required. In the example you have given, it is not difficult to do this, since it is small.
When compiling a program compiled in C, a much larger assembler file is created and manual work with it is a non-trivial task.

Usually programs are written to simplify manual operations and automate them to eliminate errors.

Your program does not perform this action and, unfortunately, cannot completely replace the Hi Tech assembler. It is sad.

I hope that common sense will win and you will add optimization to your code.

Andrey

суббота, 29 января 2022 г. в 09:49:52 UTC+3, ladislau...@euroqst.ro:

[ladislau szilagyi]

Hi all,

I modified the -J option to behave exactly as in ZAS. 

Jump optimizations are made directly in the code and the listing. 

If -J is requested, a third pass is necessary (unfortunately slowing down the assembly process...).

The manual is updated.

However, Andrey, I have to let you know, with boundless sadness, that even now the Z80AS is not fully compatible with ZAS.

Example: -C command line option is not implemented (I do not know the format of HiTech's Cross Reference files).

But, I consider that the quest to achieve full compatibility with ZAS is a nonsense.

I think that the limited compatibility achieved now is good enough.

This being said, also considering the low interest shown for this topic, I will take a longer break.

Ladislau

[Андрей Никитин]

Ladislau

Initially, your Z80AS macroassembler did not differ much in functionality from ZSM4. The Z80AS macroassembler used the HiTech object file format, which allowed the program to use longer symbol names than ZSM4. The size of the Z80AS executable file turned out to be significantly smaller than that of the regular ZAS macroassembler created by HiTech. In some cases, your macro assembler could be used in the HiTech C compiler. Theoretically, this eliminated the problem of lack of memory for assembling large files. In my practice, the ZAS assembler did not have such situations. However, the Z80AS did not perform jmp optimization, which reduced its attractiveness. Your latest revision has greatly increased the compatibility of the Z80AS with the HiTech macroassembler and expanded the range of possible uses for it. Now it supports almost all important functions, with the exception of working with the double type, since it cannot handle real constants. It seems to me that it will not be difficult for you to add processing for the deff directive. After that, the Z80AS macroassembler will become fully compatible with the original.
The -C option is of little use nowadays, as it is mainly intended to assist in finding the location of variables in the program text. The cross-referenced file assumes the creation of a paper copy. I don't think anyone will do this now. However, for compatibility with the HiTech compiler, you need to add an empty -C option, which the Z80AS macroassembler will accept, but will not do anything with it.
Thanks for corrections. I think that you can make the Z80AS program better than ZSM4 and ZAS and it will be in demand. 

Andrey

понедельник, 31 января 2022 г. в 17:47:42 UTC+3, ladislau...@euroqst.ro:

[ladislau szilagyi]

Hi Andrey,

You say, speaking about "the problem of lack of memory for assembling large files", that "In my practice, the ZAS assembler did not have such situations".

On the opposite, in my practice, ZAS caused many problems caused by large assembler files. The current Z80AS project is a good example. Do you think I split the original zsm.mac in 6 separate sources by caprice or hazard? It was needed in order to be able to assemble using ZAS, otherwise the "out-of-memory" error was omnipresent.

Now, again about being "fully compatible with the original". You seem to not understand my initial statement. Full compatibility is practically impossible. That's a fact. Not an opinion.

And, finally, about the DEFF directive. It's only a small part of all the long way to narrow the gap between the set of features of Z80AS and the set of features of ZAS. Other "missing parts" include ABS,GLOBAL,LOCAL,OVRLD,PURE PSECT flags, cross reference file, -N option, etc.

Now, the strength of a community of people lies in their willingness to contribute to the common effort. Ask Hector Peraza, Tony Nicholson, Miguel Garcia & others about this...

Why don't you try to help a little too?

Let's take the case of DEFF directive. It seems that this topic is very important to you. Well, I made a branch, name-it Z80ASF. It's yours. Add the DEFF directive. I can help. The only place where you need to modify the code is: ZSM6.AS. You need to add DEFF in the OPCODE table, and add code to handle-it. You might get clear ideas about what code is needed by studying https://github.com/agn453/HI-TECH-Z80-C/tree/master/float ; it contains all the necessary missing pieces (atof.c - to be compiled to transform-it to assembler source, and the rest of assembler routines needed to handle floating point operations). All the algorithm, data, code is there.

Be warned: it will add an extensive amount of code ( I estimate an additional 1 to 2 KB). Is it worth it? Maybe.

Success!

Ladislau

[Tony Nicholson]

On Saturday, January 29, 2022 at 5:49:52 PM UTC+11 Ladislau wrote:

I have a request for all of you: Please give me a feedback about Z80AS !

I have not much spare time the past few weeks (since my elderly mum had a fall

and broke her hip).  I'll try to give Z80AS a thorough workout later this week.

Tony

[ladislau szilagyi]

Thanks Tony!

I really appreciate your help!

Ladislau

PS.  Best wishes to your mother!

[ladislau szilagyi]

Hi,

big surprise: I tried to assemble the old, "Clark A. Calkins" CP/M BDOS, using the -J option.

Result:

>z80as -j cpmbdos
Z80AS Macro-Assembler V4.6

Errors: 0

Jump optimizations done: 248
Finished.

>

248 !!!

Same kind of results with the CP/M BIOS...

That gives me ideas about a new, more small, CP/M for my RC2014...

regards,

Ladislau

[Андрей Никитин]

Hi Ladislau

At the moment I am trying to recreate the source code in the C language of HiTech compiler programs for CP/M. This has already been partially done. Right now I am restoring the ZAS macroassembler code. Interested people help me in restoring the text of the programs.

The main goal is to compile recreated programs for the UZI180 operating system. An additional goal, no less important, is to recreate and preserve the source code of this wonderful compiler for history. If obvious errors are detected, mark them in the recreated code and correct them if possible.
Executable files for the UZI 180 operating system should be smaller in size, since the code of some functions is located in the kernel. In addition, there will be a full-fledged possibility of using directories.

The restored code, with gcc is compiled on Linux (Mac OS) and possibly Windows (I haven't checked). Due to this, simultaneously with the reconstruction of programs, a cross-compiler for modern operating systems is obtained. The cross-compiler version can handle larger files.
I have two or three programs left to restore before the end of the work P1.COM , ZAS.COM and maybe OBJTOHEX.COM . The latter is less important to me, since I don't need to generate code to write to ROM.

Your program Z80AS.COM is written in assembler and has a smaller executable file size. It can be useful in the CP/M operating system if it can replace the native macroassembler.

The compiler, producing intermediate code in the assembler, does not use all the possibilities ZAS.COM . Some functions ZAS.COM  are needed to facilitate writing code directly in assembly language, for example macros. In Z80AS.COM  need to add only those features without which it will not be able to process the code generated by the compiler.

Hector Peraza wants to adapt ZSM4 for UZI180, but this is not a priority for him. For my main goal, the work of a macroassembler in a unix-like system is a priority.

When I finish restoring the compiler code, I may be able to adapt your program to my needs. In addition to public benefit, personal interest also plays an important role. I sincerely rejoice at your victories with jmp optimization. But in the beginning, this opportunity was not included in your plans. I understand your interest in attracting additional forces to the development. As far as possible, I will join her, but not immediately.

I sincerely wish you success in your work .

regards,
Andrey

вторник, 1 февраля 2022 г. в 11:05:47 UTC+3, ladislau...@euroqst.ro:

[hper...@gmail.com]

On Tuesday, February 1, 2022 at 9:05:47 AM UTC+1 ladislau...@euroqst.ro wrote:

>z80as -j cpmbdos

Z80AS Macro-Assembler V4.6

Errors: 0

Jump optimizations done: 248
Finished.

>

248 !!!

Same kind of results with the CP/M BIOS...

Beware of compiling the CP/M BIOS with jump optimizations enabled: the BIOS jump table will be very likely optimized, and that will break any programs (or a standard BDOS, for that matter) that access the BIOS functions.

I'm planning to fork your z80as repository as soon as I get some free time, as I would like to have a working Z280 version even if it results in a larger executable.

Hector.

[ladislau szilagyi]

Hi all,

I implemented the DEFF directive.

It will store floating point constants (4 bytes). I tested against ZAS, it works ok.

Updated also the manual. 

Now the Z80AS.COM is near 24KB. 

It's time to stop adding new features.

I consider the Z80AS project finished.

regards,

Ladislau

[ladislau szilagyi]

Hi all,

another big surprise: ZAS does not detect floating point overflows/underflows related to DEFF.

Example: DEFF 12345.67e10000 is generated & listed as 00 00 00 00 , without any error mark : (see below)

J>zas -lcon: x.as

HI-TECH SOFTWARE Z80 Macro Assembler: X.AS
                                                                      Page   1

   1    0000  00 00 80 41       deff 1,2,3      ;must handle also integers
        0004  00 00 80 42
        0008  00 00 C0 42
   2    000C  DE E9 F6 47       deff 123.45678,23.76
        0010  7B 14 BE 45
   3    0014  4C 43 BB E2       deff -12.567e9
   4    0018  AD 8D 84 AA       deff -12.345e-8,78.54
        001C  7B 14 9D 47
   5    0020  00 00 00 00       deff 12345.67e10000     ;overflow (ZAS does not
                                mark this as overflow !!! )
   6

HI-TECH SOFTWARE Z80 Macro Assembler:
                                                                      Page   2



                      ---------- Symbol Table ----------

 (ABS) 0024#


J>

Instead, Z80AS will signal the error:

J>z80as -ltty: x
Z80AS Macro-Assembler V4.6

Z80AS 4.6       Source file: X          Page    1

  0000' 00 00 80 41 00 00       deff 1,2,3      ;must handle also integers
  0006' 80 42 00 00 C0 42
  000C' DE E9 F6 47 7B 14       deff 123.45678,23.76
  0012' BE 45
  0014' 4C 43 BB E2             deff -12.567e9
  0018' AD 8D 84 AA 7B 14       deff -12.345e-8,78.54
  001E' 9D 47
F 0020' 00 00 00 00             deff 12345.67e10000     ;overflow (ZAS does not mark this as overflow !!! )



Errors: 1
Finished.

J>

Therefore, Andrey, not even here Z80AS is not "fully compatible" with ZAS ! (just joking :)

regards,

Ladislau

[Alan Cox]

248 !!!

Same kind of results with the CP/M BIOS...

That's because CP/M is an 8080 program not a Z80 one. There are Z80 clones of CP/M that are smaller and more functional.

It's also why most Z80 assemblers don't turn JP into JR but do support turning JR into JP. That allows for much more explicit control and to write code that has Z80 paths but also runs on an 8080 processor.With a BIOS there are even bigger problems because turning JP into JR makes the loops slower and breaks things like floppy disk drivers.

Alan

[ladislau szilagyi]

Hi all,

to address the concerns of Alan & Hector, regarding BIOS jump optimizations, I added a new directive: JOPT.

When -J is used as option:

- JOPT ON will enable jump optimizations for all following statements (this is the default)

- JOPT OFF will disable jump optimizations for all following statements 

This way, you can select exactly the areas to be excepted from jump optimization.

See reljp.as in tests folder.

New Z80AS version is published, including updated manual.

[ladislau szilagyi]

...and, thank you, Andrey Nikitin, for the  JOPT idea !

Ladislau

[ladislau szilagyi]

Hi all,

at last, I solved one last issue. 

It was related to LINK that "refused" to be called from the C compiler, if Z80AS was used instead of ZAS. 

Issue fixed. 

I published the fixed version.

Z80AS is now fully compatible with HiTech's C compiler. 

If Z80AS.COM is renamed ZAS.com, the C compiler will work without any problem, compiling, assembling larger files (compared to the original), and linking object files into executables.

Finally, I can declare now that the Z80AS project target was fulfilled.

It's time for me to use Z80AS to its real potential.

First target: I "merged" the Z80AS (zas1.as, zas2.as, zas3.as, zas4.as, zas5.as, zas6.as) source files into a large z80as.as. 

As in the original Hector Peraza's ZSM4. 

But, this time, I can assemble this huge file (more than 200KB), using Z80AS !

And, using TE512, I can edit-it on RC2014 !

I will shortly publish this version too, it's more easy to manage.

Second target: RTM/Z80, next week. 

At last, I will return to a decent set of source files, without being constrained to split large files into small parts.

What a relief to have a decent assembler!

Ladislau

[ladislau szilagyi]

Hi all,

I published on GitHub:

- the Z80AS source files, ready to be assembled with Z80AS (folder SOURCES-Z80AS in the Z80AS GitHub entry)

- the RTM-Z80 source files, ready to be assembled with Z80AS (folder SOURCES-Z80AS in the RTM-Z80 GitHub entry)

I assembled all RTM-Z80 sources with Z80AS, recompiled the RTM-Z80 C demos (replacing ZAS.com with Z80AS.COM).

All RTM-Z80 tests & demos run without any problem, on RC2014(SC108 or 512+512MemoryModule or 128MemoryModule) & Z80SIM on CygWin.

Another proof that Z80AS works fine.

And, of course, the big advantage to have the Z80AS & RTM-Z80 source files in a decent shape, without being constrained to split them into many small pieces.

The relative large size of some source files is not anymore a problem for me, given the TE editor!

Mission accomplished.

Ladislau

[ladislau szilagyi]

Hi all,

I finished to comment-out all the remaining Z180 & Z280 instructions code processing, and I gained 2KB. 

Re-tested, all Z80 instructions are generated ok.

Now, Z80AS.COM size is back at 22KB. Exactly 16KB less than ZAS.COM.

I published the new version on GitHub.

Ladislau

[ladislau szilagyi]

Hi,

I stored on GitHub a new version (v4.7) and also updated the manual.

What changed:

- Some bugs were fixed (e.g. in an very rare situation, with a source containing hundreds of consecutive DEFW's , all containing relocatable addresses, object file was not built correctly)

- Option -D added, to make "DEFS buffers initialization with zero" optional

- Option -X added, to store in the object file only the global symbols (by the way, this is NOT documented in the original HiTech ZAS manual...but the C compiler, when -X is used at compile time, generates the assembly command line with -X included...nice surprise...)

- Added SLL (!!!) accepted as "Z80 instruction"... the C compiler generates-it instead the "usual" SLA...why? I do not know ... I just hope that there are NOT anymore "exotic" Z80 opcodes used in the HiTech CGEN.COM... anyway, I do not understand why these strange op-codes were used, instead of the usual op-code ... another nice surprise...

- Added *TITLE, *HEADING, *LIST, *EJECT (*INCLUDE was already added in the v.4.6)

- Some code optimizations were done ... I was able to keep the .COM size at 22KB

Ladislau

[Андрей Никитин]

It's nice to see macro-assembler continue to evolve. However, it is not entirely clear why it is needed?
This macro-assembler can be:
1. An alternative to HiTech ZAS. In this case, Z80AS, in addition to extensions, should allow as a subset to assemble all the code that processes the original macro-assembler from HiTech. In this case, it can be used instead of the original. To do this, it must be fully compatible in terms of parameters with the original one and use the default values ​​for these parameters. The Z80AS macro-assembler must understand any parameters of the original one, and if it does not implement some of its capabilities, it must not react to them in any way. With a smaller executable file size, the Z80AS macro-assembler will be able to assemble source files in larger assembler and possibly faster than the original one, due to the fact that it is written in assembly language. Additional features can ease the hard work of a programmer.
2. An alternative to Microsoft's M80 macro-assembler. M80 was written a long time ago. It was limited by the FORTRAN and COBOL programming languages. From them, M80 and the L80 linker received character length limits. In addition, the cost of RAM also influenced this, as a result of which at that time personal computers often did not have the maximum available memory of 64K. Now these restrictions are no longer significant.
The macro-assembler ZSM4 Hector Peraza tried to become a similar replacement. It is almost completely compatible with the M80 and expands the types of processors allowed to the Z180 and Z280.
Using the object file format and the HiTech linker allows you to remove character length restrictions, however, the capabilities of the Z80AS do not allow it to become a full-fledged replacement for the M80. It is clear that the Z80AS is not a commercial product, but the author should have an ultimate goal for which he does all this. So far, Z80AS cannot replace either Microsoft's M80 or HiTech ZAS. I still cannot use it in these qualities and I cannot refuse programs written more than 30 years ago, especially since the M80 and ZAS were able to work badly or poorly with overlay programs, which, in principle, does not imply the Z80AS macro-assembler. The intentions of the original programmers were much broader.

It seems to me that achieving the first option (an alternative to HiTech ZAS) will require less effort.
The second option is also possible, but less promising.
If you leave everything as it is, then most likely only the author of the program will use the Z80AS.

I apologize for the criticisms. In no way did I mean to offend the author of the Z80AS. He is a good programmer and perhaps the above will be useful to him in his future work and a wonderful hobby.

I wish you success in your work.

Andrey 

суббота, 19 марта 2022 г. в 17:02:21 UTC+3, ladislau...@euroqst.ro:

[ladislau szilagyi]

Well, this could be for me a very good occasion to get some feedback, at last.

I have (to all of you) the following simple questions:

1. Can anyone forward me a C source file that cannot be compiled & assembled using the HiTech C compiler + Z80AS ? This may be done simply by saving ZAS.COM (e.g. renaming it ZASOLD.COM), then renaming Z80AS.COM to ZAS.COM, then trying to compile your C source files, to see if this works or not. You may try to build C apps & execute them, in order to be sure that the executables built this way are working as designed. I currently use Z80AS assembled with Z80AS, TE compiled (using Z80AS instead of ZAS), RTM-Z80 sys & apps assembled with Z80AS. Every single one works. More than that, I can handle very nicely large source files, having an appropriate editor & assembler. I found many cases when C compiling failed because ZAS failed ("out-of-memory") but Z80AS worked.

2. Can anyone forward me an assembler source file ( from one of your projects ), which cannot be assembled with Z80AS, but can be assembled with ZAS ? I am aware that Z80AS is not fully compatible with ZAS, but in my opinion the current already obtained limited compatibility is good enough in order to allow the day-to-day use of Z80AS, without any significant constraint. On the other hand, I can give many examples of files that ZAS fails to assemble, but Z80AS can handle.

I'm waiting also for bug reports, please!

regards,

Ladislau

[Phillip Stevens]

Hi Ladislau,

The n-body benchmark won’t compile under hitech c 3.09-12 so that’s a useful test for you, perhaps.

https://github.com/z88dk/z88dk/wiki/Benchmarks

The code, already adjusted for hitech c is located here.

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

The hitech c 7.80 compiler directory provides some further adjustments to the n-body code that help it successfully compile, so that code can also be used as a reference for success.

I tried to compile this code just a few days ago, and the issue was around structures and memory, iirc. 

Cheer, P

[ladislau szilagyi]

Hi Phillip,

I use the "original" HiTech C v3.09, without any updates/improvements/etc.

The source code you mentioned ( https://github.com/z88dk/z88dk/tree/master/libsrc/_DEVELOPMENT/EXAMPLES/benchmarks/n-body ) does not reach the assembler step, it stops at CGEN.

What issues I have found:

- #defines not placed at column 1 - fixed by moving them at column 1

-  // comment - fixed by changing with /* */

- #pragma rejected - fixed by removing the whole #ifdef __Z88DK...

- the final one:

0:CGEN $CTMP2.$$$ $CTMP1.$$$
NBODY.C:124:    Expression too complicated

at :

120 #define NBODIES 5
121 struct planet bodies[NBODIES] = {
122  {                               /* sun */
123    0, 0, 0, 0, 0, 0, solar_mass
124  },

...at this stage, I quit.

Please fix the code to pass CGEN... then, we will see what happens at assembly time.

thanks for the feedback,

Ladislau

PS. The funny thing is that I could not found the "iirc" string in ZAS.COM ... are you sure that "iirc" was mentioned in the ZAS error message?

[Tony Nicholson]

On Sun, 20 Mar 2022 at 14:29, ladislau szilagyi <ladislau...@euroqst.ro> wrote:

PS. The funny thing is that I could not found the "iirc" string in ZAS.COM ... are you sure that "iirc" was mentioned in the ZAS error message?

Just clarifying - “iirc” is “if I remember correctly” or “if I recall correctly” - one of those everyday phrase abbreviations that may not be obvious to a non-native English speaker.

Tony

--

Tony Nicholson <tony.ni...@computer.org>

[ladislau szilagyi]

Hi all,

I just added to Z80AS the "missing" part of the ZAS functionality : the PSECT flags (abs, local, global, ovrld, pure).

I uploaded on GitHub the modified files & the updated manual.

I consider that now Z80AS is FULLY compatible with ZAS, from the perspective of the assembler features. 

For the command line part, the only "missing" options are the -C option (I do not know the cross-reference file format), -U option (this is default) and -W option (I consider this one useless).

regards,

Ladislau

[Phillip Stevens]

I use the "original" HiTech C v3.09, without any updates/improvements/etc.

The source code you mentioned ( https://github.com/z88dk/z88dk/tree/master/libsrc/_DEVELOPMENT/EXAMPLES/benchmarks/n-body ) does not reach the assembler step, it stops at CGEN.

0:CGEN $CTMP2.$$$ $CTMP1.$$$
NBODY.C:124:    Expression too complicated

120 #define NBODIES 5
121 struct planet bodies[NBODIES] = {
122  {                               /* sun */
123    0, 0, 0, 0, 0, 0, solar_mass
124  },

Just to close this off too.

The issue (for the past 5 years) has been that there are some constant expressions that can't be calculated by the compiler.

So they just have to be calculated by hand.

I've done this and now the benchmark compiles and runs, and actually produces quite a good result.

I'm not sure why the resulting N-BODY.COM file is so large, unless there's something I've missed with the linker.

Cheers, Phillip

[ladislau szilagyi]

Hi Phillip,

the executable is large because you used an older version of Z80AS, which "filled" with zero all the BSS DEFS buffers. 

Now, with the last version of Z80AS, this happens only if you will use the -D option, the default is to NOT initialize the BSS DEFS buffers...please download the last version and give-it a try.

So, in the end, it was not the Z80AS fault. I'm happy to have from you the confirmation...

Anyone finding a bug? Please report-it and I will fix-it...

regards,

Ladislau

[Fred Weigel]

Ladislau

https://github.com/ratboy666/mtrel/blob/master/objtomac.c

is my tool to convert OBJ to MAC that can then be assembled to REL. Note that I do not fully understand the OBJ format -- note that at line 106 I assume only a single

BSS section per OBJ file. I assume that holds? Also, Notice that I use the sequence

 CSEG

 OFFSET SET 01234H

 ORG OFFSET

which could also be DSEG. OFFSET is then used in future relocations. This technique does not appear possible in Z80AS?

As a "feature request" -- It would be nice to have a directive (not a command line switch) to produce AM9511 floating numbers in DEFF (Maybe *AM9511). Then asm() could pass

that through to the AS file, and we could link with a am9511 library for fast floats. Pretty sure Phillip would enjoy that too.

Thanks in advance

Fred Weigel

[Fred Weigel]

And, as an aside -- if you make CSEG/ORG DSEG/ORG work per ZSM/M80 -- PHASE is almost natural. Makes it much easier to

write relocating code. See https://github.com/ratboy666/r/blob/main/R.MAC for a simple example of such a use of .phase.
Line 371 is where the relocated code starts.

[ladislau szilagyi]

Hi Fred,

1. the "sequence" (with a small change - EQU instead of SET ) works well on Z80AS, for CSEG & DSEG:

J>type t.as
 CSEG
 OFFSET EQU 01234H
 ORG OFFSET
LD A,1
 CSEG
 OFFSET EQU 01234H
 ORG OFFSET
DEFB 1,2,3

J>z80as -ltty: t
Z80AS Macro-Assembler V4.7

Z80AS 4.7       Source file: T          Page    1

                                 CSEG
  1234  =                        OFFSET EQU 01234H
  1234  =                        ORG OFFSET
  1234  3E 01                   LD A,1
                                 CSEG
  1234  =                        OFFSET EQU 01234H
  1234  =                        ORG OFFSET
  1234  01 02 03                DEFB 1,2,3


Errors: 0

Z80AS 4.7       Source file: T          Page    2

Symbols:
OFFSET ........................... 1234
Finished.

J>

2. I do not know the format of AM9511 floating numbers, nor have the source code necessary for an "atof" to AM9511 format... Phillip, can you help?

3. The issue of PHASE/DEPHASE: it is implemented in ZSM 4.6 . I dropped-it because ZAS has no such PHASE/DEPHASE.

My target was to obtain a ZAS compatible assembler.

Now, have I obtained full compatibility? It depends on the perspective you are using. In my view, yes, because I have now implemented all the features, related to the source file that is processed by the assembler (syntax & semantics), that are mentioned in the ZAS manual; however, I have not yet fully implemented all the command line options...e.g. I do not know the format of the cross-reference file built by the ZAS -C option, therefore I did not implemented the -C option... 

Ladislau

[ladislau szilagyi]

Sorry, my mistake, the correct example for CSEG/DSEG/OFFSET is:

J>z80as -ltty: t
Z80AS Macro-Assembler V4.7

Z80AS 4.7       Source file: T          Page    1

                                 CSEG
  1234  =                        OFFSET EQU 01234H
  1234  =                        ORG OFFSET
  1234  3E 01                   LD A,1

                                 DSEG

  1234  =                        OFFSET EQU 01234H
  1234  =                        ORG OFFSET
  1234  01 02 03                DEFB 1,2,3


Errors: 0

Z80AS 4.7       Source file: T          Page    2

Symbols:
OFFSET ........................... 1234
Finished.

J>

...it works with any kind of segments...

Ladislau

[Fred Weigel]

My am9511 project includes the functionality needed -- in C,

https://github.com/ratboy666/am9511/blob/main/floatcnv.c

That would allow for the use of hi-tech, microsoft, am9511, or ieee formats.

Thanks for looking into it!

Fred

(Phillip has used the AM9511 chip, and has worked with my emulator)

[Fred Weigel]

But, that goes against the doc:

"3.4.14 ...ORG changes the current segment to Absolute Code (ASEG, or PSECT text,abs), and sets a new

program counter (PC).

..."

I want CSEG or DSEG to be set to a new location by ORG

For example:

CSEG

label:

    jmp 0

 HERE EQU $-2

    ORG HERE

    dw label

   

should generate

   jmp label

but that goes against the doc... I'll try it!

Fred

On Sunday, March 20, 2022 at 11:57:19 PM UTC-4 ladislau...@euroqst.ro wrote:

[ladislau szilagyi]

ups...you're absolutely right!

ORG switches to ASEG and sets the PC... exactly as in ZAS.

Sorry...

Ladislau

[Phillip Stevens]

Hi Ladislau,

2. I do not know the format of AM9511 floating numbers, nor have the source code necessary for an "atof" to AM9511 format... Phillip, can you help?

Yes, I've an overview of the format used by the Am9511A APU. It is based on (is the same as) the original Lawrence Livermore (National) Labs Floating Point library. I guess that AMD had to start somewhere when they developed their first device.

I've some code for converting between IEEE and AM9511 here, but this is not the same as the Hitech-C floating point format.

I believe that Fred has built that code though.

3. The issue of PHASE/DEPHASE: it is implemented in ZSM 4.6 . I dropped-it because ZAS has no such PHASE/DEPHASE.

My target was to obtain a ZAS compatible assembler.

Just for reference, in z88dk the assembler has the PHASE/DEPHASE commands, and it respects the ALIGN commands too. The purpose is, as you'd expect, to allow a section of code to be assembled as if it were to be run in another location. To allow it to be relocated without being adjusted.

I've used that here (in an 8085 CP/M BIOS) to allow the bios to be written to ROM in one location, but be copied to the correct location and run from there. It is quite a helpful capability to have, particularly when you don't have relative jump instructions.

Cheers, P

[ladislau szilagyi]

Hi Fred, Hi Phillip,

are you suggesting that I shall add a DEFF9511 (to store a floating point constant in 9511 format) in Z80AS?

This will solve the definition of floating point constants using the AMD9511 format... but, a problem remains... the HiTech standard library knows only the HiTech floating point format.

Of course, another library may be used, for this special case...

Ladislau

[ladislau szilagyi]

Hi,

on the topic of PHASE/DEPHASE.

I used for this purpose a "custom" segment:

PSECT CUST

(code)

then, al link:

LINK pCUST=0/1000H 

that is, CUST's code will be linked for execution at 0, but loaded in the output file at 1000H

This does not solve the problem?

Ladislau

[Fred Weigel]

Actually,

I would change what DEFF does: *AM9511, *HITECH (default *HITECH). Just changes DEFF.

The use is: add

#asm

*AM9511

#endasm

into a C source, then link with am9511.lib to provide new arithmetic. Currently, I use AM9511 with FORTRAN and BASIC, but always need conversion! Slows stuff down.

Something like this allows pretty much full-speed floats.

May throw off the Hi-TECH OPTIM.COM optimizer -- but it gets to a really good place!

The Hi-TECH CGEN.COM won't produce anyrhing but DEFF. But, we could jam into the assembler.

Fred

[Fred Weigel]

Thanks! That does work for my needs!

Fred

[ladislau szilagyi]

Hi Fred,

do you suggest that I may add, at the Z80AS command line level, an option named (let's say) -F , with possible use:

>Z80AS -FAM9511 source.as

(-F default value will be, of course, HI TECH's format)

Am I correct?

Ladislau

[Fred Weigel]

No... because C.COM can't generate that... 

But, consider this HI-TECH C snippet:

#asm

*EJECT

#endasm

int main(int ac, char **av) {

    return 0;

}

Now *EJECT gets copied through to the assembler!

So, if you introduce *AM9511 that gets copied through, and can change what DEFF produces! This is controlled by the C source!

Now, this even works when OPTIM.COM is used -- as long as the #asm/#endasm section is outside of any function.

Fred

[ladislau szilagyi]

Ok, I got it...seems simple.

I must first obtain an assembler routine from your C code that converts fp formats...

I will try to use -S compiler option to obtain the assembler code... let's see.

regards,

Ladislau

[ladislau szilagyi]

Hi Fred, Hi Phillip,

I found these two descriptions of the fp format:

/*--------------------------------------------------------------------------------------------
Am9511 Floating Point Format
Automatic conversion from the Am9511A hardware floating point format and the IEEE-754 single precision floating point format is included. The Am9511A format is used only when loading and unloading the APU. All internal floating point uses IEEE-754 single precision.

The format for floating point values in the Am9511A is given below. The mantissa is expressed as a 24-bit (fractional) value; the exponent is expressed as an unbiased two's complement 7-bit value having the range of -64 to +63. The most significant bit is the sign of the mantissa (0 = Positive, 1 = negative), for a total of 32 bits. The binary point is assumed to be to the left of the most significant mantissa bit (bit 23). All floating point values must be normalised. Bit 23 must always be equal to 1, except for the value zero, which is represented by all zeros.

  dehl =  seeeeeeee 1mmmmmmm mmmmmmmm mmmmmmmm (s-sign, e-exponent, m-mantissa)
---------------------------------------------------------------------------------------------
HiTech Floating Point Format
;        The format of a floating point number is as follows:
;
;                        ------------
;                        *   sign   *        1 bit
;                        *----------*
;                        * exponent *        7 bits
;                        *----------*
;                        * mantissa *        24 bits, normalized
;                        ------------
;
;                Note that the number is stored with the mantissa in the
;                low order bytes, i.e. the sign is the most significant
;                bit of the most significant byte.
---------------------------------------------------------------------------------------------*/

Is this info correct?

I'm asking because it seems to me that the two representations are identical...am I missing something?

Ladislau

[ladislau szilagyi]

Hi Fred, Hi Phillip,

I studied Fred's floatcnv.c routines, I see now that the formats are different.

I'm busy these days, but I will get the job done till the end of the week.

Ladislau

[Phillip Stevens]

Ladislau wrote:

Hi Fred, Hi Phillip,

I studied Fred's floatcnv.c routines, I see now that the formats are different.

/*--------------------------------------------------------------------------------------------
Am9511 Floating Point Format
Automatic conversion from the Am9511A hardware floating point format and the IEEE-754 single precision floating point format is included. The Am9511A format is used only when loading and unloading the APU. All internal floating point uses IEEE-754 single precision.

The format for floating point values in the Am9511A is given below. The mantissa is expressed as a 24-bit (fractional) value; the exponent is expressed as an unbiased two's complement 7-bit value having the range of -64 to +63. The most significant bit is the sign of the mantissa (0 = Positive, 1 = negative), for a total of 32 bits. The binary point is assumed to be to the left of the most significant mantissa bit (bit 23). All floating point values must be normalised. Bit 23 must always be equal to 1, except for the value zero, which is represented by all zeros.

  dehl =  seeeeeeee 1mmmmmmm mmmmmmmm mmmmmmmm (s-sign, e-exponent, m-mantissa)
---------------------------------------------------------------------------------------------
HiTech Floating Point Format
;        The format of a floating point number is as follows:
;
;                        ------------
;                        *   sign   *        1 bit
;                        *----------*
;                        * exponent *        7 bits
;                        *----------*
;                        * mantissa *        24 bits, normalized
;                        ------------
;
;                Note that the number is stored with the mantissa in the
;                low order bytes, i.e. the sign is the most significant
;                bit of the most significant byte.
---------------------------------------------------------------------------------------------*/

Is this info correct?

I'm asking because it seems to me that the two representations are identical...am I missing something?

I found this summary of the format in the htc v7.80 manual.

This raises some possible confusion for me.

If the mantissa is in twos complement, why is a sign bit needed?

Well the looking at fabs.c in Tony's repository, it seems the sign bit actually carries the sign, and the mantissa is always assumed positive.

But, if the mantissa is always positive, is the first bit always zero? Or is the binary place assumed to the left of the bit 23?

float.as in Tony's repository is helpful here and seems to resolve all the possible confusion. The first bit must be always be 1, and so the binary point is left of bit 23.

Hope that's useful.

Cheers, Phillip

[ladislau szilagyi]

Hi,

I added the *AM9511 directive, updated DEFF, updated the manual, uploaded the new Z80AS.COM, added am9511.as in tests folder.

It seem to work... I do not have any AM9511 board, so it is impossible to me to verify if the DEFF produces the desired effect.

I hope that Fred / Phillip can test-it. 

Please add some tests to check the situation when DEFF HITECH does not produce underflow/overflow, but AM9511 does...

regards,

Ladislau

[ladislau szilagyi]

example:

J>z80as -ltty: t
Z80AS Macro-Assembler V4.7

Z80AS 4.7       Source file: T          Page    1

                                *AM9511
  0000' 00 00 00 00             deff 0
  0004' 00 00 80 01 00 00       deff 1,2,3      ;must handle also integers
  000A' 80 02 00 00 C0 02
  0010' 00 00 80 00             deff 0.5
  0014' DE E9 F6 07 7B 14       deff 123.45678,23.76
  001A' BE 05
  001C' 4C 43 BB A2             deff -12.567e9
  0020' AD 8D 84 EA 7B 14       deff -12.345e-8,78.54
  0026' 9D 07
F 0028' 00 00 00 00             deff 12345.67e10000     ;overflow (ZAS does not mark this as overflow !!! )

Errors: 1
Finished.
J>

Are the numbers OK?

Ladislau

[ladislau szilagyi]

compare with this: (the HITECH format)

J>z80as -ltty: t
Z80AS Macro-Assembler V4.7

Z80AS 4.7       Source file: T          Page    1

  0000' 00 00 00 00             deff 0

  0004' 00 00 80 41 00 00       deff 1,2,3      ;must handle also integers
  000A' 80 42 00 00 C0 42
  0010' 00 00 80 40             deff 0.5
  0014' DE E9 F6 47 7B 14       deff 123.45678,23.76
  001A' BE 45
  001C' 4C 43 BB E2             deff -12.567e9
  0020' AD 8D 84 AA 7B 14       deff -12.345e-8,78.54
  0026' 9D 47

F 0028' 00 00 00 00             deff 12345.67e10000     ;overflow (ZAS does not mark this as overflow !!! )

Errors: 1
Finished.

J>

Seems OK?

[Fred Weigel]

Thanks!

Will test! For reference

https://github.com/ratboy666/am9511/blob/main/cnvtest.c

contains some test vectors that I will apply (used to validate floatcnv.c)

Fred

[ladislau szilagyi]

J>z80as -ltty: t
Z80AS Macro-Assembler V4.7

Z80AS 4.7       Source file: T          Page    1

                                *am9511
  0000' 00 00 A0 03             deff 5.0
  0004' CD CC CC 7D             deff 0.1
  0008' 52 49 9D F6             deff -0.0006


Errors: 0
Finished.

J>

...the only issue is at -0.0006

in cvvtest.c 0x51, 0x49, 0x9d, 0xf6

in my test:  52 49 9D F6

is this "normal" ? I suspect that it's because first I transform-it to HITECH and only then transform from HITECH --> AM5911 ...

any opinions on this?

Ladislau

[Андрей Никитин]

Ladislau
during the period of frequent changes, I propose to add the compilation date to the text line informing about the
macro assembler. This will eliminate the use of previous versions of the program.

Andrey

вторник, 22 марта 2022 г. в 14:10:58 UTC+3, ladislau...@euroqst.ro:

[ladislau szilagyi]

Hi Fred, Hi Phillip,

one week passed, an I had no feedback from you on the topic of the AM9511-formatted DEFF in Z80AS.

It seems to me that, for both of you, this topic's priority is very low....

Ladislau

[ladislau szilagyi]

Hi all,

while working on the CGEN.COM optimization, I found and fixed a Z80AS bug related to the -J option (jump optimization).

In extremely rare cases, the bug caused wrong relative jump address being generated. It's fixed now.

I published the updated Z80AS sources & executable.

If you are currently using Z80AS in your projects, please download & use the new, fixed Z80AS.COM.

Ladislau

[Fred Weigel]

Thanks Ladislau!

Updated... I compiled a few programs, and so far, works fine!

FredW

[ladislau szilagyi]

Hi Fred,

thanks for the feedback!

Any news on AM9511 used in Z80AS?

Ladislau

[ladislau szilagyi]

Hi,

I fixed today another bug & uploaded a new Z80AS executable, sorry...

Testing never ends, right?

regards,

Ladislau

[Richard Deane]

Hopefully you add this to your scripted tests so that a regression test is easy, perhaps run under a fast z80/cpm emulation to get speed, then compare test output files to see they are all good, not needing to manually check each test case.

Microshell gives good command line redirection to capture output and for script input, and also cpm3 has useful get and put commands.

Richard

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/abd294dd-a524-40ec-b0cd-7a7d0dd65c3an%40googlegroups.com.

[ladislau szilagyi]

Hi all,

six months ago I added to my Z80AS assembler a special feature:  the AM9511-formatted DEFF.

It was added as a response to someone's request.

Since then, I had not received any feedback / responses (does it work?)

Any remarks?

Ladislau

[fridtjof.ma...@gmail.com]

Ladislau

It appears to work just fine! Thanks

FredW

[ladislau szilagyi]

Hi,

nice to hear this! 

Better late than never...

Ladislau

[ladislau szilagyi]

Hi,

I just published a new version ( 4.8 ) of Z80AS on GitHub ( https://github.com/Laci1953/Z80AS and https://github.com/Laci1953/HiTech-C-compiler-enhanced/tree/main/Z80AS )

The only modification is that I increased the number of maximum allowed JP optimizations from 128 to 512.

It was not a bug but a constraint.

It was necessary because I noticed that, for large C source files, when compiling with -O option, the OPTIM was building assembler files that frequently needed more than 128 JP optimizations, when assembled using the -J option (example: compiling P1EXPR.C, from the 512KB version of P1, results in 308 JP optimizations ! )

The v4.7 version of Z80AS limited the JP optimizations to a maximum of 128.

Now, the limit is 512. I hope that's quite enough...

No other bugs were detected since the previous version (4.7) was published on 27 May 2022.

Ladislau

[Richard Kiernan]

Peculiar situation I had when I set this up on an RC2014 Mini with the CP/M kit. I hadn't set up Z80AS or Hi-Tech C before. I uploaded the z80as.hex file to CP/M, used LOAD to transform it into an executable, used PIP to set it to ZAS.COM, then set things up for a "Hello, world" compilation as a sanity test. When I was running the C.COM script, I had a peculiar error during the linking stage: "Entry point multiply defined". Notably, when using Z80AS on its own, I wasn't getting any errors even when linking the object file manually. I found and downloaded the previous version, ran the command again and it went through fine as expected and I believe I re-uploaded the z80as.hex file to CP/M, using LOAD and PIP as before and it's seemed to work since. Would you have any advice on what to do if this happens again, like with a later version?

[ladislau szilagyi]

Hi Richard,

I made the same test: (on RC2014, 512KB RAM board, ACIA)

D>type test.c
#include <stdio.h>
void main(void)
{
printf("hello world!");
}

D>

D>c -v -o test.c
HI-TECH C COMPILER (CP/M-80) V3.09
Copyright (C) 1984-87 HI-TECH SOFTWARE
0:CPP -DCPM -DHI_TECH_C -Dz80 -I TEST.C $CTMP1.$$$
0:P1 $CTMP1.$$$ $CTMP2.$$$ $CTMP3.$$$
0:CGEN $CTMP2.$$$ $CTMP1.$$$
0:OPTIM $CTMP1.$$$ $CTMP2.$$$
0:ZAS -J -N -oTEST.OBJ $CTMP2.$$$
Z80AS Macro-Assembler V4.8

Errors: 0
Finished.
ERA $CTMP1.$$$
ERA $CTMP2.$$$
ERA $CTMP3.$$$
0:LINK -Z -Ptext=0,data,bss -C100H -OTEST.COM CRTCPM.OBJ TEST.OBJ LIBC.LIB
ERA TEST.OBJ
ERA $$EXEC.$$$

D>
D>test
hello world!

D>

It's the latest version of my enhanced HiTech C compiler ans Z80AS (v4.8)... and, as you see, it works.

I tried-it also on Z80SIM, it works ok also here:

J>c -v -o test.c
HI-TECH C COMPILER (CP/M-80) V3.09
Copyright (C) 1984-87 HI-TECH SOFTWARE
0:CPP -DCPM -DHI_TECH_C -Dz80 -I TEST.C $CTMP1.$$$
0:P1 $CTMP1.$$$ $CTMP2.$$$ $CTMP3.$$$
0:CGEN $CTMP2.$$$ $CTMP1.$$$
0:OPTIM $CTMP1.$$$ $CTMP2.$$$
0:ZAS -J -N -oTEST.OBJ $CTMP2.$$$
Z80AS Macro-Assembler V4.8

Errors: 0
Finished.
ERA $CTMP1.$$$
ERA $CTMP2.$$$
ERA $CTMP3.$$$
0:LINK -Z -Ptext=0,data,bss -C100H -OTEST.COM CRTCPM.OBJ TEST.OBJ LIBC.LIB
ERA TEST.OBJ
ERA $$EXEC.$$$

J>test
hello world!
J>

I'm a little confused why this happens in your situation, but the error message tells that there are two END START statements... why? I cannot guess why...

Ladislau

[Richard Kiernan]

OK, I've done some more testing on this and noticed that while I'd uploaded the Z80AS.HEX file for v4.8 again, I had not actually run LOAD again on it since installing v4.7. Testing both versions in sequence, using the rest of the stock Hi-Tech C components from the download at http://www.z80.eu/c-compiler.html, I see the following:

v4.7:

B>c -v -o test.c

HI-TECH C COMPILER (CP/M-80) V3.09
Copyright (C) 1984-87 HI-TECH SOFTWARE
0:CPP -DCPM -DHI_TECH_C -Dz80 -I TEST.C $CTMP1.$$$
0:P1 $CTMP1.$$$ $CTMP2.$$$ $CTMP3.$$$
0:CGEN $CTMP2.$$$ $CTMP1.$$$
0:OPTIM $CTMP1.$$$ $CTMP2.$$$
0:ZAS -J -N -oTEST.OBJ $CTMP2.$$$

Z80AS Macro-Assembler V4.7

Errors: 0
Finished.
ERA $CTMP1.$$$
ERA $CTMP2.$$$
ERA $CTMP3.$$$
0:LINK -Z -Ptext=0,data,bss -C100H -OTEST.COM CRTCPM.OBJ TEST.OBJ LIBC.LIB
ERA TEST.OBJ
ERA $$EXEC.$$$

B>test
Hello, world

v4.8:

B>c -v -o test.c

HI-TECH C COMPILER (CP/M-80) V3.09
Copyright (C) 1984-87 HI-TECH SOFTWARE
0:CPP -DCPM -DHI_TECH_C -Dz80 -I TEST.C $CTMP1.$$$
0:P1 $CTMP1.$$$ $CTMP2.$$$ $CTMP3.$$$
0:CGEN $CTMP2.$$$ $CTMP1.$$$
0:OPTIM $CTMP1.$$$ $CTMP2.$$$
0:ZAS -J -N -oTEST.OBJ $CTMP2.$$$
Z80AS Macro-Assembler V4.8

Errors: 0
Finished.
ERA $CTMP1.$$$
ERA $CTMP2.$$$
ERA $CTMP3.$$$
0:LINK -Z -Ptext=0,data,bss -C100H -OTEST.COM CRTCPM.OBJ TEST.OBJ LIBC.LIB

TEST.OBJ: 12: entry point multiply defined
ERA $$EXEC.$$$

B>test
Hello, world

I can see that both versions generate working executables for this test, but I'm worried that I may come into problems later on due to the entry point warning on the .OBJ file.

Interestingly, when running Z80AS on its own on my own assembly file, I'm also getting an entry point error when running LINK, this time on v4.7, but not on v4.8:

v4.7:

B>zas onescomp.as
Z80AS Macro-Assembler V4.7

Errors: 0
Finished.

B>link -oonescomp.com onescomp.obj
no start record: entry point defaults to zero (warning)

v4.8:
B>zas onescomp.as

Z80AS Macro-Assembler V4.8

Errors: 0
Finished.

B>link -oonescomp.com onescomp.obj

In both cases, it seems to result in the same data in the executable file.

(Please note that I have normally stored my source files on drive E:, using an ENVIRON file as defined in the Hi-Tech C manual to specify the location of the compiler passes, but have run these tests from the location of the compiler executables to rule out as many idiosyncracies of my setup as possible.)

[ladislau szilagyi]

Hi Richard,

question: in your source file (onescomp.as) , do you have an explicit "END start" statement, as the final line? (where "start" indicates the starting line of your program)

Ladislau

[Richard Kiernan]

No, I don't have an explicit END statement assigned in this file; is it necessary/desirable?

I'll provide the source file here; this is meant to be an adaptation of the one's complement program listed in Leventhal's Z80 Assembly Language Programming, but with some extra assignments and setting the ORG to 100H in accordance with CP/M memory mapping:

E>type onescomp.as
ORG 0100H
LD HL,0200H
LD (HL),6AH
INC HL
LD (HL),0

LD HL,0200H
LD A,(HL)
CPL
INC HL
LD (HL),A
HALT

[ladislau szilagyi]

Hi Richard,

the "END start-addr" statement is useful only if you need to indicate explicitly a start address (different to 100H).

If END start-addr is present, the object file will contain a special "END" record.

The linker, as designed, behaves differently if you feed as input an object file which contains the "END" record, compared with the case when the "END" record is missing.

Example (run on Z80SIM): (comments marked with ***)

-------------------------------

J>type test.as
start:ld a,1
end start

J>z80as test

Z80AS Macro-Assembler V4.8

Errors: 0
Finished.

J>dumpobjx test.obj
TEST.OBJ
        1       IDENT
                Machine         = Z80
                32 bit order    = 0 1 2 3
                16 bit order    = 0 1
        2       TEXT
                text    0       2
                3E 01
        3       PSECT
                (abs)   GLOBAL
        4       TEXT
                        0       0
        5       PSECT
                text    GLOBAL
        6       TEXT
                text    0       0
        7       SYM
                start   text    0
        8       START
                text    0
        9       END

(*** notice the START record, just before the END record)

J>link
link> -otest.com test.obj

J>link
link> -ptext=100h -otest.com test.obj

J>link
link> -ptext=100h -c100h -otest.com test.obj

(*** link does not issue any warning...)

J> (edit test.as, remove the end statement...)
J>type test.as
start:ld a,1

J>z80as test

Z80AS Macro-Assembler V4.8

Errors: 0
Finished.

J>dumpobjx test.obj
TEST.OBJ
        1       IDENT
                Machine         = Z80
                32 bit order    = 0 1 2 3
                16 bit order    = 0 1
        2       TEXT
                text    0       2
                3E 01
        3       PSECT
                (abs)   GLOBAL
        4       TEXT
                        0       0
        5       PSECT
                text    GLOBAL
        6       TEXT
                text    0       0
        7       SYM
                start   text    0
        8       END

(*** no more START record !!!)

J>link
link> -otest.com test.obj

no start record: entry point defaults to zero (warning)

J>link
link> -ptext=100h -otest.com test.obj

no start record: entry point defaults to zero (warning)

J>link
link> -ptext=100h -c100h -otest.com test.obj

J>

(*** notice the warning messages produced by LINK, except the case when -C100h is used, with LINK "enforcing" 100H as start address)

--------------------------------

Please, try to reproduce exactly the tests, using the last version of Z80AS (4.8) ... the results should be identical.

I wait for your feedback in order to investigate further...

regards,

Ladislau

[Richard Kiernan]

OK, I don't seem to have a dumpobjx.com file, nor an equivalent to read the object file, but I've done the other tests:

B>type test.as

start:ld a,1
end start

B>z80as test

Z80AS Macro-Assembler V4.8

Errors: 0
Finished.

B>link
link> -otest.com test.obj

B>link
link> -ptext=100h -otest.com test.obj

B>link

link> -ptext=100h -c100h -otest.com test.obj

----------------------------------------
B>type test.as
start:ld a,1


B>z80as test

Z80AS Macro-Assembler V4.8

Errors: 0
Finished.

B>link
link> -otest.com test.obj

B>link
link> -ptext=100h -otest.com test.obj

B>link

link> -ptext=100h -c100h -otest.com test.obj

I'm noting here that even after the removal of the END start pseudo-operator that the assembler still doesn't seem to be complaining about a missing start record, which suggests that it is somehow slipping one in there. If you can provide a link to a dumpobjx executable, I can try running this for each of the tests and providing the output separately.

[Андрей Никитин]

The recreated program for viewing the contents of object files in Hi-Tech format is located at the link https://github.com/nikitinprior/ddump

понедельник, 27 марта 2023 г. в 16:58:27 UTC+3, Richard Kiernan:

[ladislau szilagyi]

Hi Richard,

yes, something went wrong at building the last Z80AS version...

I'm rebuilding-it from zero, I will come back soon...

Ladislau

[ladislau szilagyi]

Hi Richard,

I rebuilt Z80AS & published the executable & sources.

I'm curious if your problem is solved... anyway, thanks for pointing-out the issue!

Ladislau

[ladislau szilagyi]

Hi,

to explain why I rebuilt the last version of Z80AS from zero: I didn't liked the way Z80AS sources were assembled.

The old version of Z80AS was used to assemble the new version... somehow risky, no?

Now, I sliced down the largest source file and rolled back to use the old ZAS to assemble all... more safer procedure, I think.

Anyway, now I'm re-building all TE & HiTech C versions, using the latest Z80AS version...I already tested TE128, it works ok, so I'm continuing the build process...

Tomorrow I will re-publish all TE & HiTech C compiler versions.

Ladislau

[Richard Kiernan]

I've tried the latest version of the executable, along with compiling the DUMP.COM executable to give more visibility of what's going on, but the issue still seems to be occurring for me.

B>c:load z80as

FIRST ADDRESS 0100
LAST  ADDRESS 5F7F
BYTES READ    5E60
RECORDS WRITTEN BD

B>type test.as
start:ld a,1

B>z80as test
Z80AS Macro-Assembler V4.8

Errors: 0
Finished.

B>dump test.obj

TEST.OBJ
       1       IDENT
               Machine         = Z80
               32 bit order    = 0 1 2 3
               16 bit order    = 0 1
       2       TEXT
               text    0       2
               3E 01  
       3       PSECT
               (abs)   GLOBAL
       4       TEXT
                       0       0
       5       PSECT
               text    GLOBAL
       6       TEXT
               text    0       0
       7       SYM
               start   text    0
       8       START
               text    0
       9       END

B>link
link> -otest.com test.obj

B>

This seems to substantiate my suspicion that there's a START pseudo-op creeping in there.

[Richard Kiernan]

And to illustrate that I'm not having the same issues with v4.7:

B>z80as test.as

Z80AS Macro-Assembler V4.7

Errors: 0
Finished.

B>link

link> -otest.com test.obj
no start record: entry point defaults to zero (warning)

B>dump test.obj     
TEST.OBJ
       1       IDENT
               Machine         = Z80
               32 bit order    = 0 1 2 3
               16 bit order    = 0 1
       2       TEXT
               text    0       2
               3E 01  
       3       PSECT
               (abs)   GLOBAL
       4       TEXT
                       0       0
       5       PSECT
               text    GLOBAL
       6       TEXT
               text    0       0
       7       SYM
               start   text    0

       8       END

[ladislau szilagyi]

Hi Richard,

I repeated the test, this time I used the same Z80SIM and another, different RC2014:

(*** Z80SIM)

J>type test.as

ld a,1

J>z80as test
Z80AS Macro-Assembler V4.8

Errors: 0
Finished.

J>dumpobjx test.obj
TEST.OBJ
        1       IDENT
                Machine         = Z80
                32 bit order    = 0 1 2 3
                16 bit order    = 0 1
        2       TEXT
                text    0       2
                3E 01
        3       PSECT
                (abs)   GLOBAL
        4       TEXT
                        0       0
        5       PSECT
                text    GLOBAL
        6       TEXT
                text    0       0

        7       END

> (*** modify test.as)

J>

(*** RC2014, SC108, SIO/2)

D>type test.as
ld a,1

D>z80as test

Z80AS Macro-Assembler V4.8

Errors: 0
Finished.

D>dumpobjx test.obj

TEST.OBJ
        1       IDENT
                Machine         = Z80
                32 bit order    = 0 1 2 3
                16 bit order    = 0 1
        2       TEXT
                text    0       2
                3E 01
        3       PSECT
                (abs)   GLOBAL
        4       TEXT
                        0       0
        5       PSECT
                text    GLOBAL
        6       TEXT
                text    0       0

        7       END

D> (*** modify test.as)

D>type test.as

start:ld a,1
end start

D>z80as test

Z80AS Macro-Assembler V4.8

Errors: 0
Finished.

D>dumpobjx test.obj

TEST.OBJ
        1       IDENT
                Machine         = Z80
                32 bit order    = 0 1 2 3
                16 bit order    = 0 1
        2       TEXT
                text    0       2
                3E 01
        3       PSECT
                (abs)   GLOBAL
        4       TEXT
                        0       0
        5       PSECT
                text    GLOBAL
        6       TEXT
                text    0       0
        7       SYM
                start   text    0
        8       START
                text    0
        9       END

D>

---------------------------

Therefore, unfortunately, I failed to reproduce the issue... here, with my RC2014's , it works as designed.

More on this, I checked carefully the source code:

In z80as5.as:

ENDMARK:defb 0 ; 0 if no END start

In z80as4.as:

;
;       END
;
S320:   call    GNC             ; argument present (program start address)?
        or      a
        ld      hl,0
        ld      a,0
        jr      z,S320A         ; branch if not
        call    BACKUP
        call    EVALNEW         ; else get argument
ld a,0FFH
ld (ENDMARK),a ;mark END START
        ld      a,(EVMODE)
S320A:  ld      (ENDADR),hl
...

then in genobj.as:

;
; CLSOBJ - Write end record
; close object file.
;
CLSOBJ:
COND NOOBJ
jp CLOSE2 ; close REL file
ENDC
ld a,(JPASS)
or a
ret nz
ld a,(PBUF) ;buffer loaded?
or a
jr z,c1
call WriteBuf ;yes, then write the buffer
call DeployREL ;then write RELOC recs (if any...)
c1:
ld a,(RPBUF) ;buffer loaded?
or a
call nz,WriteRBuf ;yes, then save the buffer

ld a,(PSECT_DONE) ;PSECT records were written?
or a ;if no, write them...
call z,WritePSECTS

ld a,(ENDMARK) ;END addr was specified?
or a
jr z,wend
;then write the START record
ld hl,(ENDADR)
ld (start),hl

ld hl,START_REC
ld b,START_REC_LEN
call WriteBytes
wend: ;write END record
ld hl,END_REC ;BSS
ld b,END_REC_LEN
call WriteBytes

jp CLOSE2 ; close REL file
------------

... so, the START record is written ONLY if ENDMARK is set.

I checked, ENDMARK is referred ONLY in these places... for me, is a mystery how it's possible that the START record is written when there is no "end start" statement...

Anybody else have noticed this Z80AS anomaly?

Ladislau

[ladislau szilagyi]

Hi again Richard,

I think that for you, the best is to keep using the previous v4.7 version of Z80AS, until I will found what's the problem.

Anyway, the difference between v4.7 and v4.8 is that in the new version, up to 512 jump optimizations are allowed, compared to 128 in the old version.

I encountered only 2 (very large) C source files where this may happen, in all the usual cases, up to 128 jump optimizations is quite enough...

Meantime, let's wait, perhaps someone else will report the same issue as yours, but for a hard-soft environment I can replicate...

regards,

Ladislau

[Richard Kiernan]

That makes sense; this does seem like a very peculiar edge case and for what I'll be using this for in the short term, which is just learning Z80 assembly language and on a basic 64 KB environment, I shouldn't expect to need the extra capacity of v4.8 at present.

[ladislau szilagyi]

Hi Richard,

I neglected to ask you a very important question: how many KB of RAM do you have?

If you have only 32KB, the issue is clarified: the Z80AS v4.8 version is larger compared to the previous v4.7, and that explains all.

Ladislau

[Richard Kiernan]

I'm using a standard RC2014 Mini with the CP/M upgrade kit, so I presume 64 KB in total.

[ladislau szilagyi]

Hi Richard,

problem solved. I found that my com2hex program had a bug, so that I published again the Z80AS.HEX file , it will work now.

Take a look and tell me if the issue was solved...

regards,

Ladislau

[Richard Kiernan]

Hello Ladislau,

Just had a chance to test it there and it appears to be working with both the C and assembly test programs, so I think this is solved now.

[ladislau szilagyi]

Thanks Richard for the quick response!

I'm glad that it works now!

regards,

Ladislau

[ladislau szilagyi]

Hi all,

I published a new version, to fix some CP/M filename related bugs in the management of the Z80AS command line.

What was the problem: the syntax checking of the command line was not accurate.

Example:

D>z80as [
Z80AS Macro-Assembler V4.8
Source file not found

( this is an incorrect error message, because "[" is not a valid CP/M filename ) 

D>z80as a12345678

(here, the assembler freezes, you needed to reboot the system... and this because filenames with more than 8 chars were passing the syntax check...)

These errors are now fixed.

Ladislau