Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[idrougge]

Hello! New forum user, longtime AMOS user.

Today, I installed the compiler for AMOS Pro and compiled my latest project without errors. However, upon running it, I encountered an odd problem which prevents my game from working properly: When a variable (or rather, an array) is set to True (-1), the compiled program sets it instead to -2147483648. Is this a known bug, and is there a fix?

[bruceuncle]

Difficult to pinpoint the problem without an example of the code...

The value -2147483648 in decimal is $80000000 in hexadecimal.  This is a special value AMOS uses to indicate a Null value internally.  If, for example, it's expecting to evaluate some expression and a function in that expression is not actually a function, it returns this value.

There's an easy to see example using the Print statement (at least there will be until the next V2.10 release as I've fixed it now  ): 

When you code Print in a program, it expects to be followed by an expression - something it can evaluate and actually print.  You can then optionally keep adding expressions separated by delimiters (commas or semi-colons).  If instead, you follow Print with a delimiter, one of two situations will occur as in these two examples:

Print ;"Hello World"  will give a Syntax Error.
Print ,"Hello World" will print -2147483648 Hello World

In the first one, AMOS is trying to evaluate ";".  To do this it goes to the main AMOS Token Table and finds the ";" token:

   dc.w   L_Nul,L_Nul
   dc.b   ";"+$80,"O",-1

Both the Instruction and Function Number for the ";" token are defined as L_Nul and these will give a Syntax Error if the Interpreter tries to call them.

In the second one, AMOS is trying to evaluate ",".  Again, it would go to the main AMOS Token Table and find the "," token:

   dc.w   L_Nul,L_FnNull
   dc.b   ","+$80,"O",-1

This time, the Instruction Number is defined as L_Nul and this will give a Syntax Error if the Interpreter tries to call it.  But the Function Number is defined as L_FnNull.  That function is the one that returns the -2147483648 value.  The designers of AMOS had to do this as the humble comma crops up all over the place in AMOS Basic, not just as a delimiter when Print-ing.  In all those other cases, the comma token needs to be evaluated by the common evaluation routine, but be recognised as something other than an expression.  So it has to return something (-2147483648) rather than pop out the Syntax Error.  AMOS also uses a lot of shortcuts in the code to avoid that happening anyway when it finds a comma token.  So this behaviour is a bit of a safety net.

The bug is not in the Interpreter Print-ing the wrong thing.  It's the Tokeniser (the code that turns your text program into AMOS tokenised code) that fails to reject it when you type your code into your program.


Back to the compiler!   I haven't pulled it apart yet but suspect something similar is happening.  If you can supply an example of the code where it's happening, it would be a great help in tracking down this bug...  I'll also, of course, add it to the bugs list when I have that example (pretty please?).

[Lonewolf10]

When a variable (or rather, an array) is set to True (-1), the compiled program sets it instead to -2147483648. Is this a known bug, and is there a fix?

Yes it is a known bug, which is why I always manually set variables directly (I use 1 as yes and 0 as no, but there's no reason why you can't use -1, or any other number). Code reading the variable (or array in your case) should recognise the values you choose for true and false.

I'll also, of course, add it to the bugs list when I have that example (pretty please?).

Did this get missed from the list? It was a well known bug that must have been mentioned several times on the AMOS-list group over on Yahoo.

[idrougge]

Bruceuncle, do you still need my code?

[bruceuncle]

When a variable (or rather, an array) is set to True (-1), the compiled program sets it instead to -2147483648. Is this a known bug, and is there a fix?

Yes it is a known bug, which is why I always manually set variables directly (I use 1 as yes and 0 as no, but there's no reason why you can't use -1, or any other number). Code reading the variable (or array in your case) should recognise the values you choose for true and false.

I'll also, of course, add it to the bugs list when I have that example (pretty please?).

Did this get missed from the list? It was a well known bug that must have been mentioned several times on the AMOS-list group over on Yahoo.

Nope, it's not in the bugs list I'm maintaining.  Must have missed it somewhere along the line. 

From a quick look at the compiler code it generates a (correct) moveq #-1,d3 code fragment as the return value from the True token.  In the interpreter code, it's FnTrue()  (instruction number L_FnTrue) which just does the same thing.  So it looks like it might be a good symptom to chase up for something unrelated going wrong in the tokeniser (the cause of that example I used a couple of posts back) or the compiler, which is just causing this behaviour as a side-effect.

Bruceuncle, do you still need my code?

Yes please idrougge.  This is a bug that I didn't have on the 'fix it!' list.  And, as you'll see from my reply to Lonewolf10 above, it's not the True function itself that's at fault.  So it would be great to have some code where it happens all the time.  I can look at the machine code resulting from the compile against the original AMOS program and its tokens.

Just from general comments about the compiler, I suspect it's getting something wrong in its core that generates a few of these 'unusual behaviours'.


If you haven't been following the threads on AMOS Pro's future, the general plan is to fix up the existing bugs in the loader/editor/monitor/interpreter, the *.Libs libraries, and the amos.library (which interfaces AMOS to the Amiga hardware).  Plus, get the docs accurate and complete.  The compiler will come last of all, hence my comments about it being a while yet.  The reasoning is that, as the compiler is (mainly) slotting together chunks of code straight out of the *.Libs files, it would be a good idea to get that fixed first.  And we're all doing this in our spare time so sometimes progress is slow...

[idrougge]

I have pasted the program at http://privatepaste.com/3f9b55ba03

The offending line should be around line 654:
NPC(NPCNR,0)=True : NPC(NPCNR,6)=True

Another offender is at line 260:
KRABBA(KRABBNR,0)=True

[bruceuncle]

I have pasted the program at http://privatepaste.com/3f9b55ba03

Many thanks idrougge.     It will be good to be able to make the comparisons between the compiled code and the tokenised source.  I'll continue our dialogue on this file in PMs to protect privacy.