INTYBASIC 1.2 problems

[artrag]

Yes the problem is in the label generation of intybasic

[artrag]

here another test.bas with problems in generating labels with intybasic version 1.2

test.bas

Edited August 13, 2015 by artrag

[First Spear]

These are great finds. I do have an issue with the thread title though. We all do this but in the end it hurts the ability of everyone to find out about problems or help with fixes. If this thread was called "IntyBASIC Variable Problem" or something, that would go a lot further in helping people with problems now and if anyone hits a similar issue in the future.

[artrag]

Thread renamed

Btw to return to the array matter, I was thinking that being able to allocate arrays at given locations could be used also to reuse the same room for different arrays to be used at different times.

Assume you want dim a(10,10) as side information to generate a level and than you need dim b(50) for the ai of enemies...

You could allocate them in the same ram region counting on the fact they are used at different times

[+DZ-Jay]

Thread renamed

Btw to return to the array matter, I was thinking that being able to allocate arrays at given locations could be used also to reuse the same room for different arrays to be used at different times.

Assume you want dim a(10,10) as side information to generate a level and than you need dim b(50) for the ai of enemies...

You could allocate them in the same ram region counting on the fact they are used at different times

You leff a typppo in teh tiltle.

[+DZ-Jay]

Thread renamed

Btw to return to the array matter, I was thinking that being able to allocate arrays at given locations could be used also to reuse the same room for different arrays to be used at different times.

Assume you want dim a(10,10) as side information to generate a level and than you need dim b(50) for the ai of enemies...

You could allocate them in the same ram region counting on the fact they are used at different times

What you are asking is some sort of way to "deallocate" memory. I don't think old-school BASIC ever had that feature, except for perhaps localized or lexical variables.

 

I believe that is something Oscar may be planning for a future release.

[artrag]

No allocate and deallocate variables needs heap management. What I suggestis by far simpler and if you know what you are doing equally efficient

[artrag]

You leff a typppo in teh tiltle.

Fixed !thx! Edited August 14, 2015 by artrag

[+DZ-Jay]

No allocate and deallocate variables needs heap management. What I suggestis by far simpler and if you know what you are doing equally efficient

If I understand what you are asking, it's far more dangerous than its worth.

 

Being able to overlap memory structures such as arrays is not something I would recommend to add to a BASIC compiler. I can see that inviting unwarranted trouble.

 

If you know what you are doing, why lot define a large array and create some DEF FN macros to access sections of it using Assembly Language of PEEKs?

[artrag]

C also has unions.

IMHO the closer you stay to the hardware the better it is.

And if you do not want to allocate arrays at a given position you do not have to.

Edited August 14, 2015 by artrag

[GroovyBee]

I agree with DZ-Jay. Using DEF FN to access the elements in your multi-purpose array is the best way.

[GroovyBee]

IMHO the closer you stay to the hardware the better it is.

As I mentioned here, there is little difference between accessing an array and using DEF FN with a PEEK/POKE to get what you want. IntyBASIC already gets you very close to the hardware.

[artrag]

Not for overlapping arrays.

Stretching your reasoning one could conclude that variables and arrays are not needed, as you can use directly ram locations using peek and poke.

Edited August 14, 2015 by artrag

[+DZ-Jay]

C also has unions.

IMHO the closer you stay to the hardware the better it is.

And if you do not want to allocate arrays at a given position you do not have to.

C is most definitely not BASIC.

 

And, like GroovyBee said, IntyBASIC lets you keep close to the metal. The "ASM" directive and the macros allow you to do bespoke low-level work without having to pollute the language with functionality to support esoteric use cases.

 

dZ.

[+DZ-Jay]

Not for overlapping arrays.

Stretching your reasoning one could conclude that variables and arrays are not needed, as you can use directly ram locations using peek and poke.

 

What you don't seem to appreciate is that variables and arrays address some extremely common use cases and allow for working at a higher cognitive level. There is a reason why integers, floats, strings, etc. have been adopted by many BASIC dialects, while pointers and unions, not so much.

[GroovyBee]

Not for overlapping arrays.

Stretching your reasoning one could conclude that variables and arrays are not needed, as you can use directly ram locations using peek and poke.

I just coded this as a simple test :-

 

INCLUDE "constants.bas"

DIM BIG(100)
DEF FN LEVEL(aColumn,aRow) = BIG((aRow*10)+(aColumn))
DEF FN ENEMYX(anIndex) = BIG(6+(anIndex))

LEVEL(1,1)=33		' 2 CPU instructions.
what=LEVEL(1,1)		' 2 CPU instructions.
ENEMYX(1)=20		' 2 CPU instructions.
ex=ENEMYX(1)		' 2 CPU instructions.

loop:
	WAIT
	GOTO loop

And the "overlapping arrays" execute as fast as possible using DEF FNs with constant parameters.

[artrag]

DIM A(100) AT $0200

DIM B(10) AT $0210



A(1) = 100



B(1) = 200

less effort for the coder and the compiler, same results and efficiency

 

[+DZ-Jay]

DIM A(100) AT $0200
DIM B(10) AT $0210

A(1) = 100

B(1) = 200

less effort for the coder and the compiler, same results and efficiency

 

 

And a scary nightmare for the newbie!

 

Also, "DIM" actually allocates memory by moving an internal cursor, which heretofore has been linear. The memory manager will need to be complicated to support such cases, and segment overflow will not be easy to detect.

 

All for a one-off or extremely rare case.

 

What you suggest could be addressed by something a "REDIM" directive; which rather than open ended, is a special purpose re-allocation of arrays. This probably would require arrays to be handled specially by the compiler, but the gains may be worth it since arrays have a tendency to take a rather large chunk of memory.

DIM A(100) ' Allocate array

    ' use array A here...


REDIM A(10) ' re-allocate array

    ' use a smaller version of array A here...

I deal with this sort of thing in my P-Machinery AGE framework, but with different semantics. It does tend to cause memory fragmentation, which needs to be handled specially.

 

In practice, the solutions are not easy to implement. In the meantime, I recommend something like what GroovyBee posted above.

 

-dZ.

Edited August 14, 2015 by DZ-Jay

[GroovyBee]

less effort for the coder

Not really. Its the same number of lines of BASIC code and my method works in IntyBASIC 1.2. When you place general purpose arrays at specific memory locations you have to know where the free RAM is. If you get it wrong you could corrupt other variables. The only array that makes sense at a specific location is one to access BACKTAB, perhaps nanochess can add a predefined array name for that. However, you can get around that limitation in the current version of IntyBASIC with DEF FNs too.

[GroovyBee]

What you suggest could be addressed by something a "REDIM" directive; which rather than open ended, is a special purpose re-allocation of arrays.

The problems with "REDIM" are :-

• There is no concept of garbage collection in IntyBASIC.
• Variables are not stored on the stack.

If the array is defined as 100 elements then it still takes the space of 100 elements even if you make it smaller. Variables are not placed on the stack but exist as physical locations in memory. Thus they cannot be moved around in an ad hoc manner.

 

If nanochess implements the concept of local variables, then in my mind, they would most likely be located at the end of SCRATCH/SYSTEM RAM and grow "downwards" towards the global variables. The compiler can then work out if global variables and local variable overlap and generate an appropriate error.

[+DZ-Jay]

The problems with "REDIM" are :-

• There is no concept of garbage collection in IntyBASIC.
• Variables are not stored on the stack.

If the array is defined as 100 elements then it still takes the space of 100 elements even if you make it smaller. Variables are not placed on the stack but exist as physical locations in memory. Thus they cannot be moved around in an ad hoc manner.

 

If nanochess implements the concept of local variables, then in my mind, they would most likely be located at the end of SCRATCH/SYSTEM RAM and grow "downwards" towards the global variables. The compiler can then work out if global variables and local variable overlap and generate an appropriate error.

Agreed. That or keep track of fragments, which is what I do in P-Machinery. The memory manager ensures that fragments are used first when allocating a new variable or memory block.

 

This mechanism allows for the support of overlapping RAM segments so that each game phase (title screen, game-play, menu, game-over, etc.) can have it's own memory space.

 

See here for more information.

http://atariage.com/forums/topic/218915-p-machinery-shared-ram-segment-blocks/

 

Anyway, I'm sure IntyBASIC can do better. I had the constraint of being limited to the Assembler's macro pre-processor.

 

dZ.

[artrag]

Sorry that you cannot see how different is implementing runtime memory management (please don't do heap management and garbage collection) from allowing at compile time to allocate a variable at a fixed position.

Anything could be safely solved by adding a symbol in the compiled asm. No need to make anything complex.

Variables with fixed positions do not affect the management of the others and you do not have to use them if you are a newbie (or if you have problems with them).

Edited August 15, 2015 by artrag

[freewheel]

Or you could simply re-use variable names given the appropriate context. The platform is nowhere near complicated enough that we need to engineer anything remotely close to C-isms just to accomodate the 2 programmers who even understand the use, let alone would ever bother using it. There are a ton of other more pressing things that need addressing in the language and compiler first. I haven't even tested 1.2 to find out what's broken this time due to feature creep (I kid, I kid!).

 

DZ and Groovybee are arguing quite well for my stance against over-complicating this language. Keep it up, boys.

[+DZ-Jay]

Sorry that you cannot see how different is implementing runtime memory management (please don't do heap management and garbage collection) from allowing at compile time to allocate a variable at a fixed position.

Anything could be safely solved by adding a symbol in the compiled asm. No need to make anything complex.

Variables with fixed positions do not affect the management of the others and you do not have to use them if you are a newbie (or if you have problems with them).

I don't think you read what I wrote. I am very much talking about static allocation during compile time.

 

What you are requesting is not possible if IntyBASIC abstracts the memory map (which it does). It also requires you having access to the actual addresses of variables, That should not be allowed as part of the language itself, but it is in fact possible using the macro and ASM extensions.

[artrag]

Add a label in the generated asm with the fixed address of the variable. That's it all.

As you said it is a feature of the assembler so supporting it from the compiler is effortless.

 

Developing the compiler is not up to you (nor to me) but to Oscar who will decide as he likes.

This discussion is drifting to idiotic contraposition of theories. For me the discussion ends here.