New: RPN3.NET (XML-defined universal RPN simulator for .NET software or hardware)

[Nick]

(08-22-2016 12:32 AM)Claudio L. Wrote:  I think it's a cool concept. It's not clear to me what's going to be defined in the XML file, though.
Is it just the screen display and keyboard layout and behavior? or the actual behavior of every keystroke/command?
If you can define the basic commands without programming, then how would you define let's say "RCL 00" in the XML file? Is there going to be some sort if intermediate language?

Claudio,

Thank you for your question -- it helps me to think this through and extend the idea. To answer your question: Some of all, yes.

The idea behind the configuration (XML file(s)):

The RPN calculators have a lot of things in common and can share a great deal of simulator code across models. If we build for that, what’s left is the differences that can be defined in the XML files giving multiple types of support from a single core.

By maintaining layers of separation, we could re-use the same function library across multiple configurations in both software or hardware. And these function aren’t limited to math, also consider File I/O, TCP/IP, serial I/O… as the modules will have access to the core object space via a defined plugin interface, other modules functions’, the .NET framework library, and any supported hardware.

For stack, we have 3-level, 4-level, 8-level, n-level with different behavior for X/entry and with or without the constant behavior (commonly T). If you were to describe those settings in an XML file, then a single piece of software could simulate all of those types. Or a function to re-define the stack size could be presented to the user (such as on the WP34S) for any depth (or unlimited) given the size is now arbitrary.

For display, there’s 1 line, 4 line, n-line and that could output to a resizable display if it were of the high-res type, but alternately we could direct the same output to a console or a connected LCD text display. Maybe the annunciators are on the LCD display or maybe they’re an LED wired to a GPIO pin… a configuration file could define that mapping.

RCL is a good example. So let’s say RCL is part of the core library (basic functions, no module required). It has an input… If you made a “RCL” button, then it might prompt for the parameter. If you made a “RCL 00” button, in the config file you might give it a fixed 00 parameter. But in either case, they could both share the same RCL-XX function in the library.

This definition doesn’t have to be a key at all… it could also be 42-style menu or a 41-style catalog with either listing defined in XML as well (or both within the same user-defined layout / XML file). This is how the number of shift keys becomes arbitrary (and why text labeling should be independent of layout as well)... if you want 1 or 3 shift keys… or even chorded (think of the WP34 complex key) it wouldn’t matter as the layout is independent of the other subsystems of the calculator.

The way a function such as CHS could have 3 different behaviors is by writing the functions plugin-style. Consider if an XML stated “15C as the default behavior for all functions” or alternatively “41 as the default behavior with 15C behavior just or the CHS key”. In either case, the function examines the core environment for things such as stack size and configuration factors, then decides how to respond accordingly. And again, because of the separation, a "CHS behavior setting" could be exposed to the user as a function so that they could change this behavior from a menu.

And to extend this idea further, let’s say a module developer created a function and they want to offer 3 different behaviors. There’d be a default (likely) so that you wouldn’t have to do any setup at all to use their function. But if you wanted say alternate or maybe beta behavior, you could add the line they specified to your XML configuration file.

Perhaps the layers of settings / overrides is as follows:
1. The function defaults (whatever the module/function author picked)
2. XML-settings (whatever the 'designer' chose in their implementation to override those defaults given the core or function settings)
3. runtime-settings (the module author could also include functions to adjust the behavior -- giving the user the option to adjust the behavior at runtime (calc on); simply add them to a menu/catalog -- or key)

Intermediate language:

No. The only IL exists in the core and modules -- the “ROM-type” (DLL) code written in .NET (which allows you to compile various languages into the same executable, high performance, not runtime interpreted -- for those not familiar; one user could contribute a VB.NET module and another a C# module and they would both co-exist just fine; the IDE to do this is a free download for non-commercial use)

It was my thought that userspace (keystroke programs) on-device could be treated the same as the core or module function giving a non-programming user the same flexibility in defining custom key/menu layouts of their own on-board code the same as would be a module they added.

Software vs Hardware:

This same core / configuration system applies to both: (example) Making your own custom HP-15C on your smartphone and (example) Making your own custom 97 in hardware with a Raspberry Pi 3 (PC on a board - $35USD) or similar device that can run the .NET framework.

Tradeoffs:

The “ROM” code will be larger, and the memory requirements higher so this isn’t intended to be as efficient as a classic machine. The idea is to make a common codebase more universal and for things like 15C complex behavior or CHS behavior… rather than “vote” on which way to go -- let’s do them both and expose that as a user setting. With the level of abstraction I have in mind, I see this as feasible.

Thanks,
Nick