Array Descriptor (split from Wiki Improvements)

Forum for discussion about the documentation project.
fxm
Posts: 9123
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Array Descriptor (split from Wiki Improvements)

Postby fxm » Aug 23, 2019 7:32

coderJeff wrote:
speedfixer wrote:Does this mean that all arrays will have descriptors, exposed and available, in this future version?

david

Yes, that is the intent.

For those who want to test all this, download at http://users.freebasic-portal.de/stw/builds/:
- last fbc build
- and freebasic_additional_headers.zip
MrSwiss
Posts: 3220
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Array Descriptor (split from Wiki Improvements)

Postby MrSwiss » Aug 23, 2019 10:18

coderJeff wrote:Yes, I read through the code for your proposed additions. From your code and other comments in this topic, the "flags" field is looking like the following (so far):

Code: Select all

enum FBARRAY_FLAGS
   FBARRAY_FLAGS_DIMENSIONS = &h0000000f      '' number of entries allocated in dimTb()
   FBARRAY_FLAGS_STATIC     = &h00000010      '' array points to static/fixed-length memory
   FBARRAY_FLAGS_ATTACHED   = &h00000020      '' array points to memory managed by another descriptor
   FBARRAY_FLAGS_LOCKED     = &h00000040      '' array in use: do not allow redim/erase
   FBARRAY_FLAGS_RESERVED   = &hffffff80      '' reserved, do not use
end enum
Sorry, but this is only good for FBC 32 bit ... not so, for FBC 64 bit!
Except the "bitfield" (aka: flags) is of a fixed size: ULong (not UInteger).

I haven't come across any language, that uses a "dynamic" variable for: "bitfield".
For practical reasons, they're usually: "hard coded".
Juergen Kuehlwein
Posts: 210
Joined: Mar 07, 2018 13:59
Location: Germany

Re: Array Descriptor (split from Wiki Improvements)

Postby Juergen Kuehlwein » Aug 23, 2019 10:55

Static - dynamic:

to my understanding a static (fixed size) array´s descriptor must not be changed at runtime. That is number of dimensions and number of elements must be static. You must not be allowed to redim or erase such an array. This allows for compile time optimization. A dynamic array currently gets s assigned room for a maximum of 8 dimensions, which might be a waste of space, because most of times it will use less dimensions. On the other hand this is a requirement for an unrestricted redim and i think it should stay this way.

The only reason the RTL prevents adding dimensions to a dynamic array at a redim, is that it cannot decide, if it´s a static or a dynamic array, which is to be redimmed. So in order not to corrupt memory or produce a GPF by accessing memory (added dimensions), which hasn´t been allocated for this purpose, it just forbids it.

Conclusion:
As soon as we can decide (in the RTL) between static and dynamic arrays, this restriction could and should be dropped.

I don´t think a locked flag makes sense. This would require an object like reference count in procedural code. It would make sense only for array object.


JK
fxm
Posts: 9123
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Array Descriptor (split from Wiki Improvements)

Postby fxm » Aug 23, 2019 11:39

MrSwiss wrote:Sorry, but this is only good for FBC 32 bit ... not so, for FBC 64 bit!
Except the "bitfield" (aka: flags) is of a fixed size: ULong (not UInteger).

No problem for me.
Post us code where it does not work for 64-bit.
MrSwiss
Posts: 3220
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Array Descriptor (split from Wiki Improvements)

Postby MrSwiss » Aug 23, 2019 11:52

Code: Select all

#Ifndef __FB_64BIT__
enum FBARRAY_FLAGS
   FBARRAY_FLAGS_DIMENSIONS = &h0000000f      '' number of entries allocated in dimTb()
   FBARRAY_FLAGS_STATIC     = &h00000010      '' array points to static/fixed-length memory
   FBARRAY_FLAGS_ATTACHED   = &h00000020      '' array points to memory managed by another descriptor
   FBARRAY_FLAGS_LOCKED     = &h00000040      '' array in use: do not allow redim/erase
   FBARRAY_FLAGS_RESERVED   = &hffffff80      '' reserved, do not use
end Enum
#Else
enum FBARRAY_FLAGS
   FBARRAY_FLAGS_DIMENSIONS = &h000000000000000f      '' number of entries allocated in dimTb()
   FBARRAY_FLAGS_STATIC     = &h0000000000000010      '' array points to static/fixed-length memory
   FBARRAY_FLAGS_ATTACHED   = &h0000000000000020      '' array points to memory managed by another descriptor
   FBARRAY_FLAGS_LOCKED     = &h0000000000000040      '' array in use: do not allow redim/erase
   FBARRAY_FLAGS_RESERVED   = &hFFFFFFFFffffff80      '' reserved, do not use
end Enum
#EndIf
Should be obvious, that the bit_masks, need extensions for FBC 64.
fxm
Posts: 9123
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Array Descriptor (split from Wiki Improvements)

Postby fxm » Aug 23, 2019 12:02

Juergen Kuehlwein wrote:Static - dynamic:

to my understanding a static (fixed size) array´s descriptor must not be changed at runtime. That is number of dimensions and number of elements must be static. You must not be allowed to redim or erase such an array.

Just a little brightening;
Using the future 'static' flag, ERASE will can apply to both fix-len and var-len arrays passed as arguments to a procedure:
- For a fix-len array, the array elements are only reinitialized.
- For a var-len array, the array elements are fully destroyed (data memory deallocated) and the array descriptor is reinitialized (only 'element_len' and 'dimensions' values are presently kept).
This will be the same capability than in the main code.
fxm
Posts: 9123
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Array Descriptor (split from Wiki Improvements)

Postby fxm » Aug 23, 2019 12:05

fxm wrote:Post us code where it does not work for 64-bit.

MrSwiss wrote:Should be obvious, that the bit_masks, need extensions for FBC 64.

You have not responded to my specific request.
MrSwiss
Posts: 3220
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Array Descriptor (split from Wiki Improvements)

Postby MrSwiss » Aug 23, 2019 12:11

fxm wrote:You have not responded to my specific request.
I won't, like you do ... (just stating it honestly, as a difference).
coderJeff
Site Admin
Posts: 3018
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Array Descriptor (split from Wiki Improvements)

Postby coderJeff » Aug 23, 2019 12:38

MrSwiss wrote:Sorry, but this is only good for FBC 32 bit ... not so, for FBC 64 bit!
Except the "bitfield" (aka: flags) is of a fixed size: ULong (not UInteger).


new flags field will be UINTEGER which will be same size as cpu's native word size. True this size could be 32 or 64 bits, but we only ever use lower 32 bits. Using U|INTEGER maintains the overall native word sized alignment and access of the array descriptor structure as a whole and is at least as portable as any other field in the structure.
coderJeff
Site Admin
Posts: 3018
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Array Descriptor (split from Wiki Improvements)

Postby coderJeff » Aug 23, 2019 12:55

Juergen Kuehlwein wrote:Static - dynamic:

to my understanding a static (fixed size) array´s descriptor must not be changed at runtime. That is number of dimensions and number of elements must be static. You must not be allowed to redim or erase such an array. This allows for compile time optimization. A dynamic array currently gets s assigned room for a maximum of 8 dimensions, which might be a waste of space, because most of times it will use less dimensions. On the other hand this is a requirement for an unrestricted redim and i think it should stay this way.

I had debated (with myself) over using "static" or "fixed". I originally selected "static", feeling it was opposite to "dynamic". After reading your understanding, I am thinking "fixed-length", and "variable-length", as fxm uses might be clearer. So I'm going to use FBARRAY_FLAGS_FIXED as the symbol name. Your understanding here seems OK.

The only reason the RTL prevents adding dimensions to a dynamic array at a redim, is that it cannot decide, if it´s a static or a dynamic array, which is to be redimmed. So in order not to corrupt memory or produce a GPF by accessing memory (added dimensions), which hasn´t been allocated for this purpose, it just forbids it.

This isn't quite correct. RTL allows unrestricted REDIM first time only. After which, the number of dimensions is fixed from then on for the duration of program execution (but array bounds can still change on redim). Part of this restriction is likely due that the original number of entries available in the dimTb() table is lost. More on this later after fxm's comment.
coderJeff
Site Admin
Posts: 3018
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Array Descriptor (split from Wiki Improvements)

Postby coderJeff » Aug 23, 2019 13:09

fxm wrote:
Juergen Kuehlwein wrote:Static - dynamic:

to my understanding a static (fixed size) array´s descriptor must not be changed at runtime. That is number of dimensions and number of elements must be static. You must not be allowed to redim or erase such an array.

Just a little brightening;
Using the future 'static' flag, ERASE will can apply to both fix-len and var-len arrays passed as arguments to a procedure:
- For a fix-len array, the array elements are only reinitialized.
- For a var-len array, the array elements are fully destroyed (data memory deallocated) and the array descriptor is reinitialized (only 'element_len' and 'dimensions' values are presently kept).
This will be the same capability than in the main code.


I like your use of "fix-len" and "var-len" for clarity.

Expanding on your point about "only 'element_len' and 'dimensions' values are presently kept". I think 'element_len' must always be set. Is there ever a time when it would be zero (0)?

What do you think about resetting dimensions too, after ERASE? Good programming practices aside:

Code: Select all

sub proc1( a() as integer )
   erase a
   redim a(1 to 2)
end sub

sub proc2( a() as integer )
   erase a
   redim a(1 to 2, 3 to 4)
end sub

dim a() as integer
proc1()
proc2()


The illegal function call due to wrong number of dimensions depends on which procedure is called first and second.
Juergen Kuehlwein
Posts: 210
Joined: Mar 07, 2018 13:59
Location: Germany

Re: Array Descriptor (split from Wiki Improvements)

Postby Juergen Kuehlwein » Aug 23, 2019 13:12

You must not be allowed to redim or erase such an array

Fxm is right! "Erase" could be misinterpreted in this context. I meant "erase" in a sense of deallocating memory.

Thinking about it, the FBARRAY_FLAGS_DIMENSIONS member might be obsolete, as soon as we can decide between static and dynamic arrays. The already available dimensions member of the descriptor holds the same information. For a static array, this value must not be changed, for a dynamic array it could be reset to whatever is specified by redim (or set to zero again for "ERASE"), because we have room for 8 dimensions anyway.

I don´t see a problem with uinteger for the bitfield either. For masking out the flags (the lower 32 bit in 64 bit) you can use the same code. The masks for valid members will be zero expanded automatically, and all others are "reserved" (reserved, do not use).


JK
Juergen Kuehlwein
Posts: 210
Joined: Mar 07, 2018 13:59
Location: Germany

Re: Array Descriptor (split from Wiki Improvements)

Postby Juergen Kuehlwein » Aug 23, 2019 13:17

@Jeff,

we cross posted.
What do you think about resetting dimensions too, after ERASE?

exactly what i mean. You don´t even need "ERASE" beforehand, "REDIM" (with an implicit ERASE, if the array is already dimmed) would do (for dynamic or "var-len" arrays).


JK
fxm
Posts: 9123
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Array Descriptor (split from Wiki Improvements)

Postby fxm » Aug 23, 2019 13:29

Juergen Kuehlwein wrote:Thinking about it, the FBARRAY_FLAGS_DIMENSIONS member might be obsolete, as soon as we can decide between static and dynamic arrays. The already available dimensions member of the descriptor holds the same information. For a static array, this value must not be changed, for a dynamic array it could be reset to whatever is specified by redim (or set to zero again for "ERASE"), because we have room for 8 dimensions anyway.

Except if one want to keep the present possibility to declare (at first time declaration) a var-len array but fixing the number of dimensions (may become the maximum number of dimensions for this array so declared at the first time):
- 'As datatype array(Any, ...)' (where the allocated descriptor is sized depending on the number of 'Any' declared),
- 'Redim As datatype array(bounds values)' (where the allocated descriptor is sized depending on the number of dimensions declared through the 'bounds values').
Juergen Kuehlwein
Posts: 210
Joined: Mar 07, 2018 13:59
Location: Germany

Re: Array Descriptor (split from Wiki Improvements)

Postby Juergen Kuehlwein » Aug 23, 2019 14:25

Or treat this kind of hybrid declaration (fixed number of dimensions, but variable number of elements) as a third variation of arrays (fix-len, var-len, fix-dim (?)) and reserve a flag bit for it.


JK

Return to “Documentation”

Who is online

Users browsing this forum: No registered users and 1 guest