LD A,R not implemented (*solved*)

[britlion]

The assembler doesn't seem to like LD A,R which is standard Mnemonics for instruction ED5F.

[boriel]

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 -->

[britlion]

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.

[boriel]

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.

[britlion]

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..?

[boriel]

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).

[britlion]

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*

[boriel]

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.

[britlion]

I was just joking

I like my screen length variables!