![]() |
LD A,R not implemented (*solved*) - Printable Version +- Forum (https://www.boriel.com/forum) +-- Forum: Compilers and Computer Languages (https://www.boriel.com/forum/forumdisplay.php?fid=12) +--- Forum: ZX Basic Compiler (https://www.boriel.com/forum/forumdisplay.php?fid=11) +---- Forum: Bug Reports (https://www.boriel.com/forum/forumdisplay.php?fid=15) +---- Thread: LD A,R not implemented (*solved*) (/showthread.php?tid=185) |
LD A,R not implemented (*solved*) - britlion - 03-18-2010 The assembler doesn't seem to like LD A,R which is standard Mnemonics for instruction ED5F. Re: LD A,R - boriel - 03-18-2010 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 --> Re: LD A,R not implemented (*fixed*) - britlion - 03-18-2010 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. Re: LD A,R not implemented (*fixed*) - boriel - 03-19-2010 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. Re: LD A,R not implemented (*fixed*) - britlion - 03-20-2010 ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() 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..? Re: LD A,R not implemented (*fixed*) - boriel - 03-20-2010 britlion Wrote: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). Re: LD A,R not implemented (*fixed*) - britlion - 03-20-2010 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* Re: LD A,R not implemented (*fixed*) - boriel - 03-20-2010 britlion Wrote:Now you make me feel guilty for having huge variable names. :-) 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. Re: LD A,R not implemented (*fixed*) - britlion - 03-20-2010 I was just joking ![]() I like my screen length variables! |