Polymorphic Index Terminal

[P@Anand]

While working with index array (or similar primitives) we have to use the index element as I32 format only which is really a question when using them in FPGA code. In most of cases I know the amount of elements in the array I am going to handle. So it would be a better option to make the Index terminal as polymorphic and it accomodates Integer values (I8, I16 and I32).

This idea is not only for FPGA, and also it applies to all the array primitives which uses index terminals.

[Intaris]

Well for non-FPGA targets, the array size is not fixed.  there are ticks to get LV to recognise fixed-length arrays but AFAIK it's not officially supported. (It involves cross-pollinating FPGA and non-FPGA code).

I would like to have the ability to declare fixed-sized arrays on any target, and therefore make this idea a real neccessity.  While I agree with this idea in theory, I'm not sure I want NI taking R&D time from other topics.

Same thing applies to case selectors BTW.

[crossrulz]

Why not allow for the Unsigned Integers as well?

Admittedly, there are very few times where this would come into play.  And when it is with the FPGA, I really hope that the FPGA interpreter takes care of all of that for us.

[SteenSchmidt]

On Desktop and Real-Time where data type sizes does not affect applicability as much as on FPGA, keeping the index inputs as I32 doesn't mean much. The coercion dot does not mean any performance hit for I8, I16, U8, and U16, as those will fit nicely in the I32 (and thus won't trigger a real coercion at runtime). A coercion is a possibility when you wire a U32, I64, or U64 though, but I'm pretty sure that the coercion won't hit harder than if Index Array (and similar) were polymorphic.

On FPGA the situation is dissimilar though, as the implementation of Index Array would use up less fabric with I8 instead of I32 as index. Depending on if this optimization is in place already, I'd hope the Xilinx compiler does not actually perform this coercion in the final bitfile though? It can be done statically as it is.

So all in all I don't think there should be any reason for making Index Array (nor the other index inputs) polymorphic?

The idea about fixed size arrays on other targets than FPGA is another thing though. I can see many places where that could help the compiler.

Cheers,

Steen

[P@Anand]

@crossrulz

Why not allow for the Unsigned Integers as well?

There is many cases where I use -1 as index to get empty string, so I thought it makes sense to use Signed Integers for index.

[P@Anand]

@Steen

Depending on if this optimization is in place already, I'd hope the Xilinx compiler does not actually perform this coercion in the final bitfile though? It can be done statically as it is.

I really don't know under the hood how Xilinx handles the Coercian (Would be happy if someone provide a link to understand). Taking Desktop as an example eventhough there is not much performance change, when we handle only an array of 10 elements (which is no way changing for example) and using a 32 integer made me write this idea. It made sense for me use what is only needed 🙂

[muks]

---

 It made sense for me use what is only needed

---

I agree with anand

[SteenSchmidt]

> Taking Desktop as an example eventhough there is not much performance change, when we handle only an

> array of 10 elements (which is no way changing for example) and using a 32 integer made me write this idea.

> It made sense for me use what is only needed

I agree that it makes sense to only use what is needed, but the least use of resources could very well be the current implementation. My point is that on Desktop you wouldn't gain much if anything by having a polymorphic Index Array (and all the other built-in functions with I32 index). NI would have to maintain and ship 9 to 15 functions (depending on number of supported data types) instead of 1 for each polymorphic method. That's a lot of extra work, for how much gain? Let's analyze it for Index Array;

I32 Index Array (the current implementation)

Everywhere you use Index Array in your app the same function will be used - only one Index Array on your disk in your LabVIEW install, only one Index Array in your executable, in your installer, and/or your source distribution. Depending on if the function in question is an NI VI or if it is in the runtime engine, the savings of one version over 9 or 15 will be in your own files or in the runtime engine.

And probably more important, this means only one Index Array function in memory. The moment you use just two functions (due to two different index data types being in use in your app), the savings in memory footprint you gained by having one of them I8 instead of I32 will be long gone.

How about performance then? As I wrote earlier, when you get a coercion dot for a smaller data type into a larger one, you'll have no actual coercion performed. If the compiler makes a memory copy or not will be impossible to predict except for the most trivial of cases, and it will rarely be affected by the data type and coercion dot anyway. For larger data types than I32 (U32, I64 and U64) there are other problems, namely that the arrays can't be this big currently anyway. In these cases it would be wise to investigate the coercion dot and being able to acknowledge certain coercion dots would come in handy.

I8 Index Array (the suggested implementation)

The above would mean all the drawbacks I've mentioned, and wouldn't mean better performance. Only in very few situations you would save a few bytes in memory, which really makes no difference on Desktop, especially taking into consideration all the possible situations where you'd use more memory.

So no performance gain, very very rare memory benefit (usual higher memory usage), and many more lines of code for NI to maintain and ship (at least until we get proper data type objects).

On FPGA it would be a different situation, but I think it is taken care of there already. If so that could be signalled in the IDE though.

/Steen

[JValdez]

---

On FPGA it would be a different situation, but I think it is taken care of there already.

---

This is largely true.  The Xilinx compiler should be very aggressive in removing unused signals, so, in principle, any address bits beyond that needed for the size of the array should be culled, particularly in the case of a coercion on the index terminal.  When coercing from I8 to I32, for example, the upper 24 bits will all just be a sign extension based on the 8th bit - Xilinx should have no problem recognizing that pattern and eliminating the extraneous bits.

For clarity's sake, there probably is some value to making the terminal polymorphic on FPGA since, in essence, you're already getting equivalent behavior in the coerced case. I think it's really just a question of priority along with the desire to be consistent across targets vs. the impact such a feature would have on other targets.

[AristosQueue (NI)]

Under the hood on RT and desktop targets, the index is used to take a pointer to an array and offset that pointer. That math has to be done in the pointer size of the platform, regardless of the fixed or unfixed size of the array. Given that, if your input is not a pointer-sized integer, there will be a coercion somewhere, so it seems right to reflect that on the diagram. Now, that math is done in the pointer size of the platform, so maybe the coercion dot should be based on whether or not the platform is 64-bit (or higher in the future), but LabVIEW generally has decided to make our source code environment independent of the underlying compilation environment.

I would be open to the idea that we should reflect coercion to a "pointer-sized integer" and then interpret "pointer-sized integer" as necessary for the compilation target. But "pointer-sized integer" as a data type is something that LV R&D discussed at least a couple times in the past (most recently for the refactoring of the Call Library Node) and has always rejected as adding too much complexity to our language environment for very little return. The argument against doing this is that the size of the array is still a 32-bit integer even on 64-bit platforms, so the comparison of the index vs the size is always done in 32 bits, even if the offset is eventually computed in 64 bits.

For those reasons, I lean toward leaving the Index Array (and similar primitives) exactly as they are today,