From: Groepaz (groepaz_at_gmx.net)
Date: 2000-12-12 20:14:40
Ullrich von Bassewitz wrote:
> The .repeat command does have a loop counter. See my example posted earlier to
> the list.
ah, ok then ;)
> 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.
well, i DO if i can, but that still means that there are cases when c-style
macros would fit the job just perfectly fine
> 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!
yeah exactly =)
> 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.
well, thats what i wanna avoid ... i am infact 'cleaning up' my c64 code
library from all that sort of things since i want ppl to be able to compile
it without needing to get hundreds of obscure tools.
> 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.
uhm really? oooops 8=) hehehe.... then why the hell didnt i get it working for
me? eeehrm ;=)
> > 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.
standard.inc:
bla=1
dont work:
foo.asm:
.include "standard.inc"
.proc
.if (bla=1) ; 'bla constant expression expected'
.byte $00
.endif
.endproc
works:
foo.asm:
.include "standard.inc"
.if (bla=1)
.proc
bla=1
else
.proc
.endif
.if (bla=1)
.byte $00
.endif
.endproc
> 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.
thats what i expected... but look above :/
> > 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.
i generally agree on this, aslong as those missing features can be 'emulated'
using other features in an exceptable way. (which is eg. not the case regarding
the .rept vs recursive macros topic)
> > - 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.
err 'dd' ? tell windoze peeps to use *nix tools ;=D
no really, while this may be exceptable to achive the equivalent to eg
.incbin "file1",0,4096,2
.incbin "file2",1,4096,2
..it becomes painful to create a replacement for
.macro chunk a
.incbin "file1",a*10,256,2
.if (a>0)
chunk a-1
.endif
.endmacro
chunk 5
chunk 7
chunk 8
chunk 5
chunk 7
chunk 8
> > - 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).
can't await to check those then ;=D
> > - 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.
cool to hear that ;=)
> > - 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.
mmh 'a hack' ? no, thats why i said '16 bit integer variables' .... since those
can either represent
a) 16bit unsigned 'addresses'
b) 16bit signed 'variables'
c) 8.8 signed fixed-point 'variables'
math functions should take and return variables in 8.8 format, whereas the user
would be responsible to properly convert them forth and back.
.macro table origin,range,length
.rept length
; do whatever math here
.byte origin+((.sin(loopcount<<8)/($100/range))>>8)
.endrept
.endmacro
table $80,$100
_I_ can't actually think of any case were the use of floats would make real
sence (as in, would be superior to using fixed point) ...
regards
gpz
--
----------------------------------------------------------------------
/^\
\ /
ASCII RIBBON CAMPAIGN X AGAINST HTML JUNK MAIL
/ \
----------------------------------------------------------------------
___ ___ .___________________ .___________ _______.
c=64 / | \| \__ ___/ \ \_ _____/ \ \ groepaz
cgb / ' \ | | | / \ / \ | __)_ / | \
psx \ . / | | |/ ' \| \/ | \
dc \___|_ /|___| |____|\____|__ /_______ /\____|__ /
\/ ' \/ \/ \/
http://www.hitmen-console.org Hitmen WWW Headquarters
http://fly.to/hitmen-groepaz my personal playground
----------------------------------------------------------------------
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:37 CET