[NTLK] [ANN] Newton C++ toolchain utilities (ELFtoNTK & ELFtoPKG)

[Eckhart Köppen]

That is pretty cool :)! The advantage of this approach is that it should be possible to use modern C++, CFront 2.1 by all standards pre-historic. I was able to get CFront 2.1 at least compiled and produce some output (https://40hz.org/Pages/mottek/2020/2020-02-27/), but it’s still quite an effort to turn that into a proper tool chain. I also need to publish the patches somewhere...

Again, great stuff!

Eckhart

> On 8. Jun 2020, at 13:42, Paul Guyot <pguyot at kallisys.net> wrote:
> 
> Hello all,
> 
> I am pleased to announce the release of Newton C++ toolchain utilities that can be used to generate C++ code for NewtonOS using gcc.
> This is available as part of the DCL (Desktop Connection Library) and was successfully used to generate a Newton package on macOS X 10.15 with arm-none-eabi-g++ 8.3.0 and arm-none-eabi-binutils.
> 
> Source code is available for download on GitHub here:
> https://github.com/pguyot/DCL/tree/master/Sample_Code/ToolchainUtils
> 
> ELFtoNTK is the equivalent of AIFtoNTK and actually a clone of a similar tool developed by Eckhart Köppen [1]. From an ELF shared library, it generates a .ntkc file for use with Newton Toolkit (NTK).
> ELFtoPKG is the most innovative tool. From an ELF shared library, it generates a Newton package with a single "protocol" part. It effectively replaces Packer that generated a package part from a raw protocol part. The innovation lies in allowing relocation in the protocol code, something that the original Newton C++ Tools did not allow.
> 
> Sample code is provided to illustrate the use case.
> 
> For the history, I've been working on porting a large library to NewtonOS and was hit by a bug in NewtonOS. It doesn't handle embedded C++ code in NewtonScript packages larger than about 128KB (the package store was eventually corrupted and I had to erase the flash file), so I tried to package the library as a protocol only to realize Newton C++ Tools did not handle relocation, which were also needed. After writing a prototype ELF loader on NewtonOS and toying with global read/write variables using fdpic runtime, I wrote ELFtoPKG to try and apply relocations with protocol parts and it just worked. Additionally, Newton C++ compiler just couldn't compile some of the bits, so this made the porting process much easier.
> 
> For newcomers to Newton programming, Newton programs mostly rely on NewtonScript and C++ can only be used to accelerate computation or writing drivers. This toolchain doesn't allow you to write a regular Newton application, Newton Toolkit (or alternative tools) is still required.
> 
> Paul
> 
> [1] https://40hz.org/Pages/newton/hacking/experiments/