[NTLK] [ANN] mbedTLS 2.16.6 for NewtonOS
pguyot at kallisys.net
Mon Jun 15 05:58:33 EDT 2020
> Date: Sun, 14 Jun 2020 23:16:55 +0200
> From: "Matej Horvat" <matej.horvat at guest.arnes.si>
> I looked at the file Common/mbedtls/config.h and I think you could disable
> some options to reduce the size of the code:
True. However, the main limitation does not seem to be the size of the code but rather the RAM usage. I am not sure a large code impacts RAM usage much as packages are decompressed on the fly by the virtual memory manager.
Half of the package is actually root certificates data which probably compresses quite well on the Newton.
A large chunk of RAM is taken by these root certificates when loaded, so large that I had to allocate it in a separate heap as the "inet" task heap was too small.
The rationale is that certificates are loaded in PEM format and converted to DER format and kept in RAM for SSL handshake. A solution would be to avoid keeping a copy of the certificates in DER format but instead refer to a read-only copy that would be stored in the package. It would require storing the certificates in something different from the package store which does seem to copy data on the fly, and use a new function from mbedTLS that allows this, but it is not available in 2.16.6 release.
> Since you needed to make your own development tools for this, do you
> happen to know why the Newton C++ Tools can't (officially) generate code
> for OS 1.x? The OS can execute NewtonScript functions that are compiled
> into BinCFunctions, so I don't see any obvious reason why C++ code
> wouldn't work.
I am sorry I have no answer to this question as I know very little about NewtonOS 1.x. Are you sure that NewtonOS 1.x can execute native code that is stored in binaries? BinCFunction might just be pointers to native code in ROM with funcPtr being the address divided by 4? Besides, relocation in packages is something that was added with NOS 2.0, and position independent code requires relocation as soon as it returns pointers of pointers.
Still, we probably can generate native code through protocols that probably were not introduced with NewtonOS 2.0.
More information about the NewtonTalk