Question: I once heard somebody talk about a micro-controller (with a minimal instruction set) where every register could be the program counter. It did not have jump or call instructions. You had 'emulate' those with the instruction (possibly conditionally) that changed the assignment of the program counter to one of the instructions. If I am not mistaken, it had eight registers. Does this ring a bell?
“The ARM architecture provides sixteen 32-bit general purpose registers (R0-R15) for software use. Fifteen of them (R0-R14) can be used for general purpose data storage, while R15 is the program counter whose value is altered as the core executes instructions. An explicit write to R15 by software will alter program flow.”
Similarly, the PDP-11 used R7 for that. https://en.wikipedia.org/wiki/PDP-11_architecture: “The CPU contains eight general-purpose 16-bit registers (R0 to R7). Register R7 is the program counter (PC)”
I’m not aware of any CPU where “every register could be the program counter”. Such a feature also feels weird to me from a design view because I think it complicates the hardware with few (code might be smaller for a limited set of jumps) benefits. Maybe you’re confusing that with the ability to jump to whatever address is in any of the general purpose registers?
“The SEP instruction can select any of the 16 registers to be the program counter. The SEX instruction can select any of the 16-bit registers to be the index register.”
That description does not match the RCA 1802 [1] perfectly, but it is probably the best known microprocessor (not a microcontroller, though) without a dedicated program counter. There are a lot of misconceptions about it floating on the internet, so I would not be surprised to hear it described as you did.
What about privacy? Maybe not everyone wants to share his information with every far relative that you might never have met or twenty years ago when your grandmother died and you already have become a grandparent as well.
I find this a bit disappointing. Why not publish it with the preprint. Now we have no way to establish the quality of the two solutions or whether it is even possible to improve one of the solutions. I wonder why the C variant could not implement a JSON parser without malloc and free, while the RUST variant could.
Really strange the the C JSON parser has to use malloc where the RUST version does not. As if it is not possible to write a JSON parser in C that does use malloc. I presume that the syntax of the commands that the device will accept is known, and than there is no reason why you have to build a DOM of the JSON before you can process it. Apparently, the RUST version can do it. I really begin to question the abilities of two teams if the one team failed to implement a JSON parser solution without using memory allocations.
Part of the C protocol implementation is generated, and that generator chose the JSON parser. As it worked and there was plenty of memory left on the MCU, it was kept.
We're mentioning this in the paper: "The heap is entirely attributable to Parson's dynamic
allocation of JSON tree nodes; as memory usage
minimization was not a key goal, we kept Parson (the JSON
parser used by the PNPL code generator by default), noting
that there are less memory heavy options that do not require
a heap at all."
Wasn't memory one of the key indicators looked at?
> The analysis and measurements on hardware indicate no strong reason to prefer C over Rust for microcontroller firmware on the basis of memory footprint or execution speed.
I admit I have not carefully read the paper, and am collating info from comments here, so I may be fully mistaken. The word "strong" also allows for much interpretation, that I'm not a priori critical of, but am skeptical of.
Yeah, you can comfortably work with JSON in C directly on top of the string buffer containing it. Your representation for any JSON entity will just be const char pointer. It's possible to implement JSON path on top of this, and all kinds of niceties, and it's not slow.
Yes you can pin it to core 1 whilst pinning all other tasks to core 0. Then will never be interrupted or preempted (except by interrupts created on core 1)
I developed a similar language as an intermediate language for a C-compiler that I wrote. It uses reverse Polish notation instead of Polish notation [1], because it is easier to compile reverse Polish notation to machine code. I call the language Stack-C. See [2]. There are 32 bit and 64 bit compilers for x86 assembly and there is a memory safe interpreter for the language with a (rather limited) built-in debugger.
reply