вторник, 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