Re: [Tack-devel] Information for installation guide update

[David G. <dg...@co...>]

That's mostly correct, and how it's *intended* to work. However, there's a
lot of historical baggage. Before 6.0 there was just a mach directory which
contained a mixture of platform-dependent and platform-independent code.
I've been moving stuff into plat as I've been working on it but there's
still a lot of very old and unused things left in mach.

Most of the current platforms don't use specific cv programs. Instead they
use either aslod or aelflod (in utils). OSX is the single exception.
Meanwhile, nearly all the old cv programs in mach are unused. I believe the
one exception *there* is the PDP11 one, and that should really be moved
into plat/pdpv7 as it's specific to V7 Unix.

My guess would be that any tool to produce hex or srec would live in
plat/utils, as this would be generic to multiple architectures --- call it
ahexlod, say. You'd still use led to link your program.

Incidentally, regarding mach: every tool there is built *for every plat*.
So if you have two different 8080 platforms, you get two assemblers, code
generators, etc. The reason for this is that plats might have different
compilation options. For example: I've just done a tonne of work getting
the 8080 code generator into decent shape for Fuzix and CP/M, and one of
the opimisations there is to use rst instructions to call common helper
routines. Another 8080-based plat might not want these, and so would build
the code generator with different flags to disable this feature. (This is
part of what makes the ACK a pain to build.)

Re the floating point library: it's in mach/proto/fp. The only mach which
uses it so far is i86.


On Fri, 8 Mar 2019 at 19:19 Carl Eric Codere via Tack-devel <
tac...@li...> wrote:

> Greetings,
>                I am trying to update a bit the install guide, especially
> in regards to the source directory structure, so i can use it as my own
> reference, just want to make sure i understand correctly?
>
> "mach" shall now contain the CPU specific code but which is operating
> system independent, in other words:
>
> cg     the backend code generator   (*.m => *.s)
> ncg     the new backend code generator (*.m => *.s)
> mcg     the modified backend code generator
> as     the CPU specific assembler (*.s => *.o) or
>     assembler/linker (*.s + libraries => a.out)
> cv     conversion programs for a.out files. Replaced by cvmach in the
> "plat" directory.
> dl     down-load programs. Moved to cvmach in the "plat" directory.
> top     the target optimizer
> int     source for an interpreter
> ce     code expander (fast back-end)
>
> libem to create runtime system used by code generators
> libend library defining end, edata, etext
> libfp configuration data to create floating point library
> libdb to create debugger support library
>
> libce to create runtime system used by code expanders
>
>
> While the "plat" directory contains the following:
>
> cvmach conversion program to convert from a.out to platform specific
> binaries.
> emu         system specific platform emulator or simulator used for
> testing.
> include system-dependent include files
> libsys system-dependent library used to interface with the operating
> system.
>
>
> Some questions?
> 1. Are the above hypothesis correct?
> 2. As you can see above, from me dl / cv are now in "plat", but maybe i am
> wrong in this case? Where would a converter that converts to Intel HEX or
> Motorola SREC be placed? Or this is just too hypothetic now!?
> 3. Where is the software floating point arithmetic emulation layer? Does
> it actually exist? Sorry for this stupid question, but i cannot to find it!
>
>
>
> Carl
>
>
> _______________________________________________
> Tack-devel mailing list
> Tac...@li...
> https://lists.sourceforge.net/lists/listinfo/tack-devel
>