Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Summary of stuff not working [V1.2.4]
#1
Okay, I've made several posts and it's all getting confusing. Here's what seems to be wrong:
  • * [Tested Fixed in 1.25 Beta r1489]@variablename - Seems to point at one byte BELOW the correct one.

    * [Can't replicate cleanly. Needs proved example of error.] [This was probably caused by the stack erorr which is fixed in r1489 ] CHR / CHR$ - CHR$(variable) seems to crash sometimes. CHR$(number) works fine.

    * [Tested Fixed in 1.25 Beta r1489] BOLD and ITALIC cannot be used as temporary attributes (BOLD 1 works. PRINT BOLD 1;"Hello" does not.) The compiler issues some very cryptic error messages about this.

    * -O2 and -O3 are likely to fail to compile what -O1 and no optimization compiles perfectly. (Seems to fail in 'update_goes_and_comes' in optimizer.pyc on larger files)

    * [Tested Fixed in 1.25 Beta r1489]SHL and SHR don't work for Integers (reported by LCD)

    *[Tested Fixed in 1.25 Beta 1] Comparisons : the Boolean logic for >= for type FIXED is bugged. (it always returns true)

    *[Tested Fixed in 1.25 Beta 1] uByte seem to have something wrong on the comparison front as well:
    Code:
    DIM ub as uByte
    DIM b as byte
    DIM ui as uInteger
    DIM i as integer
    DIM ul as uLong
    DIM l as LONG
    DIM fi as fixed
    DIM fl as float

    print ub,b,ui,i,ul,l,fi,fl

    if 0<=20 then print "0<=20" : END IF
    if ub <= 20 then print "ub <= 20" : END IF
    if b <= 20 then print "b <= 20"   : END IF
    if ui <= 20 then print "ui <= 20" : END IF
    if i <= 20 then print "i <= 20"   : END IF
    if ul <= 20 then print "ul <= 20" : END IF
    if l <= 20 then print "l <= 20"   : END IF
    if fi <= 20 then print "fi <= 20" : END IF
    if fl <= 20 then print "fl <= 20" : END IF

    NOT strictly speaking broken, but serious "Quality of life" issues:

    * The compiler's errors could be a lot more helpful!
    1> Instead of "unexpected end of file" how about "You started a FOR loop on line 30 that never finished" and "You have an IF on line 100 that doesn't have an END IF" - if the compiler could say what statement or parenthesis isn't closed that would help me track down about 90% of my bugs. As it is, I type a line, compile, type a line, compile and so on - otherwise I'd never find the problem! [I'm REALLY bad at forgetting END IF]

    2> Could we get a warning any time a variable is used that hasn't been DIM first? Or just plain not allow it, even? A mistyped variable (vectory instead of vectorY) is very hard to find if the compiler simply creates it without telling me. So the program compiles and runs, but the math isn't working right...

    * The assembler seems to be very slow - zxb --asm program.bas returns to the command prompt within a few seconds. If we ask the assembler to assemble the file as well, it can stay away for several minutes.
#2
If I remember correctly: Usually @ is used as label pointer. BASIC and variables pointers are two different kind of labels. If you check the generated ASM file, you will notice that there is something added to the name of BASIC labels, while variable labels do not have this kind of addition. I discussed this in this forum with Boriel, because I wanted something like LD HL,@variable too. So this is not a bug, this is a feature... ;-)
I wonder where boriel is. Even on <!-- m --><a class="postlink" href="http://www.speccy.org/foro/viewtopic.php?f=6&t=492&start=510">http://www.speccy.org/foro/viewtopic.ph ... &start=510</a><!-- m --> his last message was from october 2009.
------------------------------------------------------------
http://lcd-one.da.ru redirector is dead
Visit my http://members.inode.at/838331/index.html home page!
#3
LCD:

I hope your collar bone is better!

I can't get @ pointers to work with variables - Boriel himself suggested using something along the lines of

Code:
DIM udg (7) as uByte => {1,2,3,4,5,6,7,8}
POKE UINTEGER 23675,@udg

To set UDGs. I can't get this to work. Using asm and defb as a label works just fine, however.

I too am wondering where he is. I really hope he's okay. Haven't heard anything from him on here since last year. I hope he's just tied up with his PHD stuff, and has been too busy to check the boards.
#4
From day to day it causes less pain, so I hope, I can start working again in around three weeks.

I hope, Boriel will reappear soon and clear some of the questions. Strange, but I caaot recall, the Variable pointer ever worked here.
------------------------------------------------------------
http://lcd-one.da.ru redirector is dead
Visit my http://members.inode.at/838331/index.html home page!
#5
LCD Wrote:From day to day it causes less pain, so I hope, I can start working again in around three weeks.

I hope, Boriel will reappear soon and clear some of the questions. Strange, but I caaot recall, the Variable pointer ever worked here.


I'm glad you are getting better.

I used the UDG variable pointer trick before. It's perfectly reasonable to use asm and a label, I suppose - but I think one of the design ideas for the basic compiler was that asm wouldn't actually be needed. It does sort of break the idea to HAVE to go to inline assembly; though that is staggeringly useful for defb based data.

And yeah, I'm starting to get worried about Boriel as well.

EDIT: I've just found his twitter, and he seems to be tweeting away. Also he put something in the CAPTCH forum in Jan. So, I think he's okay. We're all good.
#6
I cannot check the code at moment, but I never used a pointer to arrays yet.

Boriel came back, this is his latest post:
<!-- m --><a class="postlink" href="http://www.speccy.org/foro/viewtopic.php?f=6&t=492&sid=4997401720797764cc191ac2883ecbdf&start=510#p19675">http://www.speccy.org/foro/viewtopic.ph ... 510#p19675</a><!-- m -->
------------------------------------------------------------
http://lcd-one.da.ru redirector is dead
Visit my http://members.inode.at/838331/index.html home page!
#7
Hi, I'm back

Sorry for the delay (read the news in the forum, I explain there why: basically, forum notifications were broken and I wasn't aware of your post).
First of all, I've been told that as of version 1.2.4 (the latest one) I've reintroduced old bugs :oops: Try your test with version 1.2.3.
I've been all this evening fixing the forum, so I couln't check the compiler bugs, but I will be working on it.

Thanks to you all, and hope you're okay.
#8
Glad to have you back Boriel.

I keep editing the list of items at the start of this thread to keep it up to date. I just found out (after two days of scratching my head at something that didn't work correctly) that type FIXED comparison ">=" always returns true... So added that to the list. I don't know if it notifies you of edits or not, so I thought I'd add a post to say there's a new bug in the list.
#9
britlion Wrote:Glad to have you back Boriel.

I keep editing the list of items at the start of this thread to keep it up to date. I just found out (after two days of scratching my head at something that didn't work correctly) that type FIXED comparison ">=" always returns true... So added that to the list. I don't know if it notifies you of edits or not, so I thought I'd add a post to say there's a new bug in the list.

I think the phorum does not notify editions. But, at least, these new post are being reported :wink:
So, here we go!

The ">=" bug is very important. I did many relational operator testing, and the compiler was supposed to past them all. Will check it too.
#10
Yes indeed! That's why I wanted to bring that one particularly to your attention.

I can work around it by always using < instead and swapping the variables of course. But it took me ages to realize that was the bug, and I had to do quite a bit of testing to get there.
(I'm sort of being proud of myself for isolating that). If you try the test program I listed with 1.23 and 1.24 both have the problem. I think not many people have been working with the fixed type - but I decided to try floating point screen pixels for added accuracy.

Though given the low resolution of the spectrum, I sorta wish there was a faster, smaller 16 bit float that could do +/- 255 (or even 511 to allow for overflow off screen). Even if it only had 4 bits of floating point (and thus was accurate to about 0.125) it would be ideal for screen work. I suppose I can emulate it by working with an integer and multiplying up co-ordinates for internal storage though.

Anyway, back to the original point: Yes, this bug could trip someone badly! Thank you for looking into it.

I also have some suspicions about AND and OR not working quite right. Not sure if that was to do with my corrupted compiler or not - I haven't done a definitive test since reinstalling.


The compiler is becoming very useful actually. I'm getting into medium sized programs now, and it's holding together very well. And for the most part, it seems to be producing fast code. Thankyou for building it!
#11
Okay, I've fixed the >= and < comparisons. It was a low level (Asm) bug. It was affecting both Fixed and Long types (surprisingly Long types were less prone to fail, but they were bugged either). Yes, the < was also bugged :!: :oops:

So this bug is closed. Tongue

Note, I've put an exclamation mark on threads being worked on. Once the bug is fixed, I will remove the exclamation mark to indicate this.
#12
Way to go Boriel!

I just added a problem with comparisions for type uByte, however.

If and when you have a moment, can you check that? I put an example program that fails for me as well.

I'm trying to keep the original message current on bugs. I'll retest them all against any new releases, of course.
#13
britlion Wrote:Way to go Boriel!

I just added a problem with comparisions for type uByte, however.

If and when you have a moment, can you check that? I put an example program that fails for me as well.

I'm trying to keep the original message current on bugs. I'll retest them all against any new releases, of course.

If you're using the .py version (.zip file instead of .msi file), and have also installed SVN or TortoiseSVN you can now update the compiler source and check the fixed an floats comparators. Idea
#14
Yeah, you've mentioned SVN. It's a tool I've heard about in coding circles once or twice, but never used. I'm not using the .zip version. I tried an msi install, and then thought I could use the .zip to upgrade...but apparently I can't. It has completely different files in it!

So I'll either need a tutorial in how to get SVN versioning working or an MSI version I'm afraid :-)

No rush - I know there are a few issues that came up in 1.24 that need to be hammered back down. Did the uByte comparison issue show up for you as well, or was it just my strange computer?
#15
Fixed and uByte issues seems to be fixed. And I couln't reproduce the CHR$(n) problems you mentioned. CHR$(n) works ok for me. :?:
Try this new version: <!-- m --><a class="postlink" href="http://www.boriel.com/files/zxb/zxbasic-1.2.5beta.msi">http://www.boriel.com/files/zxb/zxbasic-1.2.5beta.msi</a><!-- m -->

Installing and repeat your tests.
The next bug to fix is the @ operator. It should work with UDG as expected.


Forum Jump:


Users browsing this thread: 1 Guest(s)