BeebAsm

[jgharston]

This came up in a discussion at ABUG. Where can the latest BeebAsm be downloaded, with the updates discussed over on the RetroSoftware forum. Things like -Dsymbol on the command line, IFDEF, couple of other things.

Sites such as https://github.com/ZornsLemma/beebasm/t ... high-order still have version 1.8 from five years ago.

[sweh]

It's the right tree, but you may need to select a different branch. I don't think SteveF has merged them into "master". eg https://github.com/ZornsLemma/beebasm/b ... mmands.cpp is from September and is on the "puttext" branch.

He may be using "my-proposed-updates" as the staging branch; https://github.com/ZornsLemma/beebasm/t ... ed-updates

[kieranhj]

A few months ago I manage to bag the stardot organisation name for use on GitHub. We can use this as the "official" repository for shared tools for the Acorn community and suchlike: https://github.com/stardot.

We can fork one of the existing BeebAsm repos but ideally the repo can be moved wholesale if there is an accepted "master" currently residing in a personal account. This way all existing forks etc. are preserved.

[kieranhj]

Looks like Tom Seddon has the "semi-official" repo for BeebAsm: https://github.com/tom-seddon/beebasm/branches, at least according to this RS thread.

But SteveF is by far and away the most recent and regular contributor to the project!

[simonm]

Steve has made some excellent additions to BeebAsm, which would be great to merge into master. Moving the repo to the stardot Github makes a lot of sense.

[SteveF]

Thanks for your kind words guys.

I'd be happy to see the master moved to the stardot github, but I think the decision ultimately rests with Rich (as the author) and Tom (as owner of the semi-official repo).

sweh is right that most of the changes I've worked on can be found on https://github.com/ZornsLemma/beebasm/t ... ed-updates, but note that this doesn't include some patches which didn't seem ready. Off the top of my head, and possibly not exhaustive or even correct :

• the "show cycle counts on output" patch isn't on there as I haven't got round to reworking it to take account of cycle stretching yet
• the defining of labels on the command line, ifdef etc isn't on there - it's missing elifndef (probably easy to add, however), there's some odd behaviour noted in the thread here and discussion seemed to fizzle out. (Credit where it's due - a big chunk of this is sweh's code anyway.) ETA: I also note that Rich had some reservations about IFDEF in that thread, which made me reluctant to push that approach. Maybe we should start a separate thread if anyone wants to discuss this?

I've been meaning to merge some of the changes from my own repo into the proposed-updates branches in Tom's repo anyway, but I've got another project on the go I'm trying to finish first; I hope to get that tied up in the next week or two, but I've been saying that for a while. For my own convenience in developing patches as I need to scratch an itch in BeebAsm, the my-proposed-updates branch doesn't have a very clean history; I'd want to tidy up each feature and merge it to Tom's repo as a single hopefully-bug-free commit so it's not simply a question of merging that branch over as-is. The end result would be fine, but the history would be ugly.

ETA: It would be good, if we could get everything merged over nicely, to bump the version number too.

[SteveF]

Hi all,

I've tidied up and merged all (I hope) of the fixes which were on the my-proposed-updates branch in my own repo and they can now been seen in Tom's repo here: https://github.com/tom-seddon/beebasm/t ... ed-updates

This doesn't have cycle counting or the 'ifdef' changes (which weren't on my-proposed-updates either).

Cheers.

Steve

[Prime]

Is this still the place to get the latest version? As the last post is over a year old

I could really do with having some way of specifying symbols on the command line.

Cheers.

Phill.

[kieranhj]

Is this still the place to get the latest version? As the last post is over a year old

I could really do with having some way of specifying symbols on the command line.

BeebAsm has now been "officially" moved to the Stardot GitHub repo: https://github.com/stardot/beebasm but I don't think all of the proposed changes to date (several years worth) have been rolled up into a new official release yet. So we're still technically on 1.08.

[tricky]

I do that by writing a file that defines them and then includes the real file (iirc).

[Prime]

I do that by writing a file that defines them and then includes the real file (iirc).

The problem is you need 2^n files where n is the number of options. That's only for binary options too, if you had a source file you wanted to build for several platforms, it would actually be worse. It's ok if you only want to build something that has one option turned on or off, but rapidly gets out of control beyond that.

Cheers.

Phill.

[tricky]

I write them to a temporary file, so it is always the same file and only lives for a few seconds.
In dos it looks something like:

echo. >tmp.asm
:loop
if ""=="%1" goto :done
echo.%1=%2 >>tmp.asm
shift /1
shift /1
goto :loop

:done
echo.INCLUDE "game.asm"
beebasm.exe tmp.asm

It is then run with:

build.bat ver 2 debug 1

I wrote this ages ago and haven't looked at it since, so I may be miss-remembering.

[SteveF]

Kieran is right about the status of the stardot repo version of github (assuming nothing's changed since I last looked). The proposed-updates branch there doesn't include the ability to define symbols on the command line though, so merging it wouldn't make any difference.

You could try building the version here in my repo: https://github.com/ZornsLemma/beebasm/t ... a282f574bf There's a thread on RetroSoftware discussing this, including some examples of its use: http://www.retrosoftware.co.uk/forum/vi ... 11e16fe98f It's mainly sweh's work with some of my fiddling on top of it. I think the big reason this never got finished off and merged into my proposed updates branch was the slightly counterintuitive behaviour discussed in the RS thread. The thread just sort of died out without anyone strongly advocating for or against the inclusion of this change, so if people are interested now we can perhaps pick this up again

[kieranhj]

It's mainly sweh's work with some of my fiddling on top of it. I think the big reason this never got finished off and merged into my proposed updates branch was the slightly counterintuitive behaviour discussed in the RS thread. The thread just sort of died out without anyone strongly advocating for or against the inclusion of this change, so if people are interested now we can perhaps pick this up again

Would it be worth using this thread (or a new one) to list out the proposed changes in that branch, and any decision points that need to be made by Rich and/or the BeebAsm dev community, so we can get the version updated to 1.09 and start from a known good baseline? Sorry to put more work on you but I'm guessing either sweh or yourself are the most knowledgeable in this area.

[ctr]

I've had a bash at summarising that RS thread.

The requirements seem to be:

1. Allow conditional compilation;
2. with options that can be overridden on the command-line;
3. or overridden in an outer asm file that includes the main asm file.

The difficulties were:

1. Attempting to use a symbol that might have been defined but hasn't been will give an error.
2. Attempting to define a symbol that might have been defined and has been will give an error.
3. Mutable symbols and/or the ability to detect undefined symbols break one of the core assumptions of beebasm: that the two passes will behave the same. This is likely to lead to subtle bugs in beebasm, and difficult to understand behaviour for end-users.

There were three main proposed changes.

1. RichTW suggested that assignments to symbols defined on the command-line should be silently ignored. This elegantly sidesteps the difficulties and requires no new syntax but doesn't support requirement 3.
2. sweh suggested IFDEF but difficulty 3 is unavoidable.
3. sweh also suggested conditional assignment and jgharston suggested a similar approach with different syntax. This is easy to implement and seems to avoid all the problems. However, it was rejected in favour of IFDEF but it's not clear why. Possibly because the problems with IFDEF weren't obvious at that point.

So I implemented conditional assignment based on SteveF and sweh's -D code, somewhat simplified because it no longer keeps track of the source of symbols.
https://github.com/mungre/beebasm/commi ... e5c4ff4601

It uses the slightly modified syntax:

DEBUG=?0

which assigns 0 to DEBUG if it doesn't already have a value. As far as I can see this allows you to do everything you can usefully do with IFDEF but has none of the downsides. Except maybe being a bit ugly.

Does anyone have a use case this doesn't meet?

[SteveF]

Would it be worth using this thread (or a new one) to list out the proposed changes in that branch, and any decision points that need to be made by Rich and/or the BeebAsm dev community, so we can get the version updated to 1.09 and start from a known good baseline?

Sure. Looking over the history of the proposed-updates branch, the new features are:

• Scope-jumping labels added, building on the existing beebasm scopes feature - you can write .^foo to define a label in the parent scope or .*foo to define a label in the global scope. This allows scopes to be used more freely, as you can expose selected labels within them to the rest of the code.
• SAVE allows you to set the high bits on load/exec addresses (which determine whether the resulting file will load into the host or parasite) on the generated SSD
• Option to allow Visual C++-style error messages
• Option to require whitespace between mnemonics and their labels, i.e. disallow things like "ck=&900:STAck" as a way to write "STA &900". The payoff for turning this option on is that you can then define macros with names which start with mnemonics ("macro stack:pha:txa:pha:tya:pha:endmacro"). This is off by default to preserve compatibility with BBC BASIC's behaviour.
• New PUTTEXT command - like PUTFILE but the file is converted from CR, LF, CRLF or LFCR line endings on the host to CR line endings on the SSD.
• New "CPU" psuedo-constant, allowing you to determine whether the "CPU 0" (6502) or "CPU 1" (65C02) directive is currently in effect. This allows you to write a macro which uses 65C02 instructions if they're allowed in the context it's being expanded in.
• New TIME$ pseudo-function available in EQUB/EQUS to get the assembly time
• New -title command line option to set the SSD title
• RANDOMIZE command added to seed the random number generator, allowing reproducible builds.
• Assembly errors involving macro expansions show a call stack, not just the line inside the macro which failed.
• New ASSERT command to abort assembly if an assembly-time condition isn't true
• PUTBASIC tokenisation errors are made visible to the user
• ETA: PUTFILE and PUTBASIC errors show the failing PUTFILE or PUTBASIC line

and the bug fixes are:

• PUTBASIC no longer allows you to generate an invalid BASIC program if the input has an overly long line
• Duplicate filename detection when writing to the SSD had some bugs (some non-duplicates were flagged as duplicates, and some duplicates weren't detected)
• Branch instructions could sometimes generate spurious assembly failures when used inside macros with multiple labels of the same name visible. (There were several bugs in this area as part of the development of the scope jumping labels, but one of them was present in 1.08 and wasn't directly related, so I'm listing it here.)

ETA: I hope this won't distract from discussion of ctr's work on defining labels on the command line (thanks for that - I haven't taken a detailed look yet, sorry). I'll leave it up to a moderator to decide if they want to split the thread...

[FourthStone]

Nice to see some work on BeebASM which I think is a great tool.

One annoyance I have noted before is that when moving projects to another folder and trying to recompile I would get a generic error that wasn't specifically pointing to where or what the error was. Only by trial and error was I able to track down that I had an incorrect path in a PUTFILE line.

Any chance the errors could be made more clear when referenced project files can't found?

Sorry if this is not clear, if you need more details or screen grabs I can provide.

Cheers!

[tricky]

Locally I added the number of bytes that a branch was trying to do to the branch out of range error message. This lets me quickly see if it is worth trying to save a byte or two before I get to the point that I have run out of memory.

[hoglet]

I have a BeebAsm related question.

Is there any way to test if a variable is already defined in an IF expression?

I would like to use this to provide a default value, if one is not already set.

Dave

[ctr]

I have a BeebAsm related question.

Is there any way to test if a variable is already defined in an IF expression?

I would like to use this to provide a default value, if one is not already set.

Dave

The short answer is not in the current version. There is a patch to add IFDEF but this causes unavoidable problems. And there is a separate patch to add conditional assignment, which only assigns a value if the variable is undefined.

The long answer is four replies above yours!

[SteveF]

One annoyance I have noted before is that when moving projects to another folder and trying to recompile I would get a generic error that wasn't specifically pointing to where or what the error was. Only by trial and error was I able to track down that I had an incorrect path in a PUTFILE line.

Any chance the errors could be made more clear when referenced project files can't found?

This seems OK for me with the proposed-updates version - there's even an example to show it works, and I do have vague recollections of fixing this after experiencing similar problems myself:

Code: Select all

steven@nine:~/src/beebasm-stardot-tmp/beebasm$ ./beebasm -do z.ssd -i putfilenonexistentdemo.6502 
putfilenonexistentdemo.6502:7: error: Error opening file.

putfile "nonexistent", "ne", 0, 0
                                 ^

Which version are you using? Are you using the beebasm.exe file from the proposed-updates branch? If so, that hasn't been rebuilt and is just the standard version 1.08 (confusing, I admit). If you can build the proposed-updates branch for yourself please try that, or if you are using that and it still isn't working for you please post an example and I'll take a look. If you can't build your own version, I hope someone here will be able to help. (I don't have a Windows compiler set up, I'm afraid.)

[SteveF]

Locally I added the number of bytes that a branch was trying to do to the branch out of range error message. This lets me quickly see if it is worth trying to save a byte or two before I get to the point that I have run out of memory.

I've had a go at implementing this - you can see my version on the branch-size branch in my repo at https://github.com/ZornsLemma/beebasm/tree/branch-size

This is branched off the proposed-updates branch so it should include everything else on there. I've only lightly tested it but I think it's good:

Code: Select all

steven@nine:~/src/beebasm$ cat branch1.6502 
ORG &2000

.start

	lda #1
	.nop
	for i, 0, 126
		nop
	next
	bne nop
	rts

.end
SAVE "Code", start, end
steven@nine:~/src/beebasm$ ./beebasm -i branch1.6502
branch1.6502:10: error: Branch out of range. (Branch distance is -129 bytes; 1 more than the maximum -128.)

 bne nop
     ^
steven@nine:~/src/beebasm$ cat branch2.6502
ORG &2000

.start

	lda #1
	bne skip
	for i, 0, 127
		nop
	next
	.skip
	rts

.end
SAVE "Code", start, end
steven@nine:~/src/beebasm$ ./beebasm -i branch2.6502
branch2.6502:6: error: Branch out of range. (Branch distance is 128 bytes; 1 more than the maximum 127.)

 bne skip
     ^

Cheers.

Steve

[FourthStone]

Which version are you using? Are you using the beebasm.exe file from the proposed-updates branch?

Using 1.08 which reports the same as the branch version, will have to compile it I'm guessing as you've suggested... will attempt that and report back, thanks for the answer though as it's something that has caught me a few times.

[SteveF]

I've had a bash at summarising that RS thread.

Thanks! Your summary seems right to me - but this stuff makes my brain hurt, so I could be overlooking something.

So I implemented conditional assignment based on SteveF and sweh's -D code, somewhat simplified because it no longer keeps track of the source of symbols.
https://github.com/mungre/beebasm/commi ... e5c4ff4601

I've had a quick play with this. It seems to work pretty well to me and the implementation is nice and simple. I did think the syntax was a little ugly, but it really isn't that bad and it's already growing on me.

I appreciate these are things you inherited from my earlier work, so definitely not your fault, but I'd suggest that:

• We make the default value for symbols defined via '-D foo' instead of '-D foo=42' be -1 instead of 1 - that way it's a proper boolean value. I got confused during my testing when I wrote 'if not (foo)' and it didn't behave as I expected when I wrote '-D foo', because not() is a bitwise operation, so it only does the right boolean thing if values are 0 or -1.
• We allow the value specified via -D on the command line to be in hex if it's prefixed with $ or &. % for binary would also be nice but perhaps less essential. As I noted before, it would be cool to hook into the full expression parser but I think that's likely to be impractical given how the code is structured; however, I could easily imagine wanting to use -D to specify the address to assemble the code at, so I think hex is worth implementing manually.

Has anyone else tried this yet? I think it's a useful feature but I've managed to avoid having any pressing call for it myself yet, so I'm probably not the best placed to comment on how well it meets people's requirements.

[ctr]

I've had a quick play with this. It seems to work pretty well to me and the implementation is nice and simple. I did think the syntax was a little ugly, but it really isn't that bad and it's already growing on me.

Thanks for having a look. An alternative syntax could be "?=", which would maybe be a bit more readable for C programmers because of the similarity to "plus equals", etc. I started with "=?" because it was slightly easier to implement but I have no real preference.

I appreciate these are things you inherited from my earlier work, so definitely not your fault, but I'd suggest that:

• We make the default value for symbols defined via '-D foo' instead of '-D foo=42' be -1 instead of 1 - that way it's a proper boolean value. I got confused during my testing when I wrote 'if not (foo)' and it didn't behave as I expected when I wrote '-D foo', because not() is a bitwise operation, so it only does the right boolean thing if values are 0 or -1.
• We allow the value specified via -D on the command line to be in hex if it's prefixed with $ or &. % for binary would also be nice but perhaps less essential. As I noted before, it would be cool to hook into the full expression parser but I think that's likely to be impractical given how the code is structured; however, I could easily imagine wanting to use -D to specify the address to assemble the code at, so I think hex is worth implementing manually.

Agreed on both points. I also included 0x syntax for hex because $ and & are special shell characters on some platforms. % for binary is a second commit because I initially forgot about it: https://github.com/mungre/beebasm/commi ... nal-assign

[kieranhj]

This is looking great guys - what a fantastic set of features & updates. Are we close to PR'ing this to master and makng an official v1.09 release?

[ctr]

I tested the changes in your proposed-updates branch. I tested that each feature works in a couple of simple cases and that it handled any error or corner cases I could think of. I've looked at a bit of the code but I haven't reviewed any of it in detail.

PUTBASIC automatic line-numbering is missing from the feature list.

It works, and correctly complains if lines become out of order or too big.

Scope-jumping labels added, building on the existing beebasm scopes feature - you can write .^foo to define a label in the parent scope or .*foo to define a label in the global scope. This allows scopes to be used more freely, as you can expose selected labels within them to the rest of the code.

This works and it sensibly disallows scope-jumping from macros. I often want to add an additional entry-point in the middle of a subroutine so this will be very useful. And I like the syntax.

SAVE allows you to set the high bits on load/exec addresses (which determine whether the resulting file will load into the host or parasite) on the generated SSD

This works. Fun fact: there are two high bits and DFS displays addresses as 00xxxx, 01xxxx, 02xxxx or FFxxxx.

Option to allow Visual C++-style error messages

This works. -vc puts the error line in parentheses as expected.

Option to require whitespace between mnemonics and their labels, i.e. disallow things like "ck=&900:STAck" as a way to write "STA &900". The payoff for turning this option on is that you can then define macros with names which start with mnemonics ("macro stack:pha:txa:pha:tya:pha:endmacro"). This is off by default to preserve compatibility with BBC BASIC's behaviour.

This works. In general I think language feature selection is best handled at the source file level because it allows you to mix and match files using different features, and it makes explicit what features a source file uses. However, beebasm doesn't support multiple input files other than through include, and trying to mix and match language features in this context would involve a whole bunch of complex design choices. Additionally, the overwhelmingly vast majority of 6502 code I've seen is written with spaces. So I think making -w global is the right choice.

New PUTTEXT command - like PUTFILE but the file is converted from CR, LF, CRLF or LFCR line endings on the host to CR line endings on the SSD.

This works. I don't like having to supply a load address, but I know that comes from PUTFILE where I don't like it either!

New "CPU" psuedo-constant, allowing you to determine whether the "CPU 0" (6502) or "CPU 1" (65C02) directive is currently in effect. This allows you to write a macro which uses 65C02 instructions if they're allowed in the context it's being expanded in.

This works.

New TIME$ pseudo-function available in EQUB/EQUS to get the assembly time

I thought it would be useful to allow TIME$ to be assigned to a variable to get a consistent value, but then I realised that string variables aren't a thing and the consistency is built-in anyway. It would probably be helpful to document the consistency in about.txt.

New -title command line option to set the SSD title

This works. Disk titles longer than 12 characters are silently truncated.

RANDOMIZE command added to seed the random number generator, allowing reproducible builds.

This works. After calls to RANDOMIZE with the same seed it produces the same sequence of values, and different seeds produce different sequences.

Small changes in the seed typically produce no change in the first random value. I first noticed this with the default time-based seed: the first random value doesn't change often. I don't know that this matters.

Assembly errors involving macro expansions show a call stack, not just the line inside the macro which failed.

This works.

New ASSERT command to abort assembly if an assembly-time condition isn't true

This works.

PUTBASIC tokenisation errors are made visible to the user

This works. I tried over-long lines and bad string literals and both were correctly reported.

ETA: PUTFILE and PUTBASIC errors show the failing PUTFILE or PUTBASIC line

This works for PUTFILE, PUTBASIC and PUTTEXT too.

I'm afraid there's nothing actionable here except for a slight change to the TIME$ documentation. And maybe grumble about disk titles being too long.

As a beebasm user I'll be very happy to see these changes in the next version. I'll definitely use PUTTEXT, ASSERT, -title, automatic line-numbering and scope-jumping, and the improvements to the error reporting are very welcome.

[SteveF]

I tested the changes in your proposed-updates branch.

Thanks very much for going through all that! I must admit I got a bit nervous on seeing your long post and expected you'd found a lot of bugs, so I'm glad it all seemed OK.

I've tidied up about.txt and added some text about TIME$' constancy. I've also added some code to generate an error if "-title" is used to specify an over-long title. You can see this on the proposed-updates branch *in my repo* - not the stardot proposed-updates branch: https://github.com/ZornsLemma/beebasm/t ... ed-updates

Interesting observation on the random numbers - I just tried building demo.6502 a few times without the RANDOMIZE command and you're right, the first byte rarely/never changes. I really want to keep the RNG simple and giving the same results on every platform regardless of word size, which is why I chose the implementation I did (see the comments at the top of random.cpp). We could possibly get a cheap fix for this by having beebasm_srand() make a few calls to beebasm_rand() and discard the results before returning - what do you think?

It's worth noting that if we make any change to the RNG, demo.ssd will change and merges will become a little bit annoying (this is what motivated me to add RANDOMIZE in the first place!). But if we do it now and do it on proposed-updates the pain should be minimal.

This is looking great guys - what a fantastic set of features & updates. Are we close to PR'ing this to master and makng an official v1.09 release?

Thanks Kieran. I'd like to give those people (JGH? hoglet? sweh? others?) who were interested in 'ifdef'-type stuff time to comment on ctr's changes before we push them into v1.09, but personally I'm pretty happy with them. (Thanks for making the changes I requested, Charles.) Once we're happy with them we need to ensure they get a mention in about.txt (including the changelog).

I've just committed a change to my proposed-updates branch moving the various *.6502/*.bas files I've dumped in the root of the repository into the already-existing examples subdirectory. I've left demo.6502 and relocdemo.6502 in the root where they always were.

sweh's documentation fix needs to be merged; there's already a pull request for that.

Should we replace section 10 "REPORTING BUGS" of about.txt? It currently says:

There are bound to be loads. I wrote it quickly! Please help me zap all the problems by reporting any bugs to me, Rich Talbot-Watkins, at <richtw1@gmail.com>, or join the forum at <http://www.retrosoftware.co.uk>.

I'm open to suggestions but how about this:

BeebAsm was writen by Rich Talbot-Watkins but is now maintained by the members of the 'stardot' forums. The official source repository is at https://github.com/stardot/beebasm. Please post any questions or comments relating to BeebAsm on the 'Development tools' forum at stardot: http://www.stardot.org.uk/forums/viewforum.php?f=55

(Rich's e-mail address is still at the top of the file, so it isn't completely removed.)

What do people want to do about credit for their contributions? The pattern so far seems to be to mention people by name in about.txt (e.g. Thomas Harte gets a mention under the PUTBASIC command and some people get a mention in the changelog). We could stick an "acknowledgements" section in about.txt and bung it all in there.

[jgharston]

Thanks Kieran. I'd like to give those people (JGH? hoglet? sweh? others?) who were interested in 'ifdef'-type stuff time to comment on ctr's changes before we push them into v1.09, but personally I'm pretty happy with them

Probably because it's 2:30am and I've been coding all night, but I can't find where the 'ifdef' update is.

[SteveF]

Probably because it's 2:30am and I've been coding all night, but I can't find where the 'ifdef' update is.

Sounds like a fun night!

The details - it isn't actually 'ifdef', so that was a confusing way to describe it, sorry - are in ctr's post in this thread at "Tue Feb 06, 2018 5:14 pm" (ETA: with a further post at "Sun Feb 11, 2018 4:13 pm"). Here's a noddy example I knocked up to test it:

Code: Select all

steven@nine:~/src/beebasm-mungre-tmp/beebasm$ cat baz.6502
ORG 0x2000

foo =? 42

baz = %1001

fast =? 0

.start

   lda #<foo
   ldx #bar
   ldy #baz
if fast == 0
   .loop
      dex
      bne loop
endif
   jmp foo
   rts

.end
SAVE "Code", start, end
steven@nine:~/src/beebasm-mungre-tmp/beebasm$ ./beebasm -i baz.6502
baz.6502:12: error: Symbol not defined.

   ldx #bar
        ^
steven@nine:~/src/beebasm-mungre-tmp/beebasm$ ./beebasm -i baz.6502 -D bar=10 -v
.start
     2000   A9 2A      LDA #&2A
     2002   A2 0A      LDX #&0A
     2004   A0 09      LDY #&09
.loop
     2006   CA         DEX
     2007   D0 FD      BNE &2006
     2009   4C 2A 00   JMP &002A
     200C   60         RTS
.end
Saving file 'Code'
Processed file 'baz.6502' ok
steven@nine:~/src/beebasm-mungre-tmp/beebasm$ ./beebasm -i baz.6502 -D bar=10 -D foo=21 -v
.start
     2000   A9 15      LDA #&15
     2002   A2 0A      LDX #&0A
     2004   A0 09      LDY #&09
.loop
     2006   CA         DEX
     2007   D0 FD      BNE &2006
     2009   4C 15 00   JMP &0015
     200C   60         RTS
.end
Saving file 'Code'
Processed file 'baz.6502' ok
steven@nine:~/src/beebasm-mungre-tmp/beebasm$ ./beebasm -i baz.6502 -D bar=10 -D foo=21 -D baz=4 -v
baz.6502:5: error: Symbol already defined.

baz = %1001
^

Note that you *must* define 'bar' on the command line, you *may* define foo on the command line and you *cannot* define 'baz' on the command line.

I'm sure ctr will chip in if I've missed something.