|
Post by Chris Iverson on Feb 4, 2021 12:54:00 GMT -5
This isn't an immediate request, but is something I think needs to be considered, ESPECIALLY with LB5 being 64-bit on some builds.
LB needs a 64-bit integer type, I think a pair like LONG/ULONG for 32-bit and SHORT/USHORT for 16-bit.
I'm finding more and more library code that assumes access to 64-bit integers. If it's a parameter to a function, or a struct, then it can be worked around by using 2 32-bit integers in it's place, but if a function returns a 64-bit value, then it's unusable from LB.
This wasn't much of a concern years ago, but as time goes on, like I said, 64-bit integers are becoming more common.
I actually ran into this myself when looking at embedding the Lua scripting language into an LB program just to see if I could. I had to make a custom build of Lua to do so, as the available binaries default to a 64-bit integer, which becomes unusable in LB.
And with 64-bit LB5 builds, there is one case where 64-bit integers will be necessary: pointers. All pointers in 64-bit programs are going to be 64-bits wide, so interacting with anything that uses pointers in a 64-bit library is going to require being able to use 64-bit integers.
|
|
|
Post by Walt Decker on Feb 5, 2021 9:10:11 GMT -5
Speaking of pointers, it would be nice if LB5 has "real" pointer variables for both code and data.
|
|
|
Post by Carl Gundel on Feb 5, 2021 9:47:00 GMT -5
Speaking of pointers, it would be nice if LB5 has "real" pointer variables for both code and data. Perhaps you would like to be more precise in what you mean by this? Liberty BASIC is not C, and variables do not hold a fixed position in memory. They often move during garbage collection. EDIT: Give me an example of how code would look for your desired use of "real" pointer variables. Thanks.
|
|
|
Post by Walt Decker on Feb 5, 2021 12:16:31 GMT -5
Mr. Gundel:
I know that LB is not C or assembler. However, I doubt the tokenizer and runtime engine are written in LB.
I know data moves around. However if there is a function that retrieves its address and that address is used immediately it is valid. That is true for numeric arrays as well. With variable lenth strings the address is still there and the data after it is moved. The same goes with variable lenth string arrays. A great deal depends on data alignment. I suspect that numerics are dword(ULONG) aligned whereas strings are byte aligned.
VARIABLE POINTERS:
Since in LB4x one cannot declare an array as GLOBAL and cannot pass an array to a SUB/FUNCTION. (You may have changed that in LB5; if so the below is mute.)
Vptr = VARBPTR(MyArray(0)) = address of sixth element of MyArray Sptr = VARBPTR(StrAry$(0)) = address of fourth element of StrAry$ (perhaps STRGPTR would be better).
FUNCTION DO.IT(Vptr, Sptr, Velms, Selms)
DIM Aptr AS LONG POINTER or PTR DIM Astr AS STRING POINTER or PTR
FOR I = 0 TO Velms Aptr = I + 10 Aptr = Aptr + 4 '<--- increase the address NEXT I
FOR I = 0 TO Selms Mstr$ = TRIM$(STR$(I + 10)) Astr = Mstr$ Astr = Astr + LEN(Mstr$) '<--- increase the address NEXT I
END SUB
Vptr = VARBPTR(SomeVarb) = address of SomeVarb Sptr = VARBPTR(MyStr$) = address of MyStr$ Vptr = VARBPTR(MyArray(5)) = address of sixth element of MyArray Sptr = VARBPTR(StrAry$(3)) = address of fourth element of StrAry$
"SomeFunc" is looking for a pointer to a variable so it can change its value. In LB4x one can only pass a numeric variable via a structure, speaking of which a structure should be a template, not a variable.
CALLDLL #FN, "SomeFunc", Vptr AS ULONG, RetVal AS VOID or CALLDLL #FN, "SomeFunc", Sptr AS ULONG, RetVal AS VOID
The code pointer I retract. LB is simply not fast enough to accomplish what I had in mind.
I admit I am not a compiler person, just an old, broken down, forgetfull engineering geologist. In the 8 bit days I did write a compiler in assembler and have not done it since.
|
|
|
Post by Carl Gundel on Feb 5, 2021 12:25:03 GMT -5
Mr. Gundel: I know that LB is not C or assembler. However, I doubt the tokenizer and runtime engine are written in LB. I know data moves around. However if there is a function that retrieves its address and that address is used immediately it is valid. That is true for numeric arrays as well. With variable lenth strings the address is still there and the data after it is moved. The same goes with variable lenth string arrays. A great deal depends on data alignment. I suspect that numerics are dword(ULONG) aligned whereas strings are byte aligned. Liberty BASIC is not written in C or assembler, or any similar language. It is written in Smalltalk which doesn't do things under the covers like procedural languages do. I very well may be able to give you pointers to numeric variables or even to arrays, but this will have to be done by literally creating C style versions of everything in non-LB memory, then passing a pointer to the call, and copying everything back again. Not sure what a code pointer is, but I'll take your word for it. No problem. There many ways to build compilers, interpreters, etc. What sort of compiler did you write? Was it a version of BASIC or something else? -Carl
|
|
|
Post by Carl Gundel on Feb 5, 2021 12:27:14 GMT -5
This isn't an immediate request, but is something I think needs to be considered, ESPECIALLY with LB5 being 64-bit on some builds. LB needs a 64-bit integer type, I think a pair like LONG/ULONG for 32-bit and SHORT/USHORT for 16-bit. Yes, of course this will be provided.
|
|
|
Post by Chris Iverson on Feb 5, 2021 13:05:00 GMT -5
Just throwing this out there, since I don't know how well this would work from an implementation point of view.
How difficult would it be to have arbitrarily-sized integers? Like, a specifier that indicates how many bits? I'm thinking something like instead of short/ushort, long/ulong, we get something like i<bits> for signed ints, and u<bits> for unsigned ints.
Like i8/u8, i16/u16, i32/u32, i64/u64.
That way, we could change bitsizes any time we need to, without needing to rebuild LB.
|
|
|
Post by Walt Decker on Feb 5, 2021 14:20:54 GMT -5
I know nothing about Smalltalk; however, unless it is open source I bet it does a great deal "under the hood."
Why not allow arrays to be global or allow passing arrays to subs/functions? That, I imagine, would be easier and take care of one (IMHO big) problem.
A code pointer is the address of a predefined method in code or a predefined label in code. For example, when registering a class one of the parameters windows requires is a pointer to a predefined callback module. With your CALLBACK function (which I had forgotten when I mentioned code pointers) you are supplying a code pointer to a predefined method to which a dll can supply information. You do not have to supply the arguments, just the address; however, the function must conform to the requirements of the dll otherwise a GPF will occur.
Well, that was 40+ years ago. It was a form of BASIC. It worked pretty well. I was able to compile individual modules then extract code modules from the main module and replace the code space with another compiled module. Back then code space was at a premium.
|
|
|
Post by tsh73 on Feb 5, 2021 14:35:34 GMT -5
all arrays ARE GLOBAL in LB. And they could not be passed to subs/functions (and it's a pity).
|
|
|
Post by Walt Decker on Feb 5, 2021 14:59:25 GMT -5
Then why, when I try to access an initialized populated array in a sub/function, do I get any error?
|
|
|
Post by Chris Iverson on Feb 5, 2021 15:17:43 GMT -5
I don't know why you'd be getting an error; he's quite correct that arrays are global.
dim testArray(20)
for x = 1 to 20 testArray(x) = x * x next x
a = printArray() end
Function printArray() for x = 1 to 20 print testArray(x) next x End Function
|
|
|
Post by Rod on Feb 5, 2021 15:46:09 GMT -5
What error Walt? Arrays are global, they are easily accessed from within a sub or function. Couple of things may catch folks out. Firstly the code has to actually pass over the dim statement. No good declaring it in a sub yet to be called. Second but less likely for yourself is that the array(index,index) index is not global and needs passed or created. Lastly typos, case sensitive array names.
|
|
|
Post by Walt Decker on Feb 5, 2021 17:49:04 GMT -5
I do not remember. I will have to play a little to duplicate the error.
I do know that I could not find the scope of arrays in the LB PRO help.
|
|
|
Post by Chris Iverson on Feb 5, 2021 18:48:25 GMT -5
Hmm, giving a quick look over everything, it does seem like arrays being global in scope is not mentioned in the helpfile in the sections relating to arrays.
The scope info IS mentioned in various sections relating to Functions and Subroutines, but not arrays directly, so you wouldn't have found that info unless you were reading up on subs/functions at the same time.
|
|
|
Post by Walt Decker on Feb 6, 2021 9:28:59 GMT -5
When I was figuring out how to create multiple instances of a control without having to give each a name. I first declared an array and tried passing it to a sub byref. That did not work. Tried passing individual elements to a function, e. g. A = SomeFunc(byref B(I)). That worked except the array was not filled. Looked in help for GLOBAL and the only item mentioned were individual variables. Looked under arrays and it mentioned nothing about how to create a global array. Also said nothing about arrays being global. So I assumed that arrays could not be made global and were not global.
Are arrays declared in a sub/function local to that sub/function?
|
|