| Welcome, Guest |
You have to register before you can post on our site.
|
| Online Users |
There are currently 222 online users.
» 0 Member(s) | 219 Guest(s)
Applebot, Bing, Google
|
| Latest Threads |
.tap file code not execut...
Forum: Help & Support
Last Post: Zoran
04-28-2025, 10:59 AM
» Replies: 4
» Views: 319
|
Exit from more than one l...
Forum: Wishlist
Last Post: Duefectu
04-23-2025, 10:06 PM
» Replies: 3
» Views: 300
|
put small ASM programs li...
Forum: How-To & Tutorials
Last Post: Zoran
04-18-2025, 02:02 PM
» Replies: 6
» Views: 1,600
|
Creating +3 Menus - Loadi...
Forum: Help & Support
Last Post: merlinkv
04-16-2025, 02:08 PM
» Replies: 6
» Views: 554
|
Randomize not very random...
Forum: Help & Support
Last Post: Zoran
04-08-2025, 10:40 AM
» Replies: 4
» Views: 893
|
Scope rules
Forum: Bug Reports
Last Post: Zoran
04-04-2025, 09:46 AM
» Replies: 2
» Views: 328
|
Using constants not allow...
Forum: Bug Reports
Last Post: baltasarq
03-19-2025, 10:00 PM
» Replies: 8
» Views: 1,066
|
404 page not found
Forum: Documentation
Last Post: boriel
03-08-2025, 07:16 PM
» Replies: 5
» Views: 2,886
|
Spectrum keywords codes
Forum: Bug Reports
Last Post: boriel
03-08-2025, 11:00 AM
» Replies: 1
» Views: 419
|
ZXodus][Engine
Forum: ZX Basic Compiler
Last Post: boriel
02-19-2025, 11:43 PM
» Replies: 69
» Views: 213,808
|
|
|
| Effects of running out of memory |
|
Posted by: LTee - 03-23-2011, 02:03 PM - Forum: Help & Support
- Replies (4)
|
 |
I just added another (hopefully the final!) screen to my game and after compilation it locked up at the menu screen. I suspect that this is because of a lack of memory - my compiled code is now 28932 bytes long, so starting at the default of 32768 that takes me up to 61700. The heap is 4k still, yes? So there's not actually enough space to allocate it, I suspect. Compiling with -O2 took the size down a little and allowed it to run for longer, but I was still getting lockups.
I fixed this by moving the ramtop up to 30000 and now it seems fine. However, is there any way for me to be sure that this is enough space? And is there anything I should watch out for now that I've had to use some contended memory?
|
|
|
| Try this for faster multiply? |
|
Posted by: britlion - 03-23-2011, 12:26 AM - Forum: Wishlist
- Replies (1)
|
|
(where /should/ I be putting this sort of thing?)
Plug this in for mul16.asm
Code: __MUL16: ; Mutiplies HL with the last value stored into de stack
; Works for both signed and unsigned
PROC
LOCAL __MUL16LOOP1
LOCAL __MUL16NOADD1
LOCAL __MUL16LOOP2
LOCAL __MUL16NOADD2
ex de, hl
pop hl ; Return address
ex (sp), hl ; CALLEE caller convention
;;__MUL16_FAST: ; __FASTCALL ENTRY: HL = 1st operand, DE = 2nd Operand
;; ld c, h
;; ld a, l ; C,A => 1st Operand
;;
;; ld hl, 0 ; Accumulator
;; ld b, 16
;;
;;__MUL16LOOP:
;; sra c ; C,A >> 1 (Arithmetic)
;; rra
;;
;; jr nc, __MUL16NOADD
;; add hl, de
;;
;;__MUL16NOADD:
;; sla e
;; rl d
;;
;; djnz __MUL16LOOP
__MUL16_FAST:
ld b, 8
ld a, d
ld c, e
ex de, hl
ld hl, 0
__MUL16LOOP1:
add hl, hl ; hl << 1
;sla c
rla ; a,c << 1
jr nc, __MUL16NOADD1
add hl, de
__MUL16NOADD1:
djnz __MUL16LOOP1
ld a,c
ld b,8
__MUL16LOOP2:
add hl, hl ; hl << 1
rla ; a,c << 1
jr nc, __MUL16NOADD2
add hl, de
__MUL16NOADD2:
djnz __MUL16LOOP2
ret ; Result in hl (16 lower bits)
ENDP
I think it saves on average about 110 T states per multiply, according to my tests. If I counted correctly, it's 10 bytes longer.
Why it's faster:
SLA C is a long slow opcode, compared to just doing the RLA. It's faster to loop twice and roll the A register round the two halves than it is to roll the 16 bit pair.
Also in this case, JR is a better choice than the original JP instruction. Not only is it a byte shorter, but it's faster on average. Probably.
16 JP NC instructions = 160 T states.
JR is 7 if condition fails, 12 if it passes. We can assume that for bits, half will be 1 and half will be 0. So that's an average of (8*12)+(8*7)=156 T states. It's worth saving the byte; which compensates for a double loop being a few extra bytes.
Could also probably shave a little time by using dec b && jp nc _mul16loop since that will jump most times. Probably not worth the bytes. Having two short loops actually speeds up the DJNZ a little too 
|
|
|
|
| Run Time error in Footy code. |
|
Posted by: britlion - 03-19-2011, 04:16 PM - Forum: Bug Reports
- Replies (5)
|
|
1.2.8-s644 Still isn't running correctly.
My half build football manager program gives an out of memory error at some early string handling. Goes right past that if compiled with 1.26.
I tried to attach a file, here, but couldn't.
With 1.2.8-s644 this breaks at line 438, just after the print 2. With 1.26 it works (it breaks later. Haven't investigated that).
Always compiled with --debug-array --debug-memory (not with O3).
|
|
|
|
| fixed is broken (*solved*) |
|
Posted by: britlion - 03-17-2011, 11:37 PM - Forum: Bug Reports
- Replies (7)
|
|
Code: CLS
#include <input.bas>
dim num AS FIXED
value$=input(8)
cls
print value$
num=VAL(value$)
print num
print num/2
print ln (num)
The last line - ln(num) breaks it. Without that line it compiles, but gives nonsensical answers. I think this is the reason why my fSin benchmark isn't compiling. fSin works with fixed point numbers.
There's an issue with input / strings as well though:
Code: CLS
#include <input.bas>
dim num AS FIXED
value$=input(8)
cls
print value$
Compiles, but gave an out of screen error for me.
|
|
|
|
| Labels as byte values in inline assembly |
|
Posted by: britlion - 03-13-2011, 01:47 PM - Forum: Help & Support
- Replies (3)
|
|
If I had code that wanted to make a jump table, and still be able to compile it such that it can move around, how can I do this?
That is, I want something like
jump_table:
defb routine1
defb routine2
defb routine3
routine1:
<code>
ret
routine2:
<code>
routine3:
<code>
The design calls for a jp (hl). I could probably code around it, but I'm wondering how I could get label locations into the actual bytes compiled?
|
|
|
|
| Bug or Feature? |
|
Posted by: LCD - 03-10-2011, 05:39 PM - Forum: Help & Support
- Replies (8)
|
|
Hi Boriel, I ran into following Problem:
Code: print at 17,0;(peek 3)*9
Code: dim c1 as uinteger
c1=peek(adr)
print c1*9
Code: dim c1 as ubyte
c1=peek(adr)
print c1*9
Any chance to fix this?
Another Problem:
Code: print at 17,0;1<<3+2
|
|
|
|
| Possible String issue? (*solved*) |
|
Posted by: LTee - 03-10-2011, 01:44 PM - Forum: Bug Reports
- Replies (21)
|
|
I don't know whether this is expected behaviour or not because of the way Strings are stored, but my high score routine just presented this issue so I thought I'd check before I changed how it works. :-)
If I declare a string outside of a sub I can use it within any sub. If I change the value within the sub then that's fine, unless I make it equal to another String which was declared within that sub. If I do that, the value of the first string becomes blank as soon as the sub ends.
This is kind of hard to explain, so see this example:
Code: dim testglobal as string
cls
testglobal = "global"
print testglobal
setlocal()
print testglobal
print "done"
sub setlocal
dim testlocal as string
testlocal = "local"
testglobal = testlocal
print testlocal
print testglobal
end sub
Code: global
local
local
done
I think I would be better off using a function for this kind of thing rather than a sub, but I just thought it was worth checking whether that behaviour was expected or not.
|
|
|
|
| New beta release 1.2.8r2153 |
|
Posted by: boriel - 03-09-2011, 11:05 PM - Forum: Bug Reports
- Replies (3)
|
 |
Okay, this is a new beta release. It fixes several *CRITICAL* bugs found mainly by LTee.
Please, download here: <!-- m --><a class="postlink" href="http://www.boriel.com/wiki/en/index.php/ZX_BASIC:Archive#Latest_Development_Version">http://www.boriel.com/wiki/en/index.php ... nt_Version</a><!-- m -->
Version 1.2.7 should not be used (It will be soon removed from the download archive).
|
|
|
|
|
