From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2000-12-12 10:51:11
Hi! On Mon, Dec 11, 2000 at 11:07:46PM +0100, Groepaz wrote: > other than that, i think there might be a pretty easy fix actually, provided > you could 'overload' one of the builtin mnemonics with a 'traditional' macro. Giving a macro preference over a mnemonic is no technical problem. It may give all sort of strange errors and makes sources hard to understand (ANY instruction may be a macro), so I decided to disallow it. > well, uhm.... no this would NOT work.... look at my example again ... i am > gonna write it down like i would have expected it to work in ca65: You're right, I didn't realize this. > a) like you said, one isnt allow to modify constants (which generally is a good > thing ofcoz ;=D) - the bad thing is, that as a consequence, there's no other > kind of symbol whose value can be controlled (as in 'modified') at compile- > time. that fact makes a lot of stuff impossible, that's used frequently in > code written for eg. turbo-asm. > if you dont have some kind of these symbols, you also take most of the power > away from the .rept thing you wanna introduce ;/ The .repeat command does have a loop counter. See my example posted earlier to the list. > b) c-style macros cannot have multiple statements/lines - this is one thing > were i just ask myself 'WHY THE HELL?!' - since a lot of useful stuff can > be done in a very convinient way using c-macros that have multiple lines. > (and yes, many of them can't be done using traditional macros) C style macros were invented to allow translating sources written for some other assembler. I was payed to do this, and I didn't want to add all sorts of duplicate stuff to ca65. However, C style macros ignore scoping rules and do in general work on a very low level. So these macros have the same problems as their C counterparts. In other words: They are evil:-) Try to avoid them if you can. > d) c-style macros aren't exactly operating at 'scanner level'... again the > rgbasm handles this very nicely. i would expect them to really work as > "find and replace" - since this would again allow some nice stuff.... C style macros *are* operating at the scanner level. They are working with tokens, not strings. This is the reason why you you cannot do anything with C style macros that works on or creates invalid tokens. For example: .define 'a 'b ; ILLEGAL! Neither 'a, not 'b are legal tokens, so this will not work. If you need anything more C like, you're free to run your favorite C preprocessor over the sources before passing them to ca65. > e) traditional macros can't take strings as arguments - this again makes > various stuff impossible, for eg i wanted to create a macro that takes a > string and which would convert the argument (string) byte-per-byte to > eg petsci format. - right now i can do that for a single byte like intended, > but once you got more that a few words of text, you want real strings aswell ;=) Traditional macros *can* take string arguments, and the example for the new functions in 2.6 (example posted to the list a few days ago) did exactly what you're describing here: Working on each of the characters of a string passed as argument to the macro. > f) if you enclose a block using .proc / .endproc, other global symbols > become invisible to this block ?!? HU?! ;=D should i include my global header > files in each of these blocks ?!? nononono this can only be a bug ;) This seems to be a misinformation or I don't understand it correctly. Variables from inside the block are not visible to the outside, but variables from all enclosing lexical blocks are visible in the inside. So there's no need to include any global headers in a block, including them outside the block makes the variables visible inside, too. In general, .proc/.endproc work something like PROCEDUREs in pascal. > some more stuff.... (more like nice things i've seen elsewhere....) ;=D I'm very cautious when adding things. Featurism causes code bloat and more bugs. Adding complex stuff that one person needs once in a year is usually not a good idea. So I'm quite sceptic about new feature proposals, at least until I know, the feature is really needed, and it has the most generic form. > - extend the .incbin directive to work like > > .incbin "filename",start,end,step Someone else had proposed this feature, but I have never seen it used. As long as usage is quite rare, it may be emulated by "dd" in the makefile. > - add a simelar directive for use in macros, that works like > > .readbin "filename",pos This shouldn't be needed any longer with the new macro features (hopefully). > - introduce "compiler variables" as a new kind of symbols. these could live > in their own seperated namespace, or even coexist with other global symbols > in the top-level namespace. compiler variables may be 16bit integers (wether > signed or unsigned may depend on how the user works with them) that can be > modified at any time and multiple times at compile time. These will be in the next version (the one after 2.6). I fact, after my last mail to the list (stating that constants may not be modified), I had almost the same idea than what you're describing here. > - make some basic math/trig functions available ... democoders will > love you for ever ;=D While the addition may be useful, as long as there is no support for floats in the assembler, adding this feature would always be a hack. Regards Uz -- Ullrich von Bassewitz uz_at_musoftware.de
This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:37 CET