On Sat, Nov 12, 2011 at 9:12 PM, <francesco.gring...@ing.unibs.it> wrote: > On Nov 12, 2011, at 8:16 PM, Michael Büsch wrote: > >> On Sat, 12 Nov 2011 20:03:36 +0100 >> francesco.gring...@ing.unibs.it wrote: >> >>> On Nov 12, 2011, at 7:05 PM, Michael Büsch wrote: >>> >>>> On Sat, 12 Nov 2011 18:31:21 +0100 >>>> francesco.gring...@ing.unibs.it wrote: >>>> >>>>> orxh (r1 << 8) & 0x0100, r2 & ~0x0100, r2 >>>> >>>> This is not really going to fly. If you want this highlevel stuff, you >>>> should port a C compiler to the architecture. >>>> This is assembly. It doesn't know about reg<<imm or similar stuff. >>> Yes, you are right and, in fact, the patched assembler will just accept >>> only what the cpu may execute, I does not pretend to be a C compiler. It's >>> just another way for assembling "or with shift and select" (or jzx), and >>> this way really enhances the readability of the assembly code. Give it a >>> try :-). >>> >>> If I'm not wrong, it's like "mov 0x1234, r1" >> >> No. >> It crosses the line where it does (pseudo)operations (like shift, and, or, >> etc..) >> on non-const (non-immediate) stuff. > >> Just do a preprocessor or something like that, that translates your >> pseudo-insns >> to real insns. Alternatively port a small C compiler. >> >> I also don't think that this is easier to read for people familiar to the >> CPU. And >> you have to be familiar to the CPU when writing code for it. > I initially started with a pre-processor but I soon realized that those three > instructions were the only one whose readability could have been improved by > the preprocessor itself. > >> I won't merge this. No way. > Ok, anyway I urge to share with other researchers a new version of the > standard ucode and for the moment I don't have more time to spend on the > "preprocessor". I'm sorry but the new ucode source will require the patched > assembler. As soon as I have finished some work on the N-PHY firmware I will > come back to the preprocessor. > >> The "/* duplicate some complex_imm rules to avoid parentheses" part also is >> not >> really merge-able as-is. yacc knows about operator precedence. If you want >> operator >> precedence (to get rid of parenthesis), just use this yacc feature to >> implement this. > Yes, I did it this way because "[reg|mem] << imm" is not assembly (as you say > :-) ) and the assembler strictly checks that such syntax is used only with > "orxh".
Well, in x86, we have "mov eax, es:[bx+di]". A lot more readable than, say, "mov eax, es, bx, di". > > Regards, > -Francesco > >> >> -- >> Greetings, Michael. > > > _______________________________________________ > b43-dev mailing list > b43-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/b43-dev > -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) _______________________________________________ b43-dev mailing list b43-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/b43-dev