suggesion: repurpose i/o (port 0) (type 0) as the type manager

Managing type allocations is brittle as retroforth depends on hard wired numbers. Ideally the only hard wired type should be the type manager (type 0) that can resolve and register types based on names installed on (port 0). Then interface code can then map 'FPU to its dynamically allocated type id and then locate the port(s) or conclude the given device type is not present.

Coders can then use sensibly qualified name such as 'com.intermine.JSON to determine the appropriate device type to use without conflicts from the vm and retroforth perspectives. This lookup is only performed once so it will not add additional overhead to ongoing i/o operations.

It should also be possible to create i/o types and ports in retroforth itself and have the vm use the callback when the i/o port is invoked. This would allow for default slower implementations for cross platform code and enhanced speed were the vm has a more efficient implementation of device type.

This also cleanly defines a minimum vm that does have any character output and is just a processing node.

Assigned to
8 months ago
8 months ago
suggestion vm

~crc_ 8 months ago

This is a good idea, though it will break compatibility with existing images.

I'll work on it (or at least something similar), but it won't be in the next release (2020.10); it might be possible for the following one (2021.1) though.

~scott91e1 8 months ago

That is indeed the case. Perhaps a compromise; map the type manager to (type 999) on (port 999). Have the type manager allocate dynamic types starting from 998 down and the existing code with "well known" low ports/types can stand. New code needs to be added by the vm to register its static type names with the type manager before the machine is started.

Register here or Log in to comment, or comment via email.