Welcome, Guest
You have to register before you can post on our site.

Username
  

Password
  





Search Forums

(Advanced Search)

Forum Statistics
» Members: 267
» Latest member: Jbizzel
» Forum threads: 957
» Forum posts: 6,010

Full Statistics

Online Users
There are currently 94 online users.
» 0 Member(s) | 92 Guest(s)
Bing, Google

Latest Threads
Features breaking compila...
Forum: Core
Last Post: Ljg701
06-19-2022, 08:44 AM
» Replies: 1
» Views: 142
New Text Adventure game u...
Forum: Gallery
Last Post: RandomiserUsr
06-01-2022, 10:21 PM
» Replies: 0
» Views: 107
Testing a variable within...
Forum: Help & Support
Last Post: RandomiserUsr
03-25-2022, 09:59 PM
» Replies: 11
» Views: 2,135
WHILE Loop vs FOR/NEXT Lo...
Forum: Help & Support
Last Post: RandomiserUsr
03-25-2022, 09:55 PM
» Replies: 2
» Views: 629
The Disputed Territories ...
Forum: Gallery
Last Post: Jbizzel
03-21-2022, 05:29 PM
» Replies: 0
» Views: 304
The sound effect thread
Forum: How-To & Tutorials
Last Post: worcestersource
02-23-2022, 02:22 PM
» Replies: 3
» Views: 838
mine sweeper
Forum: Gallery
Last Post: Jbizzel
02-22-2022, 02:17 PM
» Replies: 2
» Views: 813
Kardinal Kid - new game i...
Forum: Gallery
Last Post: Jbizzel
01-30-2022, 10:25 PM
» Replies: 2
» Views: 744
Frogger 50
Forum: Gallery
Last Post: boriel
01-23-2022, 08:21 PM
» Replies: 2
» Views: 801
snake game
Forum: Gallery
Last Post: boriel
01-21-2022, 08:23 PM
» Replies: 1
» Views: 672

 
  STR problem (*solved*)
Posted by: LCD - 05-11-2009, 01:19 PM - Forum: Bug Reports - Replies (12)

Code:
SUB MeineRoutine(x as uinteger,y as uinteger,a$ as string)
IF a$="Test" THEN erg$="Es wurde nur getestet"
ELSE erg$=a$+str(x)+" "+str(y)
end if

PRINT erg$
END SUB

MeineRoutine(30,11,"Hallo")
Compiler claims "temp.bas:48: Error: Undefined label '_MeineRoutine_erg' Errors occured, compilation failed" (No line 48 defined)
I guess, this is a Problem with STR because this:
Code:
dim a as ubyte
a=20
print str(a)
Produces a code that crashes the Emulator

BTW: should POKE STRING adr,string$ work? I mean, if POKE UINTEGER works...

Print this item

  Memory Map
Posted by: LCD - 05-11-2009, 12:22 PM - Forum: Wishlist - Replies (9)

As mentioned on WOS:
A idea for the future version: How about the compiler generating a text file with memory map (not very complex... or with selectable level of detail) I think, something like:
25000-45678 : Main Program
45679-52111 : ASM: Label GRAPHICSDATA
52112-59876 : ASM: Label LevelData
59877-60521 : Variables
or:
25000 : Main Program
45679 : ASM: Label GRAPHICSDATA
52112 : ASM: Label LevelData
59877 : Variables
Level of Detail:
0=Only Program and Variables
1=like 0, but additionaly ASM Labels
2=like 1, but additionaly Basic Labels
3=like 2, but adresses of every used variable added (HiSoft Basic Compiler does this too, this will make it easier to alter or read variables of compiled programs from BASIC Loader for example)

Using a switch like -m level, -M "Filename.txt" or similar (I do not know how the parser works, maybe this can be joined into a single switch)
Memory map can then be parsed by the editor, or the user can check the details.

Print this item

  Found another bug (*solved*)
Posted by: LCD - 05-11-2009, 11:58 AM - Forum: Bug Reports - Replies (1)

Hi Boriel,

Code:
dim a$ as string

a$="This is a test"
print a$

print a$( to 4)
print a$(5 to)

This works, but
Code:
dim a$ as string

a$="This is a test"
print a$( to 4)
print a$(5 to)

This claims "Variable a never used" and compiler stops (version 1.1.9)

Edit: Btw: should POKE STRING adr,string$ and string$=PEEK STRING adr work?

Print this item

  Version 1.1.9 released!
Posted by: boriel - 05-09-2009, 08:56 PM - Forum: ZX Basic Compiler - No Replies

Changes from Version 1.1.7 to 1.1.9

  • ! Fixed a bug for constant string slicing, so
    "0909"(A TO B) now works. Thanks to britlion.
  • ! Expanded grammar to allow something like "0909"(f)
    or "0909"() which are also allowed in Sinclair Basic. Thanks to britlion.
  • ! When used expressions like "0909"(f) (like above) might corrupt
    HEAP memory, leading to a program crash. Fixed. Thanks, britlion Wink
  • ! Fixed a wrong number conversion (type CAST) from signed integers
    to floating point numbers which might cause wrong (random) results.
  • ! '%' suffix was being ignored.
  • ! Global string variables were not optimized unless declared
    with '$' suffix. Fixed.

TODO:
  • Bitwise instructions for AND, OR, XOR, NOT
  • CLEAR to fill memory areas
  • READ, DATA and RESTORE
  • SAVE & LOAD

Print this item

  CODE <constant string> is broken (*solved*)
Posted by: britlion - 05-08-2009, 06:08 PM - Forum: Bug Reports - Replies (2)

I was playing with some complex code from the "One Liners" stuff. The following program behaves completely differently in basic as opposed to going through the compiler. Actually, it crashes when run compiled. (I tried several different types for f and g). Oddly, at the first PLOT, there appears some other changes to the screen - a few bytes of corruption. Something weird is happening there. There are more brackets than I need - mostly in an attempt to make sure the math functions are coming out clearly. Try it in BASIN and then compile it.

I know the functions are unnecessarily complex. That's the nature of the one liner type code. Nonetheless, it ought to behave when compiled just like the interpreted version. Shouldn't it?

Code:
DIM f,g as UBYTE

1  PRINT AT 9,9;"SIMON"
3  FOR f=1 TO 4
4     INK f
5     FOR g=1 TO 32
6         PLOT INT ABS((SGN (f-2.5)*80)+24+g), INT (((CODE "0202"(f TO f)-49)*99)-48+g)
7         DRAW 32,0
8     NEXT g
9     goto 11
10  STOP
11  PRINT INK f; OVER 1;AT CODE "1919"(f TO f)-44,CODE "0099"(f to f)-41;f
12     NEXT f
13  LET f=1
14  goto 9

Print this item

  Version 1.1.7 released!
Posted by: boriel - 05-03-2009, 10:27 AM - Forum: ZX Basic Compiler - No Replies

What's new since 1.1.4:

  • + Added the ELSEIF construct to the IF THEN ELSE sentence
  • + Added more optimizations in some jumps
  • + Added the USR function (both for Strings and Floats). Yes, you can now use USR "a" to get the address of the UDG table (instead of PEEK Uinteger 23675), and also can do RANDOMIZE USR 40000 (if you want to call a legacy machine-code routine; other than that it's useless).
  • * Optimized some print string generated code (now it's smaller)
  • ! Fixed many optimization bugs (almost five). Thanks to LCD
  • ! Fixed ChangeLog file
  • - Internal refactored code (somewhat)
  • ! BOLD and ITALIC could not be used as permament attributes,
    only as temporary ones. Now they are allowed as permament.
  • * Some more syntax compatibility with Sinclair BASIC. Expressions
    like F$(5), F$() or F$(TO) are now allowed. So expressions like PRINT ;;; are.
  • ! single PRINT sentences were not working (they should print a
    newline).
  • * Minor grammar corrections.
  • ! Using a suffix like '$' in a function declaration was being
    ignored. Now this also works ok.
  • + Added suport for PRINT , (Thanks to britlion and LCD for the
    suggestions and bug detection)
  • * Fixed a potential optimization bug for SHR and SHL

TODO:
  • Bitwise instructions for AND, OR, XOR, NOT
  • CLEAR to fill memory areas
  • READ, DATA and RESTORE
  • SAVE & LOAD

Print this item

  Wish: Documentation!
Posted by: britlion - 04-29-2009, 08:27 PM - Forum: Wishlist - Replies (4)

There are lots of things in the compiler that are mentioned obliquely in changelogs.

Please - at least get the list of reserved words up to date so that we know something is there.

Please, document DIM! This keyword is used in so many different ways - to set types, to dimension arrays, to set constants and to block fill arrays with =>

We're a little in the dark generally - and willing to work with that - but I think I'd like to request documentation and examples for DIM be top of the pile!

Print this item

  DIM issue
Posted by: britlion - 04-29-2009, 08:17 PM - Forum: Wishlist - Replies (5)

Why does

Code:
DIM list(1) AS uByte => {24,2}

compile just fine, but

Code:
DIM p(1) AS String => {"Word","Word"}

Will not. I thought initializing arrays this way was a replacement for READ and DATA, which are not supported! I love being able to block fill an array at compile time with numbers. Can I not do the same thing with strings? How do I replace:

DATA "STRING","STRING","STRING" then?

Print this item

  Print issues (*fixed*)
Posted by: britlion - 04-29-2009, 12:31 PM - Forum: Bug Reports - Replies (3)

Big issue: I notice print doesn't support commas.

Print "1","2" doesn't line up in columns. It won't even compile!

Print "1"+CHR$(6)+"2" does compile, but the print routine seems to ignore the tab.

I'm not sure how to work around this for spectrum programs that format text out in columns, or use commas to hop to the next line.



Optimization freak (I am. If I can save one assembler instruction, that's at least a byte saved!)

I notice that:

PRINT "1";
PRINT "2"

and PRINT "1";"2"

Produce exactly the same assembler code! Bravo. But

PRINT "1"+"2" is quite a lot shorter - the compiler sees it can combine the strings into one label.

Similarly:

PRINT INK1;"BLUE";INK 2;"RED"

is quite a lot longer in assembler than:

PRINT CHR$(16)+CHR$(1)+"BLUE"+CHR$(16)+CHR$(2)+"RED"

Your print routine parses both the above lines identically. The second, while far less decipherable to a human), to the compiler is a whole 14 bytes shorter in the assembler. Given how common print and combined color codes are in code, I suspect there is a notable size optimization that could be made in compiled code.


Off this post's topic:
The other one I noticed would be not storing a variable in a register if we don't need to:

Code:
LET A=A+1
LET A=A*2

Does Load, increment, store, multiply, store.

First up, I noticed it doesn't reload from store in the middle. It also recognizes multiply by two, and does the bitshift. That's very cool. It doesn't need to store in the middle tho!

(Is it worth optimizing double and triple bitshifts for *4 and *8 and so on? These are common multipliers, if only for screen coordinates.)

Print this item

  Feature: Italics!
Posted by: britlion - 04-29-2009, 12:09 PM - Forum: Wishlist - Replies (9)

I was rummaging through the .asm code, and I note it's pretty well optimized - though I can see places that could be neater. But that's for another time.

I noticed one of the runtime code blocks was labelled Italics..

So, curious, I tried compiling:

PRINT ITALIC 1; "Italics?"

And it worked perfectly! This isn't documented anywhere! What an awesome little addition to the language.
(It prints the text with the top a pixel to the right and the bottom a pixel to the left, and the middle left alone)

This should probably be added to the reserved words list.

Print this item