I am using Hi-Tech C 3.09.

I compile hello.c:

/* hello.c
*
*/ new comment feature of cpp

#include <stdio.h>
int main(int ac, char **av) {
printf("Hello, world!\n");
return 0;
}

compile using c -v -c hello.c, giving hello.obj

Using my objtomac utility (https://github.com/ratboy666/mtrel)

obj2mac hello.obj >hello.mac

and then

m80 =hello/l
ld80 zcrtcpm,hello,hello/n/e

giving hello.com

But...

copy hello.mac to hello.z80 and edit SET to DEFL -- gives us something like:

; GENERATED BY OBJTOMAC 0.50
CSEG
text:
DSEG
data:
CSEG
OFFSET DEFL 00000H
ORG OFFSET
DB 0CDH,000H,000H,000H,000H,021H,000H,000H ; 0000
DB 0E5H,0CDH,000H,000H,021H,002H,000H,039H ; 0008
DB 0F9H,021H,000H,000H,0C3H,017H,000H,0C3H ; 0010
DB 000H,000H ; 0018
ORG OFFSET+00001H
DW ncsv
ORG OFFSET+00006H
DW data
ORG OFFSET+0000AH
DW _printf
ORG OFFSET+00015H
DW text+00017H
ORG OFFSET+00018H
DW cret
DSEG
OFFSET DEFL 00000H
ORG OFFSET
DB 048H,065H,06CH,06CH,06FH,02CH,020H,077H ; 0000
ORG OFFSET+00006H
DW data
ORG OFFSET+0000AH
DW _printf
ORG OFFSET+00015H
DW text+00017H
ORG OFFSET+00018H
DW cret
DSEG
OFFSET DEFL 00000H
ORG OFFSET
DB 048H,065H,06CH,06CH,06FH,02CH,020H,077H ; 0000
DB 06FH,072H,06CH,064H,021H,00AH,000H ; 0008
CSEG
ORG 00000H
_main:
PUBLIC _main
EXTRN _printf
EXTRN cret
EXTRN indir
EXTRN ncsv
END

Note the use of ORG to place relocations. This assembles with

Z80ASM Copyright (C) 1983-86 by SLR Systems Rel. 1.32 #AB1234
%hello/m
hello/m
End of file Pass 1
0 Error(s) Detected.
26 Absolute Bytes. 8 Symbols Detected.

hello/m to produce a REL file. I then link it and get:

B>r ld80

Link-80 Disk Vers. 3.55 10-Sep-82 Copyright (c) 1981 Microsoft

*zcrtcpm
Data 0103 0147 < 68>

LIBC RQUEST
-STARTU 0000 -_EXIT 0000 -_MAIN 0000
-__ARGC 0000
4 Undefined Global(s)
37860 Bytes Free

*hello
%Overlaying Program area
%Overlaying Program area
%Overlaying Program area
%Overlaying Program area
%Overlaying Program area
%Overlaying Program area
? Max memory addr exceeded.
*

Cool, huh? Z80ASM is a bit... um... broken. I am using Hi-Tech C 3.09 to build the AM9511 emulation, (and test DSD-80 function). I decided that a lot of people seem to REALLY like SLR and do not like Microsoft M80, and I should give Z80ASM a chance... And... bug #1. It does not appear to handle the
relocation overlap technique I use to translate Hi-Tech OBJ to MAC format.

As a PS. M80 *does* use DEFL or SET interchangeably. Using PSA PLINK-II
we get a different result:
B>r plink-ii

PSA Linkage Editor II (CP/M) [P20100-0114 ]
Copyright (C) 1981 by Phoenix Software Associates Ltd.

*out hello.com
*fi zcrtcpm,hello
*;
The following symbols were referenced, but not defined anywhere:
_CLOSE _PRINTF __CLEA
Pass 1 Error 60
*

Here is M80 and PLINK-II:

B>r m80 =hello/l
?File not found
*=hello.z80/l

No Fatal error(s)

*

*^C
B>r plink-ii

PSA Linkage Editor II (CP/M) [P20100-0114 ]
Copyright (C) 1981 by Phoenix Software Associates Ltd.

*out hello.com
*fi zcrtcpm,hello
*;
HELLO.COM (136AH, 5K)
*^C
B>hello
Hello, world!

I *WAS* thinking about SLR support -- but it is just too strange. The object
files produced do strange case-sensitive things with library, it does *NOT*
support SET (just DEFL). And it seems to generate REL files that the
standard Microsoft tools do not like.

The benefit would be 7 character external support. Possibly speed.

Anyone else can weigh in on SLR Z80ASM vs Microsoft M80? For building AM9511 native, I think I will use Hi-Tech ZAS, and LINK, *or* M80 and L80
(LD80) or PLINK. At least those choices work without issue.

As I recall "in the day" I used M80 exclusively, but I forgotten WHY. It becomes clear again.

Thanks
FredW

On Tuesday, June 8, 2021 at 4:49:11 AM UTC+10, FredW wrote:
> I am using Hi-Tech C 3.09.
[snip]
> Anyone else can weigh in on SLR Z80ASM vs Microsoft M80? For building AM9511 native, I think I will use Hi-Tech ZAS, and LINK, *or* M80 and L80
> (LD80) or PLINK. At least those choices work without issue.
>
> As I recall "in the day" I used M80 exclusively, but I forgotten WHY. It becomes clear again.

I have used a mix of assemblers.. starting with the TDL/PASM (8080-style
with Z80 extensions) and PLINK then PLINK-II; and then for a long time the
Microsoft M80 macro assembler (because I like the Zilog mnemonics).
The SLR Z80ASM assember is fast but has some "quirks" as you have
found.

In the last few years with my tinkering in the Z280 world, I've migrated to
mostly using Hector Peraza's ZSM4 macro assembler. It has a /Sn switch
that can select symbol lengths between 6 and 8 characters, and produces
object files in the standard Digital Research LINK format (also compatible
with Microsoft L80 and PLINK linkers - but it doesn't use the M80 V3.44
or SLR linker REL format extensions). It can also assemble Z80/Z180
and Z280 opcodes (all Zilog mnemonics) and uses a range of
M80-compatible pseudo-ops (like DW/DEFW, DS/DEFS etc).

Hector provides the assembler source-code and binaries for CP/M (and
his RSX180/RSX280 operating systems) with full documentation at

https://github.com/hperaza/ZSM4

ZSM4 runs fine under the John Elliott's zxcc CP/M emulator on Linux/
macOS too (from https://www.seasip.info/Unix/Zxcc/ ).

HI-TECH's ZAS has some quirks too (strict source-code formatting) and
has an added advantage of being able to optimise absolute jumps (JP)
into relative ones (JR) - albeit with a strange label convention for forward
references. The object file format is different too (see Andrey Nikitin's
recent reconstruction of the HI-TECH's object file DUMP utility for an
explanation of the object-file format (https://github.com/nikitinprior/ddump ).

Tony

On 8/06/2021 04:49, fred_...@hotmail.com wrote:
>
> Anyone else can weigh in on SLR Z80ASM vs Microsoft M80?

M80 was the de-facto standard assembler for Z80 CP/M. SLR was
backward compatible with M80. If the aim is to write M80-compatible
code using SLR, you'll likely need to check it against M80.

On Monday, June 7, 2021 at 10:06:42 PM UTC-4, Tony Nicholson wrote:
> On Tuesday, June 8, 2021 at 4:49:11 AM UTC+10, FredW wrote:
> > I am using Hi-Tech C 3.09.
> [snip]
> > Anyone else can weigh in on SLR Z80ASM vs Microsoft M80? For building AM9511 native, I think I will use Hi-Tech ZAS, and LINK, *or* M80 and L80
> > (LD80) or PLINK. At least those choices work without issue.
> >
> > As I recall "in the day" I used M80 exclusively, but I forgotten WHY. It becomes clear again.
> I have used a mix of assemblers.. starting with the TDL/PASM (8080-style
> with Z80 extensions) and PLINK then PLINK-II; and then for a long time the
> Microsoft M80 macro assembler (because I like the Zilog mnemonics).
> The SLR Z80ASM assember is fast but has some "quirks" as you have
> found.
>
> In the last few years with my tinkering in the Z280 world, I've migrated to
> mostly using Hector Peraza's ZSM4 macro assembler. It has a /Sn switch
> that can select symbol lengths between 6 and 8 characters, and produces
> object files in the standard Digital Research LINK format (also compatible
> with Microsoft L80 and PLINK linkers - but it doesn't use the M80 V3.44
> or SLR linker REL format extensions). It can also assemble Z80/Z180
> and Z280 opcodes (all Zilog mnemonics) and uses a range of
> M80-compatible pseudo-ops (like DW/DEFW, DS/DEFS etc).
>
> Hector provides the assembler source-code and binaries for CP/M (and
> his RSX180/RSX280 operating systems) with full documentation at
>
> https://github.com/hperaza/ZSM4
>
> ZSM4 runs fine under the John Elliott's zxcc CP/M emulator on Linux/
> macOS too (from https://www.seasip.info/Unix/Zxcc/ ).
>
> HI-TECH's ZAS has some quirks too (strict source-code formatting) and
> has an added advantage of being able to optimise absolute jumps (JP)
> into relative ones (JR) - albeit with a strange label convention for forward
> references. The object file format is different too (see Andrey Nikitin's
> recent reconstruction of the HI-TECH's object file DUMP utility for an
> explanation of the object-file format (https://github.com/nikitinprior/ddump ).
>
> Tony
Tony

I reversed Hi-Tech OBJ format - see my OBJTOMAC utility that converts
OBJ from Hi-Tech to MAC that can be assembled by M80. If you get MTREL,
you also get the Hi-Tech LIBC and LIBM in REL format.

FredW

вторник, 8 июня 2021 г. в 06:10:57 UTC+3, fred_...@hotmail.com:
> On Monday, June 7, 2021 at 10:06:42 PM UTC-4, Tony Nicholson wrote:
> > On Tuesday, June 8, 2021 at 4:49:11 AM UTC+10, FredW wrote:
> > > I am using Hi-Tech C 3.09.
> > [snip]
> > > Anyone else can weigh in on SLR Z80ASM vs Microsoft M80? For building AM9511 native, I think I will use Hi-Tech ZAS, and LINK, *or* M80 and L80
> > > (LD80) or PLINK. At least those choices work without issue.
> > >
> > > As I recall "in the day" I used M80 exclusively, but I forgotten WHY. It becomes clear again.
> > I have used a mix of assemblers.. starting with the TDL/PASM (8080-style
> > with Z80 extensions) and PLINK then PLINK-II; and then for a long time the
> > Microsoft M80 macro assembler (because I like the Zilog mnemonics).
> > The SLR Z80ASM assember is fast but has some "quirks" as you have
> > found.
> >
> > In the last few years with my tinkering in the Z280 world, I've migrated to
> > mostly using Hector Peraza's ZSM4 macro assembler. It has a /Sn switch
> > that can select symbol lengths between 6 and 8 characters, and produces
> > object files in the standard Digital Research LINK format (also compatible
> > with Microsoft L80 and PLINK linkers - but it doesn't use the M80 V3.44
> > or SLR linker REL format extensions). It can also assemble Z80/Z180
> > and Z280 opcodes (all Zilog mnemonics) and uses a range of
> > M80-compatible pseudo-ops (like DW/DEFW, DS/DEFS etc).
> >
> > Hector provides the assembler source-code and binaries for CP/M (and
> > his RSX180/RSX280 operating systems) with full documentation at
> >
> > https://github.com/hperaza/ZSM4
> >
> > ZSM4 runs fine under the John Elliott's zxcc CP/M emulator on Linux/
> > macOS too (from https://www.seasip.info/Unix/Zxcc/ ).
> >
> > HI-TECH's ZAS has some quirks too (strict source-code formatting) and
> > has an added advantage of being able to optimise absolute jumps (JP)
> > into relative ones (JR) - albeit with a strange label convention for forward
> > references. The object file format is different too (see Andrey Nikitin's
> > recent reconstruction of the HI-TECH's object file DUMP utility for an
> > explanation of the object-file format (https://github.com/nikitinprior/ddump ).
> >
> > Tony
> Tony
>
> I reversed Hi-Tech OBJ format - see my OBJTOMAC utility that converts
> OBJ from Hi-Tech to MAC that can be assembled by M80. If you get MTREL,
> you also get the Hi-Tech LIBC and LIBM in REL format.
>
> FredW

The Microsoft M80 and Z80ASM SLR Systems macro assemblers and some others were developed to compile source files in assembly language. The Microsoft fortran, basic, and cobol compilers compiled high-level language source files directly into a rel object file. The Microsoft fortran compiler allowed you to get a listing of a compiled file with processor opcodes, but the use of files with assembly code obtained by compiling code from a high-level language was not originally intended. Moreover, the length of variable names (identifiers) in these languages did not exceed 6 characters, which affected their length in rel object files.
The C standard allowed longer variable and function names. For this reason, the rel format did not meet this requirement.
When creating the Hi-Tech C compiler, they developed their own object file format, taking into account the increased length of names and support for processors other than Z80. Microsoft M80 and SLR Systems Z80ASM did not even think about this.
The software package of the then commercial Hi-Tech C compiler is consistent with each other and does not require third-party software and, accordingly, additional costs. When translating libraries to the rel format, you were forced to change (reduce) the names of part of the standard functions. The use of third-party assemblers restricts the C language and turns a good compiler into something non-standard. It seems to me that it is more productive to use the capabilities of Hi-Tech assembler in your development. And if they are not enough, write your own preprocessor to translate the M80 or Z80ASM syntax into a form that the Hi-Tech ZAS assembler understands.

Andrey Nikitin

On Tuesday, June 8, 2021 at 8:23:23 AM UTC-4, nikiti...@gmail.com wrote:
> вторник, 8 июня 2021 г. в 06:10:57 UTC+3, fred_...@hotmail.com:
> > On Monday, June 7, 2021 at 10:06:42 PM UTC-4, Tony Nicholson wrote:
> > > On Tuesday, June 8, 2021 at 4:49:11 AM UTC+10, FredW wrote:
> > > > I am using Hi-Tech C 3.09.
> > > [snip]
> > > > Anyone else can weigh in on SLR Z80ASM vs Microsoft M80? For building AM9511 native, I think I will use Hi-Tech ZAS, and LINK, *or* M80 and L80
> > > > (LD80) or PLINK. At least those choices work without issue.
> > > >
> > > > As I recall "in the day" I used M80 exclusively, but I forgotten WHY. It becomes clear again.
> > > I have used a mix of assemblers.. starting with the TDL/PASM (8080-style
> > > with Z80 extensions) and PLINK then PLINK-II; and then for a long time the
> > > Microsoft M80 macro assembler (because I like the Zilog mnemonics).
> > > The SLR Z80ASM assember is fast but has some "quirks" as you have
> > > found.
> > >
> > > In the last few years with my tinkering in the Z280 world, I've migrated to
> > > mostly using Hector Peraza's ZSM4 macro assembler. It has a /Sn switch
> > > that can select symbol lengths between 6 and 8 characters, and produces
> > > object files in the standard Digital Research LINK format (also compatible
> > > with Microsoft L80 and PLINK linkers - but it doesn't use the M80 V3.44
> > > or SLR linker REL format extensions). It can also assemble Z80/Z180
> > > and Z280 opcodes (all Zilog mnemonics) and uses a range of
> > > M80-compatible pseudo-ops (like DW/DEFW, DS/DEFS etc).
> > >
> > > Hector provides the assembler source-code and binaries for CP/M (and
> > > his RSX180/RSX280 operating systems) with full documentation at
> > >
> > > https://github.com/hperaza/ZSM4
> > >
> > > ZSM4 runs fine under the John Elliott's zxcc CP/M emulator on Linux/
> > > macOS too (from https://www.seasip.info/Unix/Zxcc/ ).
> > >
> > > HI-TECH's ZAS has some quirks too (strict source-code formatting) and
> > > has an added advantage of being able to optimise absolute jumps (JP)
> > > into relative ones (JR) - albeit with a strange label convention for forward
> > > references. The object file format is different too (see Andrey Nikitin's
> > > recent reconstruction of the HI-TECH's object file DUMP utility for an
> > > explanation of the object-file format (https://github.com/nikitinprior/ddump ).
> > >
> > > Tony
> > Tony
> >
> > I reversed Hi-Tech OBJ format - see my OBJTOMAC utility that converts
> > OBJ from Hi-Tech to MAC that can be assembled by M80. If you get MTREL,
> > you also get the Hi-Tech LIBC and LIBM in REL format.
> >
> > FredW
> The Microsoft M80 and Z80ASM SLR Systems macro assemblers and some others were developed to compile source files in assembly language. The Microsoft fortran, basic, and cobol compilers compiled high-level language source files directly into a rel object file. The Microsoft fortran compiler allowed you to get a listing of a compiled file with processor opcodes, but the use of files with assembly code obtained by compiling code from a high-level language was not originally intended. Moreover, the length of variable names (identifiers) in these languages did not exceed 6 characters, which affected their length in rel object files.
> The C standard allowed longer variable and function names. For this reason, the rel format did not meet this requirement.
> When creating the Hi-Tech C compiler, they developed their own object file format, taking into account the increased length of names and support for processors other than Z80. Microsoft M80 and SLR Systems Z80ASM did not even think about this.
> The software package of the then commercial Hi-Tech C compiler is consistent with each other and does not require third-party software and, accordingly, additional costs. When translating libraries to the rel format, you were forced to change (reduce) the names of part of the standard functions. The use of third-party assemblers restricts the C language and turns a good compiler into something non-standard. It seems to me that it is more productive to use the capabilities of Hi-Tech assembler in your development. And if they are not enough, write your own preprocessor to translate the M80 or Z80ASM syntax into a form that the Hi-Tech ZAS assembler understands.
>
> Andrey Nikitin

Andrey

Back "in the day" I used Whitesmiths 8080 C - and cross compiler (Whitesmiths on a VAX target was Z80). Whitesmiths used something called
"A-natural" for the assembler.. completely non-standard. So, M80 it was.

Some people distributed object code in REL format -- Micropro had SuperSort, for example, and Micro B+ from Faircom are examples. In my opinion,
it is important to have a common object format. And, from 1977 to 1982, that was REL. Both Microsoft and Digital Research used it... And that gave us
PLINK-II, SuperSort and Micro B+ Of course, there were others... but, as nice as they are --- I am writing a core AM9511 emulator. It will
(eventually) go into 8080/Z80 emulators (that is the end-goal). But... it needs to be checked against the actual hardware. So, I want to link the
emulator, written in C, into (for example) FORTRAN-80. Or MBASIC, BASCOM, or have "plain" C wrappers.

I *could* use Whitesmiths C 2.0 (I used Whitesmiths native 8080 and cross on VAX in the day - 1981 through 1983 or so), because I know that PLINK-II can link that, along with Microsoft REL. But, I wanted to use a slightly more modern variant of C -- Hi-Tech fits the bill. And, with OBJTOMAC I can coerce REL files out of it (and, yes, I have converted the ENTIRE LIBC and LIBM libraries into REL format already). So, I can have my cake, and eat it too. And, as a freebie, if I link with PLINK-II, I get overlays.

If you recall I translated Hi-Tech ZAS to M80 -- AS2MAC is the program. That was used to convert the run-time library. But, there are...
issues. It is possible to compile C to assembler with Hi-Tech C, and have ZAS *NOT ABLE TO ASSEMBLE THE AS FILE*. And, AS2MAC will
then not be able to convert it, either. Sometimes, specifying optimization helps. As does reducing the source size.This did not show up
while I was converting the run-time library. OBJTOMAC exists to remedy those and does so very well. It just works. (and, when I get around to
it -- post AM9511 code and a couple of other projects, I am going to generate OBJTOREL -- and, once I understand REL -- having never generated a REL file, RELTOOBJ would seem reasonable -- but all that is FAR FUTURE retro work).

AS2MAC.COM, OBJTOMAC.COM, LIBC.REL and LIBM.REL are all available (with all source) in https://github.com/ratboy666/mtrel

The thing was -- I took a MAC file produced by my OBJTOMAC tool and assembled it with SLR Systems Z80ASM. The *assembly* went just fine, but the
relocatable result was NOT LINKABLE. That indicates some issues with SLR Z80ASM. If I ran into these sorts of issues back in the day,
I would simply have rejected the tool and gone back to M80.

FredW

вторник, 8 июня 2021 г. в 16:49:32 UTC+3, fred_...@hotmail.com:
> On Tuesday, June 8, 2021 at 8:23:23 AM UTC-4, nikiti...@gmail.com wrote:
> > вторник, 8 июня 2021 г. в 06:10:57 UTC+3, fred_...@hotmail.com:
> > > On Monday, June 7, 2021 at 10:06:42 PM UTC-4, Tony Nicholson wrote:
> > > > On Tuesday, June 8, 2021 at 4:49:11 AM UTC+10, FredW wrote:
> > > > > I am using Hi-Tech C 3.09.
> > > > [snip]
> > > > > Anyone else can weigh in on SLR Z80ASM vs Microsoft M80? For building AM9511 native, I think I will use Hi-Tech ZAS, and LINK, *or* M80 and L80
> > > > > (LD80) or PLINK. At least those choices work without issue.
> > > > >
> > > > > As I recall "in the day" I used M80 exclusively, but I forgotten WHY. It becomes clear again.
> > > > I have used a mix of assemblers.. starting with the TDL/PASM (8080-style
> > > > with Z80 extensions) and PLINK then PLINK-II; and then for a long time the
> > > > Microsoft M80 macro assembler (because I like the Zilog mnemonics).
> > > > The SLR Z80ASM assember is fast but has some "quirks" as you have
> > > > found.
> > > >
> > > > In the last few years with my tinkering in the Z280 world, I've migrated to
> > > > mostly using Hector Peraza's ZSM4 macro assembler. It has a /Sn switch
> > > > that can select symbol lengths between 6 and 8 characters, and produces
> > > > object files in the standard Digital Research LINK format (also compatible
> > > > with Microsoft L80 and PLINK linkers - but it doesn't use the M80 V3.44
> > > > or SLR linker REL format extensions). It can also assemble Z80/Z180
> > > > and Z280 opcodes (all Zilog mnemonics) and uses a range of
> > > > M80-compatible pseudo-ops (like DW/DEFW, DS/DEFS etc).
> > > >
> > > > Hector provides the assembler source-code and binaries for CP/M (and
> > > > his RSX180/RSX280 operating systems) with full documentation at
> > > >
> > > > https://github.com/hperaza/ZSM4
> > > >
> > > > ZSM4 runs fine under the John Elliott's zxcc CP/M emulator on Linux/
> > > > macOS too (from https://www.seasip.info/Unix/Zxcc/ ).
> > > >
> > > > HI-TECH's ZAS has some quirks too (strict source-code formatting) and
> > > > has an added advantage of being able to optimise absolute jumps (JP)
> > > > into relative ones (JR) - albeit with a strange label convention for forward
> > > > references. The object file format is different too (see Andrey Nikitin's
> > > > recent reconstruction of the HI-TECH's object file DUMP utility for an
> > > > explanation of the object-file format (https://github.com/nikitinprior/ddump ).
> > > >
> > > > Tony
> > > Tony
> > >
> > > I reversed Hi-Tech OBJ format - see my OBJTOMAC utility that converts
> > > OBJ from Hi-Tech to MAC that can be assembled by M80. If you get MTREL,
> > > you also get the Hi-Tech LIBC and LIBM in REL format.
> > >
> > > FredW
> > The Microsoft M80 and Z80ASM SLR Systems macro assemblers and some others were developed to compile source files in assembly language. The Microsoft fortran, basic, and cobol compilers compiled high-level language source files directly into a rel object file. The Microsoft fortran compiler allowed you to get a listing of a compiled file with processor opcodes, but the use of files with assembly code obtained by compiling code from a high-level language was not originally intended. Moreover, the length of variable names (identifiers) in these languages did not exceed 6 characters, which affected their length in rel object files.
> > The C standard allowed longer variable and function names. For this reason, the rel format did not meet this requirement.
> > When creating the Hi-Tech C compiler, they developed their own object file format, taking into account the increased length of names and support for processors other than Z80. Microsoft M80 and SLR Systems Z80ASM did not even think about this.
> > The software package of the then commercial Hi-Tech C compiler is consistent with each other and does not require third-party software and, accordingly, additional costs. When translating libraries to the rel format, you were forced to change (reduce) the names of part of the standard functions. The use of third-party assemblers restricts the C language and turns a good compiler into something non-standard. It seems to me that it is more productive to use the capabilities of Hi-Tech assembler in your development. And if they are not enough, write your own preprocessor to translate the M80 or Z80ASM syntax into a form that the Hi-Tech ZAS assembler understands.
> >
> > Andrey Nikitin
> Andrey
>
> Back "in the day" I used Whitesmiths 8080 C - and cross compiler (Whitesmiths on a VAX target was Z80). Whitesmiths used something called
> "A-natural" for the assembler.. completely non-standard. So, M80 it was.
>
> Some people distributed object code in REL format -- Micropro had SuperSort, for example, and Micro B+ from Faircom are examples. In my opinion,
> it is important to have a common object format. And, from 1977 to 1982, that was REL. Both Microsoft and Digital Research used it... And that gave us
> PLINK-II, SuperSort and Micro B+ Of course, there were others... but, as nice as they are --- I am writing a core AM9511 emulator. It will
> (eventually) go into 8080/Z80 emulators (that is the end-goal). But... it needs to be checked against the actual hardware. So, I want to link the
> emulator, written in C, into (for example) FORTRAN-80. Or MBASIC, BASCOM, or have "plain" C wrappers.
>
> I *could* use Whitesmiths C 2.0 (I used Whitesmiths native 8080 and cross on VAX in the day - 1981 through 1983 or so), because I know that PLINK-II can link that, along with Microsoft REL. But, I wanted to use a slightly more modern variant of C -- Hi-Tech fits the bill. And, with OBJTOMAC I can coerce REL files out of it (and, yes, I have converted the ENTIRE LIBC and LIBM libraries into REL format already). So, I can have my cake, and eat it too. And, as a freebie, if I link with PLINK-II, I get overlays.
>
> If you recall I translated Hi-Tech ZAS to M80 -- AS2MAC is the program. That was used to convert the run-time library. But, there are...
> issues. It is possible to compile C to assembler with Hi-Tech C, and have ZAS *NOT ABLE TO ASSEMBLE THE AS FILE*. And, AS2MAC will
> then not be able to convert it, either. Sometimes, specifying optimization helps. As does reducing the source size.This did not show up
> while I was converting the run-time library. OBJTOMAC exists to remedy those and does so very well. It just works. (and, when I get around to
> it -- post AM9511 code and a couple of other projects, I am going to generate OBJTOREL -- and, once I understand REL -- having never generated a REL file, RELTOOBJ would seem reasonable -- but all that is FAR FUTURE retro work).
>
> AS2MAC.COM, OBJTOMAC.COM, LIBC.REL and LIBM.REL are all available (with all source) in https://github.com/ratboy666/mtrel
>
> The thing was -- I took a MAC file produced by my OBJTOMAC tool and assembled it with SLR Systems Z80ASM. The *assembly* went just fine, but the
> relocatable result was NOT LINKABLE. That indicates some issues with SLR Z80ASM. If I ran into these sorts of issues back in the day,
> I would simply have rejected the tool and gone back to M80.
>
> FredW

In those ancient times, the format of floating-point numbers was not yet standardized. Microsoft has used its version in all of its products. The AM9511 was one of the first coprocessors to speed up the computation of real numbers. He had his own idea of how they should be arranged. Other developers have used their own formats and libraries for this purpose. However, the speed of development of computer technology and the increase in the bit depth of the processor data bus led to the standardization of the representation of floating numbers, and as a result, Intel became the winner in this competition, which immediately released the 8087.

Perhaps the AM9511 emulation is needed to run programs written with this coprocessor in mind. Although there are very few such programs, but they are there. CP/M emulators emulate Z80 codes and operating system calls. Your emulation will allow you to extend the capabilities of the latter by executing binary code using this coprocessor. Emulation of AM9511 commands in a CP/M system that does not have this coprocessor is most likely not advisable due to the overhead of emulation, which will reduce the already small memory for the program. In this regard, it is also impractical to use any C compiler for CP/M to emulate AM9511 inside this system.

For a while, IBM PC compatible computers were available with or without a coprocessor. Compilers of that time could generate code both for the coprocessor and without it. However, they had significantly more memory, and when composing an executable program, they could use different libraries with code for the coprocessor or emulating it.

On Tuesday, June 8, 2021 at 11:26:56 AM UTC-4, nikiti...@gmail.com wrote:
> вторник, 8 июня 2021 г. в 16:49:32 UTC+3, fred_...@hotmail.com:
> > On Tuesday, June 8, 2021 at 8:23:23 AM UTC-4, nikiti...@gmail.com wrote:
> > > вторник, 8 июня 2021 г. в 06:10:57 UTC+3, fred_...@hotmail.com:
> > > > On Monday, June 7, 2021 at 10:06:42 PM UTC-4, Tony Nicholson wrote:
> > > > > On Tuesday, June 8, 2021 at 4:49:11 AM UTC+10, FredW wrote:
> > > > > > I am using Hi-Tech C 3.09.
> > > > > [snip]
> > > > > > Anyone else can weigh in on SLR Z80ASM vs Microsoft M80? For building AM9511 native, I think I will use Hi-Tech ZAS, and LINK, *or* M80 and L80
> > > > > > (LD80) or PLINK. At least those choices work without issue.
> > > > > >
> > > > > > As I recall "in the day" I used M80 exclusively, but I forgotten WHY. It becomes clear again.
> > > > > I have used a mix of assemblers.. starting with the TDL/PASM (8080-style
> > > > > with Z80 extensions) and PLINK then PLINK-II; and then for a long time the
> > > > > Microsoft M80 macro assembler (because I like the Zilog mnemonics).
> > > > > The SLR Z80ASM assember is fast but has some "quirks" as you have
> > > > > found.
> > > > >
> > > > > In the last few years with my tinkering in the Z280 world, I've migrated to
> > > > > mostly using Hector Peraza's ZSM4 macro assembler. It has a /Sn switch
> > > > > that can select symbol lengths between 6 and 8 characters, and produces
> > > > > object files in the standard Digital Research LINK format (also compatible
> > > > > with Microsoft L80 and PLINK linkers - but it doesn't use the M80 V3.44
> > > > > or SLR linker REL format extensions). It can also assemble Z80/Z180
> > > > > and Z280 opcodes (all Zilog mnemonics) and uses a range of
> > > > > M80-compatible pseudo-ops (like DW/DEFW, DS/DEFS etc).
> > > > >
> > > > > Hector provides the assembler source-code and binaries for CP/M (and
> > > > > his RSX180/RSX280 operating systems) with full documentation at
> > > > >
> > > > > https://github.com/hperaza/ZSM4
> > > > >
> > > > > ZSM4 runs fine under the John Elliott's zxcc CP/M emulator on Linux/
> > > > > macOS too (from https://www.seasip.info/Unix/Zxcc/ ).
> > > > >
> > > > > HI-TECH's ZAS has some quirks too (strict source-code formatting) and
> > > > > has an added advantage of being able to optimise absolute jumps (JP)
> > > > > into relative ones (JR) - albeit with a strange label convention for forward
> > > > > references. The object file format is different too (see Andrey Nikitin's
> > > > > recent reconstruction of the HI-TECH's object file DUMP utility for an
> > > > > explanation of the object-file format (https://github.com/nikitinprior/ddump ).
> > > > >
> > > > > Tony
> > > > Tony
> > > >
> > > > I reversed Hi-Tech OBJ format - see my OBJTOMAC utility that converts
> > > > OBJ from Hi-Tech to MAC that can be assembled by M80. If you get MTREL,
> > > > you also get the Hi-Tech LIBC and LIBM in REL format.
> > > >
> > > > FredW
> > > The Microsoft M80 and Z80ASM SLR Systems macro assemblers and some others were developed to compile source files in assembly language. The Microsoft fortran, basic, and cobol compilers compiled high-level language source files directly into a rel object file. The Microsoft fortran compiler allowed you to get a listing of a compiled file with processor opcodes, but the use of files with assembly code obtained by compiling code from a high-level language was not originally intended. Moreover, the length of variable names (identifiers) in these languages did not exceed 6 characters, which affected their length in rel object files.
> > > The C standard allowed longer variable and function names. For this reason, the rel format did not meet this requirement.
> > > When creating the Hi-Tech C compiler, they developed their own object file format, taking into account the increased length of names and support for processors other than Z80. Microsoft M80 and SLR Systems Z80ASM did not even think about this.
> > > The software package of the then commercial Hi-Tech C compiler is consistent with each other and does not require third-party software and, accordingly, additional costs. When translating libraries to the rel format, you were forced to change (reduce) the names of part of the standard functions. The use of third-party assemblers restricts the C language and turns a good compiler into something non-standard. It seems to me that it is more productive to use the capabilities of Hi-Tech assembler in your development. And if they are not enough, write your own preprocessor to translate the M80 or Z80ASM syntax into a form that the Hi-Tech ZAS assembler understands.
> > >
> > > Andrey Nikitin
> > Andrey
> >
> > Back "in the day" I used Whitesmiths 8080 C - and cross compiler (Whitesmiths on a VAX target was Z80). Whitesmiths used something called
> > "A-natural" for the assembler.. completely non-standard. So, M80 it was..
> >
> > Some people distributed object code in REL format -- Micropro had SuperSort, for example, and Micro B+ from Faircom are examples. In my opinion,
> > it is important to have a common object format. And, from 1977 to 1982, that was REL. Both Microsoft and Digital Research used it... And that gave us
> > PLINK-II, SuperSort and Micro B+ Of course, there were others... but, as nice as they are --- I am writing a core AM9511 emulator. It will
> > (eventually) go into 8080/Z80 emulators (that is the end-goal). But... it needs to be checked against the actual hardware. So, I want to link the
> > emulator, written in C, into (for example) FORTRAN-80. Or MBASIC, BASCOM, or have "plain" C wrappers.
> >
> > I *could* use Whitesmiths C 2.0 (I used Whitesmiths native 8080 and cross on VAX in the day - 1981 through 1983 or so), because I know that PLINK-II can link that, along with Microsoft REL. But, I wanted to use a slightly more modern variant of C -- Hi-Tech fits the bill. And, with OBJTOMAC I can coerce REL files out of it (and, yes, I have converted the ENTIRE LIBC and LIBM libraries into REL format already). So, I can have my cake, and eat it too. And, as a freebie, if I link with PLINK-II, I get overlays.
> >
> > If you recall I translated Hi-Tech ZAS to M80 -- AS2MAC is the program. That was used to convert the run-time library. But, there are...
> > issues. It is possible to compile C to assembler with Hi-Tech C, and have ZAS *NOT ABLE TO ASSEMBLE THE AS FILE*. And, AS2MAC will
> > then not be able to convert it, either. Sometimes, specifying optimization helps. As does reducing the source size.This did not show up
> > while I was converting the run-time library. OBJTOMAC exists to remedy those and does so very well. It just works. (and, when I get around to
> > it -- post AM9511 code and a couple of other projects, I am going to generate OBJTOREL -- and, once I understand REL -- having never generated a REL file, RELTOOBJ would seem reasonable -- but all that is FAR FUTURE retro work).
> >
> > AS2MAC.COM, OBJTOMAC.COM, LIBC.REL and LIBM.REL are all available (with all source) in https://github.com/ratboy666/mtrel
> >
> > The thing was -- I took a MAC file produced by my OBJTOMAC tool and assembled it with SLR Systems Z80ASM. The *assembly* went just fine, but the
> > relocatable result was NOT LINKABLE. That indicates some issues with SLR Z80ASM. If I ran into these sorts of issues back in the day,
> > I would simply have rejected the tool and gone back to M80.
> >
> > FredW
> In those ancient times, the format of floating-point numbers was not yet standardized. Microsoft has used its version in all of its products. The AM9511 was one of the first coprocessors to speed up the computation of real numbers. He had his own idea of how they should be arranged. Other developers have used their own formats and libraries for this purpose. However, the speed of development of computer technology and the increase in the bit depth of the processor data bus led to the standardization of the representation of floating numbers, and as a result, Intel became the winner in this competition, which immediately released the 8087.
>
> Perhaps the AM9511 emulation is needed to run programs written with this coprocessor in mind. Although there are very few such programs, but they are there. CP/M emulators emulate Z80 codes and operating system calls. Your emulation will allow you to extend the capabilities of the latter by executing binary code using this coprocessor. Emulation of AM9511 commands in a CP/M system that does not have this coprocessor is most likely not advisable due to the overhead of emulation, which will reduce the already small memory for the program. In this regard, it is also impractical to use any C compiler for CP/M to emulate AM9511 inside this system.
>
> For a while, IBM PC compatible computers were available with or without a coprocessor. Compilers of that time could generate code both for the coprocessor and without it. However, they had significantly more memory, and when composing an executable program, they could use different libraries with code for the coprocessor or emulating it.
>
> Andrey Nikitin

вторник, 8 июня 2021 г. в 20:20:46 UTC+3, fred_...@hotmail.com:
> On Tuesday, June 8, 2021 at 11:26:56 AM UTC-4, nikiti...@gmail.com wrote:
> > вторник, 8 июня 2021 г. в 16:49:32 UTC+3, fred_...@hotmail.com:
> > > On Tuesday, June 8, 2021 at 8:23:23 AM UTC-4, nikiti...@gmail.com wrote:
> > > > вторник, 8 июня 2021 г. в 06:10:57 UTC+3, fred_...@hotmail.com:
> > > > > On Monday, June 7, 2021 at 10:06:42 PM UTC-4, Tony Nicholson wrote:
> > > > > > On Tuesday, June 8, 2021 at 4:49:11 AM UTC+10, FredW wrote:
> > > > > > > I am using Hi-Tech C 3.09.
> > > > > > [snip]
> > > > > > > Anyone else can weigh in on SLR Z80ASM vs Microsoft M80? For building AM9511 native, I think I will use Hi-Tech ZAS, and LINK, *or* M80 and L80
> > > > > > > (LD80) or PLINK. At least those choices work without issue.
> > > > > > >
> > > > > > > As I recall "in the day" I used M80 exclusively, but I forgotten WHY. It becomes clear again.
> > > > > > I have used a mix of assemblers.. starting with the TDL/PASM (8080-style
> > > > > > with Z80 extensions) and PLINK then PLINK-II; and then for a long time the
> > > > > > Microsoft M80 macro assembler (because I like the Zilog mnemonics).
> > > > > > The SLR Z80ASM assember is fast but has some "quirks" as you have
> > > > > > found.
> > > > > >
> > > > > > In the last few years with my tinkering in the Z280 world, I've migrated to
> > > > > > mostly using Hector Peraza's ZSM4 macro assembler. It has a /Sn switch
> > > > > > that can select symbol lengths between 6 and 8 characters, and produces
> > > > > > object files in the standard Digital Research LINK format (also compatible
> > > > > > with Microsoft L80 and PLINK linkers - but it doesn't use the M80 V3.44
> > > > > > or SLR linker REL format extensions). It can also assemble Z80/Z180
> > > > > > and Z280 opcodes (all Zilog mnemonics) and uses a range of
> > > > > > M80-compatible pseudo-ops (like DW/DEFW, DS/DEFS etc).
> > > > > >
> > > > > > Hector provides the assembler source-code and binaries for CP/M (and
> > > > > > his RSX180/RSX280 operating systems) with full documentation at
> > > > > >
> > > > > > https://github.com/hperaza/ZSM4
> > > > > >
> > > > > > ZSM4 runs fine under the John Elliott's zxcc CP/M emulator on Linux/
> > > > > > macOS too (from https://www.seasip.info/Unix/Zxcc/ ).
> > > > > >
> > > > > > HI-TECH's ZAS has some quirks too (strict source-code formatting) and
> > > > > > has an added advantage of being able to optimise absolute jumps (JP)
> > > > > > into relative ones (JR) - albeit with a strange label convention for forward
> > > > > > references. The object file format is different too (see Andrey Nikitin's
> > > > > > recent reconstruction of the HI-TECH's object file DUMP utility for an
> > > > > > explanation of the object-file format (https://github.com/nikitinprior/ddump ).
> > > > > >
> > > > > > Tony
> > > > > Tony
> > > > >
> > > > > I reversed Hi-Tech OBJ format - see my OBJTOMAC utility that converts
> > > > > OBJ from Hi-Tech to MAC that can be assembled by M80. If you get MTREL,
> > > > > you also get the Hi-Tech LIBC and LIBM in REL format.
> > > > >
> > > > > FredW
> > > > The Microsoft M80 and Z80ASM SLR Systems macro assemblers and some others were developed to compile source files in assembly language. The Microsoft fortran, basic, and cobol compilers compiled high-level language source files directly into a rel object file. The Microsoft fortran compiler allowed you to get a listing of a compiled file with processor opcodes, but the use of files with assembly code obtained by compiling code from a high-level language was not originally intended. Moreover, the length of variable names (identifiers) in these languages did not exceed 6 characters, which affected their length in rel object files.
> > > > The C standard allowed longer variable and function names. For this reason, the rel format did not meet this requirement.
> > > > When creating the Hi-Tech C compiler, they developed their own object file format, taking into account the increased length of names and support for processors other than Z80. Microsoft M80 and SLR Systems Z80ASM did not even think about this.
> > > > The software package of the then commercial Hi-Tech C compiler is consistent with each other and does not require third-party software and, accordingly, additional costs. When translating libraries to the rel format, you were forced to change (reduce) the names of part of the standard functions. The use of third-party assemblers restricts the C language and turns a good compiler into something non-standard. It seems to me that it is more productive to use the capabilities of Hi-Tech assembler in your development.. And if they are not enough, write your own preprocessor to translate the M80 or Z80ASM syntax into a form that the Hi-Tech ZAS assembler understands..
> > > >
> > > > Andrey Nikitin
> > > Andrey
> > >
> > > Back "in the day" I used Whitesmiths 8080 C - and cross compiler (Whitesmiths on a VAX target was Z80). Whitesmiths used something called
> > > "A-natural" for the assembler.. completely non-standard. So, M80 it was.
> > >
> > > Some people distributed object code in REL format -- Micropro had SuperSort, for example, and Micro B+ from Faircom are examples. In my opinion,
> > > it is important to have a common object format. And, from 1977 to 1982, that was REL. Both Microsoft and Digital Research used it... And that gave us
> > > PLINK-II, SuperSort and Micro B+ Of course, there were others... but, as nice as they are --- I am writing a core AM9511 emulator. It will
> > > (eventually) go into 8080/Z80 emulators (that is the end-goal). But.... it needs to be checked against the actual hardware. So, I want to link the
> > > emulator, written in C, into (for example) FORTRAN-80. Or MBASIC, BASCOM, or have "plain" C wrappers.
> > >
> > > I *could* use Whitesmiths C 2.0 (I used Whitesmiths native 8080 and cross on VAX in the day - 1981 through 1983 or so), because I know that PLINK-II can link that, along with Microsoft REL. But, I wanted to use a slightly more modern variant of C -- Hi-Tech fits the bill. And, with OBJTOMAC I can coerce REL files out of it (and, yes, I have converted the ENTIRE LIBC and LIBM libraries into REL format already). So, I can have my cake, and eat it too. And, as a freebie, if I link with PLINK-II, I get overlays.
> > >
> > > If you recall I translated Hi-Tech ZAS to M80 -- AS2MAC is the program. That was used to convert the run-time library. But, there are...
> > > issues. It is possible to compile C to assembler with Hi-Tech C, and have ZAS *NOT ABLE TO ASSEMBLE THE AS FILE*. And, AS2MAC will
> > > then not be able to convert it, either. Sometimes, specifying optimization helps. As does reducing the source size.This did not show up
> > > while I was converting the run-time library. OBJTOMAC exists to remedy those and does so very well. It just works. (and, when I get around to
> > > it -- post AM9511 code and a couple of other projects, I am going to generate OBJTOREL -- and, once I understand REL -- having never generated a REL file, RELTOOBJ would seem reasonable -- but all that is FAR FUTURE retro work).
> > >
> > > AS2MAC.COM, OBJTOMAC.COM, LIBC.REL and LIBM.REL are all available (with all source) in https://github.com/ratboy666/mtrel
> > >
> > > The thing was -- I took a MAC file produced by my OBJTOMAC tool and assembled it with SLR Systems Z80ASM. The *assembly* went just fine, but the
> > > relocatable result was NOT LINKABLE. That indicates some issues with SLR Z80ASM. If I ran into these sorts of issues back in the day,
> > > I would simply have rejected the tool and gone back to M80.
> > >
> > > FredW
> > In those ancient times, the format of floating-point numbers was not yet standardized. Microsoft has used its version in all of its products. The AM9511 was one of the first coprocessors to speed up the computation of real numbers. He had his own idea of how they should be arranged. Other developers have used their own formats and libraries for this purpose. However, the speed of development of computer technology and the increase in the bit depth of the processor data bus led to the standardization of the representation of floating numbers, and as a result, Intel became the winner in this competition, which immediately released the 8087.
> >
> > Perhaps the AM9511 emulation is needed to run programs written with this coprocessor in mind. Although there are very few such programs, but they are there. CP/M emulators emulate Z80 codes and operating system calls. Your emulation will allow you to extend the capabilities of the latter by executing binary code using this coprocessor. Emulation of AM9511 commands in a CP/M system that does not have this coprocessor is most likely not advisable due to the overhead of emulation, which will reduce the already small memory for the program. In this regard, it is also impractical to use any C compiler for CP/M to emulate AM9511 inside this system.
> >
> > For a while, IBM PC compatible computers were available with or without a coprocessor. Compilers of that time could generate code both for the coprocessor and without it. However, they had significantly more memory, and when composing an executable program, they could use different libraries with code for the coprocessor or emulating it.
> >
> > Andrey Nikitin
> Andrey
>
> This reply is going to ramble. Your communication brought up 4 points I want to address. And a comment from me about the state of software "then" and "now".
>
> ---
>
> Yes! But... the AM9512 implemented IEEE, and Intel licensed both the AM9511 and AM9512, prior to releasing the 8087. I am interested in the AM9511 because it provided 16 bit and 32 bit fixed, and 32 bit float, and functions.. The 9512 didn't have the functions... Before the last AM9511 (and those ran HOT! 2W dissipated in a 24 pin package, afair) dies, I wanted to provide an emulation. Just for my own interest. I wanted to be able to run the emulation on the same machine that runs the actual chip... to allow validation of the emulation! And, speaking of the 8087 as a "ps" -- in 1988 I released
>
> emul87: https://www.pcorner.com/list/UTILITY/EMUL87.ZIP/INFO/
>
> as freeware (no source) (if you have an old DOS system with 286 or 386, have fun with it!) (I used my middle name back then -- F Martin Weigel).
>
> ---
> The emulation *must* be written in C to incorporate into Z80pack. I strongly desire to run it on a Z80 with AM9511 chip. Yes, you are correct... it
> is going to be too large for production. So far, its 20K bytes in length (includes all float functions, single and double fixed) -- missing 32x32->64 multiply
> No optimizations... the final should be 15K in size. But, it will only be run ON the Z80 for validation -- not for production. That will be in Z80pack or
> another host (Altair-Duino).
>
> ---
> For format conversion of floats, I published https://github.com/ratboy666/am9511 at the beginning of this project-- this has floatcnv.c which implements Microsoft 32 bit float, IEEE 32 bit float, HiTech C 32 bit float and AM9511 32 bit float convert back and forth. Written in C, Including floating point output for Hi-Tech (which is fairly huge) -- 11K with tests. Works with Hi-Tech C, GCC and TCC (maybe other compilers). Needs testing, as it is "young" code (only a week old at this writing). I welcome change requests, and patches. The next part of the emulator to be published (soon) will be "ova.c" -- no eggs, overflow arithmetic in fixed format for 16 and 32 bit with proper carry and overflow. In C for hi-tech C and GCC (and TCC).
>
> ---
>
> Very tight code can be produced with Hi-Tech C -- I am using it as a sort of "portable assembler". It would be easy enough to hand-compile floatcnv.c
> and bring it to 1/3 of its object size. But... YAGNI (yah ain't gonna need it) -- there has been no need to optimize it yet...
>
> ---
> As a side note, I am doing this as a hobby. At the early pandemic, my partner bought me an Altair-Duino. This was my first personal computer (the
> original Altair 8800). I started having a blast programming for the 2Mhz 8080 -- it occurred to me that there were things I had never done... work
> with a A9511 was one of them. But, I also realized that these early personal systems were more capable than I had thought at the time. They
> force "methodical programming"; that is more thinking about what you are doing, resulting in better programs. Simply because compiling
> etc. is so time expensive. Think first! No "experimenting". So, my OBJTOMAC program actually worked the first time! I was darn surprised that
> it didn't work with SLR! So, much credit to whoever wrote M80/L80. That worked predictably!
>
> I was working with a young lad in 2019/2020, "mentoring". He had the urge to dive in and program ... without looking for what was there,
> and how it could be pieced together. Spent a year teaching the lad Unix (Linux) command line, sqlite3, and other topics. How to get an
> aesthetic sense of what is a "good" piece of software or a "good" system. And, looking at the Altair-Duino, I am trying to recover a sense
> of the "good" of programming "back in the day". It is a fun journey.
>
> FredW

On Tuesday, June 8, 2021 at 8:23:23 AM UTC-4, nikiti...@gmail.com wrote:
> вторник, 8 июня 2021 г. в 06:10:57 UTC+3, fred_...@hotmail.com:
> > On Monday, June 7, 2021 at 10:06:42 PM UTC-4, Tony Nicholson wrote:
> > > On Tuesday, June 8, 2021 at 4:49:11 AM UTC+10, FredW wrote:
> > > > I am using Hi-Tech C 3.09.
> > > [snip]
> > > > Anyone else can weigh in on SLR Z80ASM vs Microsoft M80? For building AM9511 native, I think I will use Hi-Tech ZAS, and LINK, *or* M80 and L80
> > > > (LD80) or PLINK. At least those choices work without issue.
> > > >
> > > > As I recall "in the day" I used M80 exclusively, but I forgotten WHY. It becomes clear again.
> > > I have used a mix of assemblers.. starting with the TDL/PASM (8080-style
> > > with Z80 extensions) and PLINK then PLINK-II; and then for a long time the
> > > Microsoft M80 macro assembler (because I like the Zilog mnemonics).
> > > The SLR Z80ASM assember is fast but has some "quirks" as you have
> > > found.
> > >
> > > In the last few years with my tinkering in the Z280 world, I've migrated to
> > > mostly using Hector Peraza's ZSM4 macro assembler. It has a /Sn switch
> > > that can select symbol lengths between 6 and 8 characters, and produces
> > > object files in the standard Digital Research LINK format (also compatible
> > > with Microsoft L80 and PLINK linkers - but it doesn't use the M80 V3.44
> > > or SLR linker REL format extensions). It can also assemble Z80/Z180
> > > and Z280 opcodes (all Zilog mnemonics) and uses a range of
> > > M80-compatible pseudo-ops (like DW/DEFW, DS/DEFS etc).
> > >
> > > Hector provides the assembler source-code and binaries for CP/M (and
> > > his RSX180/RSX280 operating systems) with full documentation at
> > >
> > > https://github.com/hperaza/ZSM4
> > >
> > > ZSM4 runs fine under the John Elliott's zxcc CP/M emulator on Linux/
> > > macOS too (from https://www.seasip.info/Unix/Zxcc/ ).
> > >
> > > HI-TECH's ZAS has some quirks too (strict source-code formatting) and
> > > has an added advantage of being able to optimise absolute jumps (JP)
> > > into relative ones (JR) - albeit with a strange label convention for forward
> > > references. The object file format is different too (see Andrey Nikitin's
> > > recent reconstruction of the HI-TECH's object file DUMP utility for an
> > > explanation of the object-file format (https://github.com/nikitinprior/ddump ).
> > >
> > > Tony
> > Tony
> >
> > I reversed Hi-Tech OBJ format - see my OBJTOMAC utility that converts
> > OBJ from Hi-Tech to MAC that can be assembled by M80. If you get MTREL,
> > you also get the Hi-Tech LIBC and LIBM in REL format.
> >
> > FredW
> The Microsoft M80 and Z80ASM SLR Systems macro assemblers and some others were developed to compile source files in assembly language. The Microsoft fortran, basic, and cobol compilers compiled high-level language source files directly into a rel object file. The Microsoft fortran compiler allowed you to get a listing of a compiled file with processor opcodes, but the use of files with assembly code obtained by compiling code from a high-level language was not originally intended. Moreover, the length of variable names (identifiers) in these languages did not exceed 6 characters, which affected their length in rel object files.
> The C standard allowed longer variable and function names. For this reason, the rel format did not meet this requirement.
> When creating the Hi-Tech C compiler, they developed their own object file format, taking into account the increased length of names and support for processors other than Z80. Microsoft M80 and SLR Systems Z80ASM did not even think about this.
> The software package of the then commercial Hi-Tech C compiler is consistent with each other and does not require third-party software and, accordingly, additional costs. When translating libraries to the rel format, you were forced to change (reduce) the names of part of the standard functions. The use of third-party assemblers restricts the C language and turns a good compiler into something non-standard. It seems to me that it is more productive to use the capabilities of Hi-Tech assembler in your development. And if they are not enough, write your own preprocessor to translate the M80 or Z80ASM syntax into a form that the Hi-Tech ZAS assembler understands.
>
> Andrey Nikitin

Andrey

I was also curious about 6 character external names. In "The C Programming Language", Second Edition, Brian W. Kernighan and Dennis M. Ritchie, Page 259 (Appendix C: Summary of Changes).

- The minimum significance of all internal identifiers is increased to 31 characters; the smallest mandated significance of identifiers with external linkage remains 6 monocase letters. (Many implementations provide more).

This was 1988!

So, it is probably good that Hi-Tech supports longer external identifiers.... but... C did not require that. C89 has 6 character monocase for external identifiers.
M80 and L80 are fine! But... drum roll... Hi-Tech prepends an underscore, reducing it to 5... See my library notes when I created LIBC.REL and LIBM.REL

To be exact: I introduced stncpy, stncat and stncmp (for strncpy strncat, and strncmp) With 6 character limit AND prepending '_' we got
_strnc for ALL of these functions! we now get _stncp _stnca and _stncm which works. I also renamed __cpm_clean to __cpcl

I would have preferred Hi-Tech C appends a '_' to names: that would give a full six -- but I think Whitesmiths had the same issue. The '_'
was put there to avoid user specified names from colliding with system functions. If system functions were limited to 5 characters, we
would have had a full six characters. If you even rebuild the actual compiler, consider moving that underscore to the end!

FredW

вторник, 8 июня 2021 г. в 20:54:10 UTC+3, fred_...@hotmail.com:
> On Tuesday, June 8, 2021 at 8:23:23 AM UTC-4, nikiti...@gmail.com wrote:
> > вторник, 8 июня 2021 г. в 06:10:57 UTC+3, fred_...@hotmail.com:
> > > On Monday, June 7, 2021 at 10:06:42 PM UTC-4, Tony Nicholson wrote:
> > > > On Tuesday, June 8, 2021 at 4:49:11 AM UTC+10, FredW wrote:
> > > > > I am using Hi-Tech C 3.09.
> > > > [snip]
> > > > > Anyone else can weigh in on SLR Z80ASM vs Microsoft M80? For building AM9511 native, I think I will use Hi-Tech ZAS, and LINK, *or* M80 and L80
> > > > > (LD80) or PLINK. At least those choices work without issue.
> > > > >
> > > > > As I recall "in the day" I used M80 exclusively, but I forgotten WHY. It becomes clear again.
> > > > I have used a mix of assemblers.. starting with the TDL/PASM (8080-style
> > > > with Z80 extensions) and PLINK then PLINK-II; and then for a long time the
> > > > Microsoft M80 macro assembler (because I like the Zilog mnemonics).
> > > > The SLR Z80ASM assember is fast but has some "quirks" as you have
> > > > found.
> > > >
> > > > In the last few years with my tinkering in the Z280 world, I've migrated to
> > > > mostly using Hector Peraza's ZSM4 macro assembler. It has a /Sn switch
> > > > that can select symbol lengths between 6 and 8 characters, and produces
> > > > object files in the standard Digital Research LINK format (also compatible
> > > > with Microsoft L80 and PLINK linkers - but it doesn't use the M80 V3.44
> > > > or SLR linker REL format extensions). It can also assemble Z80/Z180
> > > > and Z280 opcodes (all Zilog mnemonics) and uses a range of
> > > > M80-compatible pseudo-ops (like DW/DEFW, DS/DEFS etc).
> > > >
> > > > Hector provides the assembler source-code and binaries for CP/M (and
> > > > his RSX180/RSX280 operating systems) with full documentation at
> > > >
> > > > https://github.com/hperaza/ZSM4
> > > >
> > > > ZSM4 runs fine under the John Elliott's zxcc CP/M emulator on Linux/
> > > > macOS too (from https://www.seasip.info/Unix/Zxcc/ ).
> > > >
> > > > HI-TECH's ZAS has some quirks too (strict source-code formatting) and
> > > > has an added advantage of being able to optimise absolute jumps (JP)
> > > > into relative ones (JR) - albeit with a strange label convention for forward
> > > > references. The object file format is different too (see Andrey Nikitin's
> > > > recent reconstruction of the HI-TECH's object file DUMP utility for an
> > > > explanation of the object-file format (https://github.com/nikitinprior/ddump ).
> > > >
> > > > Tony
> > > Tony
> > >
> > > I reversed Hi-Tech OBJ format - see my OBJTOMAC utility that converts
> > > OBJ from Hi-Tech to MAC that can be assembled by M80. If you get MTREL,
> > > you also get the Hi-Tech LIBC and LIBM in REL format.
> > >
> > > FredW
> > The Microsoft M80 and Z80ASM SLR Systems macro assemblers and some others were developed to compile source files in assembly language. The Microsoft fortran, basic, and cobol compilers compiled high-level language source files directly into a rel object file. The Microsoft fortran compiler allowed you to get a listing of a compiled file with processor opcodes, but the use of files with assembly code obtained by compiling code from a high-level language was not originally intended. Moreover, the length of variable names (identifiers) in these languages did not exceed 6 characters, which affected their length in rel object files.
> > The C standard allowed longer variable and function names. For this reason, the rel format did not meet this requirement.
> > When creating the Hi-Tech C compiler, they developed their own object file format, taking into account the increased length of names and support for processors other than Z80. Microsoft M80 and SLR Systems Z80ASM did not even think about this.
> > The software package of the then commercial Hi-Tech C compiler is consistent with each other and does not require third-party software and, accordingly, additional costs. When translating libraries to the rel format, you were forced to change (reduce) the names of part of the standard functions. The use of third-party assemblers restricts the C language and turns a good compiler into something non-standard. It seems to me that it is more productive to use the capabilities of Hi-Tech assembler in your development. And if they are not enough, write your own preprocessor to translate the M80 or Z80ASM syntax into a form that the Hi-Tech ZAS assembler understands.
> >
> > Andrey Nikitin
> Andrey
>
> I was also curious about 6 character external names. In "The C Programming Language", Second Edition, Brian W. Kernighan and Dennis M. Ritchie, Page 259 (Appendix C: Summary of Changes).
>
> - The minimum significance of all internal identifiers is increased to 31 characters; the smallest mandated significance of identifiers with external linkage remains 6 monocase letters. (Many implementations provide more).
>
> This was 1988!
>
> So, it is probably good that Hi-Tech supports longer external identifiers.... but... C did not require that. C89 has 6 character monocase for external identifiers.
> M80 and L80 are fine! But... drum roll... Hi-Tech prepends an underscore, reducing it to 5... See my library notes when I created LIBC.REL and LIBM.REL
>
> To be exact: I introduced stncpy, stncat and stncmp (for strncpy strncat, and strncmp) With 6 character limit AND prepending '_' we got
> _strnc for ALL of these functions! we now get _stncp _stnca and _stncm which works. I also renamed __cpm_clean to __cpcl
>
> I would have preferred Hi-Tech C appends a '_' to names: that would give a full six -- but I think Whitesmiths had the same issue. The '_'
> was put there to avoid user specified names from colliding with system functions. If system functions were limited to 5 characters, we
> would have had a full six characters. If you even rebuild the actual compiler, consider moving that underscore to the end!
>
> FredW

I think the compiler developers made the decision about the underscore character at the beginning of the characters consciously. This is some protection. If the name is more than 6 characters, the compiler truncates the subsequent characters, and then there may be a conflict with the names assigned by the user.

Andrey Nikitin