DSP Robotics Support

Thanks KG !

Studying this one too

OK, this might be the finished product. I've also written a manual that describes how to safely use the module and how to modify your schematic to work with it properly. I would appreciate if someone could do some tests to confirm it is working on different systems. Also I accept suggestions and criticism, especially for the manual.

KG... I have no word.

using adress of string containing ASM... it's brilliant, but what a pain !!
Thank you very very much for this work, which may had took you long time to come up with this complète solution !

KG... I have no word.

using adress of string containing ASM... it's brilliant, but what a pain !!
Thank you very very much for this work, which may had took you long time to come up with this complète solution !

francoisreme wrote:KG... I have no word.

using adress of string containing ASM... it's brilliant, but what a pain !!
Thank you very very much for this work, which may had took you long time to come up with this complète solution !

Actually, it was almost suspiciously easy. The schematic worked on second try! (first time it crashed, as usual with ASM). I would really love you people share some schematics where this module is put to use. I currently don't have any project taking advantage of this...

KG, by the way. The nicest trick of your work seems the call of the adress to machine code stored in a ruby string.
This really open new fields for assembly programming.

It seems there is a way executing any machine code even if used instructions was not present in assembleur module operators list. In a sense it seems it could open the way to executing any externaly compiled machine (x86) code directely in FS. (mainly for geeks like us who want fast processing code).

Seems there is a chance to write C code (with branching, functions, etc...) and directely compile it into machine code, store that to a string, and execute that with your trick ? no ?

francoisreme wrote:KG, by the way. The nicest trick of your work seems the call of the adress to machine code stored in a ruby string.
This really open new fields for assembly programming.

It seems there is a way executing any machine code even if used instructions was not present in assembleur module operators list. In a sense it seems it could open the way to executing any externaly compiled machine (x86) code directely in FS. (mainly for geeks like us who want fast processing code).

Seems there is a chance to write C code (with branching, functions, etc...) and directely compile it into machine code, store that to a string, and execute that with your trick ? no ?

Yes, this trick was originally discovered by MyCo in this post, so all credit to him. The real problem is obtaining a machine code of a compiled C function and making sure you adhere to the calling convention. I have never actually tried that, though I probably could.

wow!!!!!!!!!

so is this already safe to use within publicly available devices?

.......and (excuse my ignorance here) will there be any trouble down the line if a device uses it now and in the future (near we all hope) same schematic will be compiled as 64bit?

faxinadu wrote:wow!!!!!!!!!

so is this already safe to use within publicly available devices?

.......and (excuse my ignorance here) will there be any trouble down the line if a device uses it now and in the future (near we all hope) same schematic will be compiled as 64bit?

unknown as of yet. It will probably not be compatible with 64bit version, but fix should be very easy to do (literally the only difference in operation will be the size of the address and corresponding variable - 64bit instead of 32bit). Though that is probably true for any Assembler code that touches pointers.
The only possible problem may arise if, in future versions of Flowstone, there are changes to how Ruby component operates or how streams get compiled.

As for whether this is safe to use, the manual goes into meticulous detail about how to modify your schematic to ensure safe operation. Generally, if a device can run any flowstone-made software it should have no problems with this also - it literally just implements for-loop that spans multiple modules. Tests so far reveal no issues... if you experience some, please report them here or PM me

I used your oversample in my overdrive. Thanks KG !