r ld80
r plink-ii
r m80 =hello/l?File not found
r plink-ii
helloHello, world!
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.
On Tuesday, June 8, 2021 at 4:49:11 AM UTC+10, FredW wrote:Tony
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
Anyone else can weigh in on SLR Z80ASM vs Microsoft 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 ).
TonyTony
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: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
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 ).
TonyTony
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.
FredWThe 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
The C standard allowed longer variable and function names. For this reason, the rel format did not meet this requirement.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
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)
Andrey Nikitin
On Tuesday, June 8, 2021 at 8:23:23 AM UTC-4, nikiti...@gmail.com wrote: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
вторник, 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 ).
TonyTony
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.
FredWThe 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
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 yourThe 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)
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 getAndrey NikitinAndrey
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-
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 г. в 06:10:57 UTC+3, fred_...@hotmail.com: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
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 ).
TonyTony
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.
FredWThe 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
The C standard allowed longer variable and function names. For this reason, the rel format did not meet this requirement.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
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)
Andrey Nikitin
вторник, 8 июня 2021 г. в 16:49:32 UTC+3, fred_...@hotmail.com: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
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 ).
TonyTony
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.
FredWThe 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
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 assemblerThe 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 (
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 getAndrey NikitinAndrey
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 --
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 standardizationIf 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.
FredWIn 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
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 toextend 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
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 executableprogram, they could use different libraries with code for the coprocessor or emulating it.
Andrey Nikitin
On Tuesday, June 8, 2021 at 11:26:56 AM UTC-4, nikiti...@gmail.com wrote: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
вторник, 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 ).
TonyTony
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.
FredWThe 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
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 assemblerThe 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 (
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 getAndrey NikitinAndrey
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 --
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 theIf 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.
FredWIn 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
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 thePerhaps 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
program, they could use different libraries with code for the coprocessor or emulating it.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
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...Andrey NikitinAndrey
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
emul87: https://www.pcorner.com/list/UTILITY/EMUL87.ZIP/INFO/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
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
---
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: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
вторник, 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 ).
TonyTony
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.
FredWThe 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
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 yourThe 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)
Andrey NikitinAndrey
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
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 74:32:46 |
| Calls: | 6,657 |
| Calls today: | 3 |
| Files: | 12,203 |
| Messages: | 5,332,523 |
| Posted today: | 1 |