Some time ago I have announced the T3X/Z compiler here, a T3X compiler
that runs on CP/M on the Z80 and generates code for CP/M on the Z80.

In the past months I have created a new version of T3X that runs not
only on CP/M, but also on the virtual Tcode machine (TCVM), DOS (8086),
and 386-based Unix systems. Programs can be cross-compiled in many
different ways, like DOS->CP/M, CP/M->DOS, Unix->CP/M. TCVM->DOS,
TCVM->Unix, etc... There is a total of 14 cross compilers that can be
built from the code.

Here is a link to the sources: http://t3x.org/t3x/index.html#0

CP/M and DOS binaries of the compiler are included in the archive.

The T3X language accepted by the new compiler is (almost) a superset
of T3X/Z (the intrinsic T3X class has been replaced by modules, so two
lines of boiler-plate have to change at the beginning of each program).

The new language has separate namespaces via modules, loadable modules
in separate file, unsigned operators (0xfffe .< 0xffff is true), and
lots of predefined functions in a library. For example, here is
"Hello, World!" using a simple I/O library:

use t3x;
use string;
use io;

do
io.writeln("Hello, World!");
end

The compiler still self-compiles on CP/M, but needs 48K bytes of TPA
now (T3X/Z uses 44K bytes). It self-compiles in 10 minutes on a 4MHz
Z80 emulator. It also requires (at least) two files now: the compiler
binary itself and the T3X core module, which was intrinsic before.

Anyway, I hope some of you may enjoy programming CP/M using a
high-level language of the 1990s!

--
Nils M Holm < n m h @ t 3 x . o r g > http://t3x.org

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, October 2, 2022 at 12:12:36 PM UTC+2, Nils M Holm wrote:

Some time ago I have announced the T3X/Z compiler here, a T3X compiler
that runs on CP/M on the Z80 and generates code for CP/M on the Z80.

In the past months I have created a new version of T3X that runs not
only on CP/M, but also on the virtual Tcode machine (TCVM), DOS (8086),
and 386-based Unix systems. Programs can be cross-compiled in many
different ways, like DOS->CP/M, CP/M->DOS, Unix->CP/M. TCVM->DOS, TCVM->Unix, etc... There is a total of 14 cross compilers that can be
built from the code.

Here is a link to the sources: http://t3x.org/t3x/index.html#0

CP/M and DOS binaries of the compiler are included in the archive.

The T3X language accepted by the new compiler is (almost) a superset
of T3X/Z (the intrinsic T3X class has been replaced by modules, so two
lines of boiler-plate have to change at the beginning of each program).

The new language has separate namespaces via modules, loadable modules
in separate file, unsigned operators (0xfffe .< 0xffff is true), and
lots of predefined functions in a library. For example, here is
"Hello, World!" using a simple I/O library:

use t3x;
use string;
use io;

do
io.writeln("Hello, World!");
end

The compiler still self-compiles on CP/M, but needs 48K bytes of TPA
now (T3X/Z uses 44K bytes). It self-compiles in 10 minutes on a 4MHz
Z80 emulator. It also requires (at least) two files now: the compiler
binary itself and the T3X core module, which was intrinsic before.

Anyway, I hope some of you may enjoy programming CP/M using a
high-level language of the 1990s!

--
Nils M Holm < n m h @ t 3 x . o r g > http://t3x.org

A while ago I made a version that produces relocatable REL object files:

https://github.com/hperaza/T3XZ-RSX180/tree/master/rel-output

The main advantage is that the output module can now be linked to external assembler routines, and that the run-time library is not longer embedded into the compiler code, making the compiler size smaller. Different OSes can be supported via different
libraries, requiring minimal, or no compiler/application changes. Also, since REL files support separate code and data segments, the compiler no longer needs to generate jump instructions to get around static data, also reducing the generated code size.

The disadvantages being the extra linking step required, and the 6..8-character symbol name length limitation of the REL specification. The last made it necessary to implement name aliases to the T-object functions in the compiler, as e.g. T.MEMCOMP and
T.MEMCOPY names will clash if the library is compiled with the "standard" 6-char symbol name length (the supplied Makefile forces 8-char symbol names anyway.)

The port was made mostly for the RSX180 and RSX280 OSes, but a CP/M version of both the compiler and the library is generated too.

Note that RSX180/280 have different end-line conventions than CP/M, and in a way that complicates matters for the T.NEWLINE method. Specifically, lines are output as LF,<text>,CR whereas in CP/M the convention is <text>,CR,LF. The result is that a
program written for RSX180/280 will output an extra empty line after the CCP prompt when compiled for CP/M; while a CP/M program would overwrite the MCR prompt when compiled for RSX180/280. A T.WRITELN method would be more appropriate.

Hector.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)