Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
LD A,R not implemented (*solved*)
#1
The assembler doesn't seem to like LD A,R which is standard Mnemonics for instruction ED5F.
Reply
#2
britlion Wrote:The assembler doesn't seem to like LD A,R which is standard Mnemonics for instruction ED5F.
Fixed. Download ZX Basic 1.2.5-r1513d <!-- m --><a class="postlink" href="http://www.boriel.com/files/zxb/zxbasic-1.2.5r1513d.msi">http://www.boriel.com/files/zxb/zxbasic-1.2.5r1513d.msi</a><!-- m -->
Reply
#3
That was incredibly fast!

It's such a little used instruction, unless you're going for an encrypted loader, or possibly something in the random number department.

In my case, I was doing some timing tests and wanted my input data to change each cycle.

Incidentally, your 16 bit multiply is faster than the one I was thinking of suggesting.

My 8 bit one still wins though 8)

Jose, I have to keep saying how much I appreciate your efforts to make this compiler so good. And it's awesome.
Reply
#4
I've also managed to speedup assembler parsing. Now your program compiles with -O3 in less than 30seconds :!:
This update will be uploaded this evening.
Reply
#5
Tongue Tongue Tongue Tongue Tongue Tongue Tongue Tongue Tongue Tongue

Yeehaw!

Okay, you made the assembler SIX TIMES FASTER???

*blink*

Did you suddenly make it multi-threaded or something? Or was it doing something...unclever..?
Reply
#6
britlion Wrote:Tongue Tongue Tongue Tongue Tongue Tongue Tongue Tongue Tongue Tongue

Yeehaw!

Okay, you made the assembler SIX TIMES FASTER???

*blink*

Did you suddenly make it multi-threaded or something? Or was it doing something...unclever..?
Not exactly. It's not 6 times faster. It's 6 times faster with your program (and probably with some others). I mean, long labels + long varnames where confusing the zxbasm lexer (a problem in the PLY lexer layer + Regular Expressions used in it). Just used a different approach and it worked ok.

It was not zxbasm was slow. It was a *pathological case* that, when it happens, made the zxbasm go very slow (exponentially slow sometimes).
Reply
#7
Now you make me feel guilty for having huge variable names. :-)

My policy is names should be as self documenting as possible.

And unique. I often put identifiers in front of them - particularly for things I'm thinking will end up as library routines - so that they are very unlikely to trample anyone else's labels and variables.
FourSpriter, for example, had almost all references converted to begin with fsp.

As for Footy - the original game is nigh on encrypted with single letter variables; and it's probably my reaction to that to convert them into ones that I am NOT going to mistake again *heh*
Reply
#8
britlion Wrote:Now you make me feel guilty for having huge variable names. :-)

My policy is names should be as self documenting as possible.

And unique. I often put identifiers in front of them - particularly for things I'm thinking will end up as library routines - so that they are very unlikely to trample anyone else's labels and variables.
FourSpriter, for example, had almost all references converted to begin with fsp.

As for Footy - the original game is nigh on encrypted with single letter variables; and it's probably my reaction to that to convert them into ones that I am NOT going to mistake again *heh*

Wait!! Having large variable names is OK, and won't affect compiling speed anymore. :!:
It was an issue with the compiler-tool I use to create this compiler (not the compiler itself), and has been solved. So use variable names as you like.
Reply
#9
I was just joking Smile

I like my screen length variables!
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)