What programming languages does support VLAs?
I mean what programming languages out there support C-like VLAs (which are stored on the stack rather than the heap), other than C itself?
As you probably don't know VLA stand for a variable-length-array which is defined in 'C' in a way that most compilers will store them onto the 'stack' (instead of how most modern languages instead use the 'heap'). In case you do however I'll be glad if you help me to find non-100 years old, legacy carrying languages that meet this requirement.
There's a fairly good overview on staskoverflow as to why VLAs are very problematic in practice.
What problem do you want to solve using VLAs?
And besides 'C++' too. I already knew that one.
C++ actually doesn't support them as a language feature. It's an area where C99 and C++03 actually diverged from each other.
I use them in C++ by implementing my own scopes and stacks that are separate from the language's default call-stack and block scopes.
They're especially a hassle to optimize at the assembly level. Normally if all local variables are fixed size, their stack offsets are constant and can be kept directly in instruction operands. The compiler can also optimize out the frame pointer because it can control and deterministically know where the stack pointer is moving throughout the entire function because everything pushed or popped has constant sizes.
When you have VLA's... you can still reserve fixed locations for fixed size stuff, but a VLA wrecks the compiler's knowledge of anything on the stack afterwards, and you can no longer optimize out the frame pointer (since the stack pointer now has an offset from the frame pointer that can't be known at compile time). When you index a VLA, the compiler has to make a dereference relative to the start of the VLA. Since the stack almost always grows towards negative addresses, this means the start offset (even for the single-VLA case) is dynamic and has to be stored somewhere. The obvious implementation counts the number of VLAs a function uses and reserves extra fixed-position pointers on the stack to keep track of where the VLAs end up. It can deterministically figure out the position of *one* VLA the same way that normal frame pointer omission works, but after the first you need to have pointers. Manipulating any VLAs after the first then requires additional loading of those pointers off the stack or keeping them in registers (as opposed to the optimal method of baking the offsets into operands), leading to an extra dereference and more register thrash (which is worse since you're also forced to keep your frame pointer).
Static analyzers that warn you about array indices being out of range have two dynamic things to track (dynamic length, dynamic index) instead of one (static length, dynamic index).
It's pretty gross and leads to a bunch of extra instructions to deal with it. I avoid VLAs and alloca at all costs.
When you have VLA's... you can still reserve fixed locations for fixed size stuff, but a VLA wrecks the compiler's knowledge of anything on the stack afterwards, and you can no longer optimize out the frame pointer (since the stack pointer now has an offset from the frame pointer that can't be known at compile time). When you index a VLA, the compiler has to make a dereference relative to the start of the VLA. Since the stack almost always grows towards negative addresses, this means the start offset (even for the single-VLA case) is dynamic and has to be stored somewhere. The obvious implementation counts the number of VLAs a function uses and reserves extra fixed-position pointers on the stack to keep track of where the VLAs end up. It can deterministically figure out the position of *one* VLA the same way that normal frame pointer omission works, but after the first you need to have pointers. Manipulating any VLAs after the first then requires additional loading of those pointers off the stack or keeping them in registers (as opposed to the optimal method of baking the offsets into operands), leading to an extra dereference and more register thrash (which is worse since you're also forced to keep your frame pointer).
Static analyzers that warn you about array indices being out of range have two dynamic things to track (dynamic length, dynamic index) instead of one (static length, dynamic index).
It's pretty gross and leads to a bunch of extra instructions to deal with it. I avoid VLAs and alloca at all costs.
I already know how VLAs are represented. And I still like them. It's my own personal opinion. However my problem is that I can't find any good-languages (besides C/C++ and the ones listed on the Wiki-Page describing what VLA is) that supports them (I mean proper by default support, without for example the need of calling a function like 'alloca').
And also in a matter of fact - VLAs are very useful as you have already pointed out when there you've used only a single such variable. Because in such cases they are created faster then calling for example 'malloc'. Another thing is as you probably know newer 64bit processors have a lot more registers then 32bit ones so I'm sure that even using more then a single VLA can be optimized and work faster then 'heap'.
IIRC, some C compilers implement VLAs using malloc/free. Not sure where we encountered it, but my guess is some vendor supplied compiler for one of those non-arm microcontroller architectures.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement