Memory corruption (Bugs 1.25 Beta) (*solved*)

[britlion]

* Local array issues:
I noticed that a table I had in a subroutine wasn't returning the correct values. Finally pinned down a short program that demonstrates this:
(Both printed lines should be the same)

Code:

SUB failing(a as ubyte,b as ubyte, c as byte, d as byte, text as string)
DIM table2(25) as uByte => {18,24,16,14,14,12,20,12,12,16,14,6,12,10,18,14,26,18,24,8,12,24,12,26,18,10}
print table2(0);" ";table2(1)
end sub

sub working()
DIM table(25) as uByte => {18,24,16,14,14,12,20,12,12,16,14,6,12,10,18,14,26,18,24,8,12,24,12,26,18,10}
print table(0);" ";table(1)
end sub

cls
working()
failing(1,2,3,4,"A")

Interestingly if you swap the order that the two subs are in, which one breaks swaps too - it's the first one defined that breaks each time.

[boriel]

* Local array issues:
I noticed that a table I had in a subroutine wasn't returning the correct values. Finally pinned down a short program that demonstrates this:
(Both printed lines should be the same)

[...]

Interestingly if you swap the order that the two subs are in, which one breaks swaps too - it's the first one defined that breaks each time.

Yes, another bug. If you define failing(...) with no params (like working), the program runs as expected:

Code:

SUB failing()
DIM table2(25) as uByte => {18,24,16,14,14,12,20,12,12,16,14,6,12,10,18,14,26,18,24,8,12,24,12,26,18,10}
print table2(0);" ";table2(1)
end sub

sub working()
DIM table(25) as uByte => {18,24,16,14,14,12,20,12,12,16,14,6,12,10,18,14,26,18,24,8,12,24,12,26,18,10}
print table(0);" ";table(1)
end sub

cls
working()
failing()

The above runs ok, so yes, another bug. This one is very important (critical), because it is affecting the stack.
There's some parameter/stack corruption. I'm fixing it. On the other hand thes bug might be related to others where funcion calls behave unexpectedly.

[boriel]

Ok, I have found and fixed this bug. This bug was causing *severe* memory corruption :!: and might in fact be related to other bugs.
Please, download 1.2.5Beta 3 from here: <!-- m --><a class="postlink" href="http://www.boriel.com/files/zxb/zxbasic-1.2.5beta3.msi">http://www.boriel.com/files/zxb/zxbasic-1.2.5beta3.msi</a><!-- m --> Install it and test it.

I might suggest you use this version to test *all* bugs, and discard what are already fixed. To upgrade to a new compiler version, just launch the .msi (you needn't remove previous version, it will be done for you).

On the other, if you are placing your library .bas files in the /ZX BASIC/library dir, I think it is not a good idea. Better place your library files within your local source code until the file is included in the compiler library (e.g. fast fixed math library).

[britlion]

I'm testing with the new one now. We'll see what falls out.

I suppose that might just answer the question I had about function calls - that extra weird thing on the stack....it wasn't supposed to be there, was it?

Which means, my 42 char print routine, which compensated for it....probably breaks badly now.

[boriel]

I'm testing with the new one now. We'll see what falls out.

I suppose that might just answer the question I had about function calls - that extra weird thing on the stack....it wasn't supposed to be there, was it?

Which means, my 42 char print routine, which compensated for it....probably breaks badly now.

Check you have the current latest version 1.2.5r1489: <!-- m --><a class="postlink" href="http://www.boriel.com/files/zxb/zxbasic-1.2.5r1489.msi">http://www.boriel.com/files/zxb/zxbasic-1.2.5r1489.msi</a><!-- m -->
On the other hand, one the compiler is stable again, we could add your routines to it, if you like. :roll:

[britlion]

So far, it's looking good.

I've updated the buglist, and it's almost all green now.

The more I think about it, the more I'm thinking that if you make the "library list" page in the wiki, that it would be as well to put any additions in there. Then people can use them as and when they will, and they are better documented. We could add a standard set - I'm working my way towards a math library, for example - into the pile, but the wiki section will be at least as important, since it documents what all this stuff does. On more than one occasion I've found myself writing code that would be as easy to do with an import from the library that's already there.

One problem with things like the math library is are people looking for speed or size? Often it's a trade between the two. You either get big, or slow - or something in between. It might be easier to have a fully documented method or two there, and explain how it came about and then people can choose to spend bytes or not by modifying the routines.

[LCD]

A compiler directive like -fast or -small could help.

[boriel]

A compiler directive like -fast or -small could help.

Another option is to use a define, like -Dfast-math for example, and make the content of .asm files conditional to that define.

Code:

#ifdef fast-math

#else

#endif

Or simply, when using something like --fast-floating-point or the like, just define such tag internally.

[britlion]

And if we're going to do that we need fast floating point routines for all the math functions.

I've been focusing on integer stuff - figuring that very fast, but inaccurate whole-number solutions will be fine for games playing. Things like wireframe vectors are going to need fast sin/cos/tan/sqrt.

We might need a fast log function too.

Can we find or write fast assembler for all this? Maybe. Not sure. We might have to dig into todos to do it. And between you and me, I'm not an awesome assembler writer.

Ahem. Right now I have a sqr(long) routine that...gets it right about 60% of the time. And my head's hurting trying to find out why! The 16 bit version was a lot easier to cope with than the 32 bit version. Working with numbers bigger than 16 bits is really a pain! (For those that don't know, the z80 processor can deal with 16 bit numbers internally pretty well. 32 bit means holding it in 2 16 bit registers and manually dealing with how one affects the other each time you change it. So even long=long+1 takes a lot more steps than integer=integer+1 !)

EDIT: Fixed it and posted the routine over in the help and tutorials section.