serious bug making long type data impossible

[kram]

whenever you try this:
dim test as long
test = 65536

you get a type mismatch, because "dim test as long" seems to create __LONG_test, but "test = 56636" seems to attempt to create __INTEGER_test and assign a long value to it, please fix this.

and one more thing:

this doesnt work either:
read bar
dim foo(bar)

stuff:
dataint 331

it would be nice if the above things could be fixed

oh, one more thing, arrays dimensioned like this would be nice:

dim a(3,4) as long
dim b(2,5,2) as integer

oh and we have THIS problem too:
a = $000FF520
creates both __INTEGER_a and __INTEGER_$000FF520 when clearly that is an attempt to assign a hex value to a variable, the easiest solution to the major bugs is this:

1. assign dimensions based on the type being put into the variable, and only use DIM for arrays

2. allow leading $ numbers to be immediate hex numbers and leading % numbers to be binary

and for making programming much easier:

3. allow up to 3 dimensional arrays, and dont say that such arrays are never used, I have encountered situations where I had to go with very redundant decisions because I could not do this scenereo:
dim item(x,y,levels) as integer. allowing multidimensional arrays frees up a lot of wasted space in code.

[uchuusen]

I noticed the same thing with long variables around when I started using BEX. The way around it is to just put a & at the end of the variable name. for example:

test& = 65536

This way works with no problems.

[Tom Maneiro]

Guest-kram said:

this doesnt work either:
read bar
dim foo(bar)

stuff:
dataint 331

Don't forget the "dim foo(bar) As INTEGER/LONG". You forgot the data type, and for arrays, it must be defined

Guest-kram said:

oh, one more thing, arrays dimensioned like this would be nice:

dim a(3,4) as long
dim b(2,5,2) as integer

these are ALREADY supported. But the bug there is that... there are no range checking. For example do this:
dim x(10) as integer
x(11)=454

it should generate a error, because we are attempting to assign a value to a nonexisting element (out of range)

But... this bug is only present with Integer arrays, with Long arrays, program refuses to compile. For example:
dim x(15) as long
print x(10)
-or-
dim z(54) as long
z(10)=8
this gives an "Arrays must be predimensioned!" error!

Also there is another nasty bug:
dim foo(8) as long
foo=8
print foo

this outputs 8, but should give an error (you cannot print an array identifier, since it does not have value, it is just an identifier, and not a variable with a value, the only terms that have value here are the array members)

Guest-kram said:

oh and we have THIS problem too:
a = $000FF520
creates both __INTEGER_a and __INTEGER_$000FF520 when clearly that is an attempt to assign a hex value to a variable, the easiest solution to the major bugs is this:

bug?

Guest-kram said:

1. assign dimensions based on the type being put into the variable, and only use DIM for arrays

emmm.. DIM should be used FOR EVERY VARIABLE ON YOUR PROGRAM, it's a correct programming technic: require variable declaration (does Option Explicit remember something?)

Guest-kram said:

2. allow leading $ numbers to be immediate hex numbers and leading % numbers to be binary

read teh docz

Guest-kram said:

and for making programming much easier:

3. allow up to 3 dimensional arrays, and dont say that such arrays are never used, I have encountered situations where I had to go with very redundant decisions because I could not do this scenereo:
dim item(x,y,levels) as integer. allowing multidimensional arrays frees up a lot of wasted space in code.

as i said: these are already supported, just try it!

[oompa loompa]

=D these are all good replies. it puts me in a state of mind of how the compiler should be like, and how it could better in the future making it even more simpler than it is now x.x

anyway, here's my responses

whenever you try this:
dim test as long
test = 65536

you get a type mismatch, because "dim test as long" seems to create __LONG_test, but "test = 56636" seems to attempt to create __INTEGER_test and assign a long value to it, please fix this.

the parser assumes that any variable that does not have a special character at the end to represent its data type (ie: $ for byte, % for integer, & for long), it will assume it is always an integer. this has been the classical basic approach to this

and one more thing:

this doesnt work either:
read bar
dim foo(bar)

stuff:
dataint 331

it would be nice if the above things could be fixed

this is one dawnfall of the compiler: variables cannot be allocated dynamically, they have to be and only can be static. unfortunately, the compiler uses absolute indirect addressing modes to access variables, which is bad. in the future, i will be using indexed addressing since it will allow variables to be dimensioned dynamically, and will also allow variable scopes for subs/functions

oh, one more thing, arrays dimensioned like this would be nice:

dim a(3,4) as long
dim b(2,5,2) as integer

sorry, multi-dimensioned arrays are unsupported

i've seen a lot of requests for multi-dimension support, i'll try to add this in the c version, but for now, its not going to happen

oh and we have THIS problem too:
a = $000FF520
creates both __INTEGER_a and __INTEGER_$000FF520 when clearly that is an attempt to assign a hex value to a variable, the easiest solution to the major bugs is this:

use &h12345678 for hexidecimal numbers. binary numbers are unsupported. i will try to add $ and % (although they heavily conflict with byte+integer, but it can be fixed) to the c version

edit: forgot to add that if the parser see anything that is not a numeral (0,1,2,3....) at the fetch of an operator, it will think it is a veriable, regardless of what symbol is used at the begining

1. assign dimensions based on the type being put into the variable, and only use DIM for arrays

the visual basic approach to variants is slow and unnecessary for just an 8mhz cpu. all variables must have their type symbol attatched to it, unless it is an integer

and for making programming much easier:

3. allow up to 3 dimensional arrays, and dont say that such arrays are never used, I have encountered situations where I had to go with very redundant decisions because I could not do this scenereo:
dim item(x,y,levels) as integer. allowing multidimensional arrays frees up a lot of wasted space in code.

i know programmers love their multi-dimensional arrays, but the expression parser has already matured, and i can't add in multi-dimensional arrays without either having to butcher it up

Tom said:

these are ALREADY supported. But the bug there is that... there are no range checking. For example do this:
dim x(10) as integer
x(11)=454

it should generate a error, because we are attempting to assign a value to a nonexisting element (out of range)

bah, range checking's for noobs =P, it will slow down your code

Tom said:

But... this bug is only present with Integer arrays, with Long arrays, program refuses to compile. For example:
dim x(15) as long
print x(10)
-or-
dim z(54) as long
z(10)=8
this gives an "Arrays must be predimensioned!" error!

haha, you fell for the basiegaxorz rule: if a variable does not have an appropriate symbol at the end, it is assumed to be an integer data type

Tom said:

Also there is another nasty bug:
dim foo(8) as long
foo=8
print foo

this outputs 8, but should give an error (you cannot print an array identifier, since it does not have value, it is just an identifier, and not a variable with a value, the only terms that have value here are the array members)

this is because array variables and non-array variables both share the same names. i made it this way =D, so getting the first element of an array doesn't waste cpu time. for basiegaxorz, using an array on a variable is just a modifier of how the variable is addressed. obviously, its not vice-versa, like:

dim a as integer, b as integer
a(1)=123 ' if this were legal, you would be accessing variable b, but instead gives array not pre-dimmensioned

[GiGaBiTe]

make it so you dont have to add a damn space before every line of code.. god thats annoying...

[oompa loompa]

can't do that
if i could do that, i would have done it back in v0.08, but the compiler is too stupid to tell the difference between a label and a statement

it makes code look pretier too =P

[Tom Maneiro]

Code not only looks pretty with tabs, but also it is a correct programming technic: well-organized codes can be understanded very easy.

wow... two semesters of programming can be hard, but it helps to polish your code.

There are some good tips for get good codes:
1) Organize your code with tabs, not only with single spaces
2) DECLARE EACH VARIABLE THAT YOU WANT TO USE, also, if you want, initialize your vars to zero, empty, or null. This is required in some languages, like Pascal, for avoid dirty memory spaces with garbage/random undesired values that can lead to unexprected results.
3) Avoid the usage of global variables inside of procedures if you are using it. The idea of a procedure is that it can be independent from the rest of the code.

more tips will come soon... you could also add these tips to the FAQ

[oompa loompa]

Tom said:

3) Avoid the usage of global variables inside of procedures if you are using it. The idea of a procedure is that it can be independent from the rest of the code.

only in programming classes (i've only taken one =P, skipped everything else =D), i've seen this brought up a lot. for me, not taking very many classes on programming, i'd use these a lot =P, like uber a lot, like the whole program. reason is because of the programs i make, like level data, map data, graphics, player memory, npc memory, etc all need to be global. i'd say use them only if necessary, but it is allright to use them many times

[kram8192]

I didnt know until now about the signs, next, how to get asm libraries to communicate with basiegaxorz, I can then finally work on the compression library.

for now, I can only do compression through bex files.

my compression algorithms seems to work great with colors and 8x8 tiles, may work with other things too

here is an example:
0400 0D10 000E 0100 0D11 000F 080A 2432

uncompressed:
0A0A 0A0A 0A0A 0A0A 0A0A 0A0A 0A0A 0A0A
240A 0A0A 0A0A 0A0A 0A0A 0A0A 0A0A 0A0A
0A0A 3232 3232 3232 3232

yes, I did that with just brain power, and am willing to write code for decompression, that 16 bit variant should be plenty enough to compress artwork.

[kram2024]

in the classical approach, $ was string, not byte and % or nothing was integer, also A$=A% thus attempting this in classical BASIC would produce an error:
10 LET A$ = "foo"
20 A = A + 1

would produce:

TYPE MISMATCH IN LINE 20

thus if you really want to have things like classical basic, some changes are needed:

1.) change __INTEGER_foo to just foo, and have the compiler assume that foo is as dimensioned, well you get the idea

2.) notice the line numbers. that is more true to its original form than the labels are GWBASIC and BASICA only support numbered lines, so does the original language, only newer variants support labels, unless the compiler already recognises them.

also, some classical approaches to running external programs are as follows:

45 RUN "BAR"

as seen on the Tandy TRS-80

45 LOAD "BAR"

as seen on the APPLE II in both DOS 3.3 and PRODOS basic.system

oh, and a nice feature that could be useful on a sega CD:

67 BLOAD "FOOBAR", &FFD5

as seen on the APPLE II, loads binary data into RAM from an external file, the basiegaxorz variant may be a little different:

bload "pcmdata.bin", &h00FF0562

that can save a lot of compiling time with scd programs, especially since external data is loaded from outside the program, and bload can be used to load any kind of data to any address, this even includes this:

bload "gfx.bin", &h00C00004

note how simple that is, yet effective. loading tiles directly from another file into video RAM, or it can be a color palette, or other data, who knows.

if people want to play mp3's, they just need write the code to support them, and bload them into memory. same goes for wave and ogg files and levels, even instruments the list goes on.

[oompa loompa]

in the classical approach, $ was string, not byte and % or nothing was integer, also A$=A% thus attempting this in classical BASIC would produce an error:
10 LET A$ = "foo"
20 A = A + 1

would produce:

TYPE MISMATCH IN LINE 20

thus if you really want to have things like classical basic, some changes are needed:

1.) change __INTEGER_foo to just foo, and have the compiler assume that foo is as dimensioned, well you get the idea

the reason why there's a __INTEGER_ in front of integers is because it gives symbol names a unique name so that the assembler doesn't mess it up with another symbol name

2.) notice the line numbers. that is more true to its original form than the labels are GWBASIC and BASICA only support numbered lines, so does the original language, only newer variants support labels, unless the compiler already recognises them.

basiegaxorz supports line numbers

also, some classical approaches to running external programs are as follows:

45 RUN "BAR"

as seen on the Tandy TRS-80

45 LOAD "BAR"

as seen on the APPLE II in both DOS 3.3 and PRODOS basic.system

not going to happen on the sega genesis. it would be a different story if the compiled games were running behind an operating system, but not going to happen for a compiler with small goals

oh, and a nice feature that could be useful on a sega CD:

67 BLOAD "FOOBAR", &FFD5

................

yes, this feature will be included for sega genesis compiled games/apps. it hasn't been coded yet, but it is on the to-do list for the next version

overall, i guess oldschool classic basic is what is desired here in this compiler, but there's no way i'm able to facilitate all features of classic gwbasic or whatever basic in basiegaxorz. note also that basiegaxorz is a basic compiler, not an interpreter