BeebAsm

[melchett]

There's also a COPYBLOCK <start>, <end>, <dest> command....

....I have no idea if that will actually work, but it looks as though it might.

(Note: this is a different technique to the relocdemo, which assembles to its final location but patches address references in the entry point code which will be loaded at a higher position. This makes use of the fourth parameter in SAVE, to supply a reload address.)

Can confirm this works beautifullly. Great suggestion and needed for something I have.

[SteveF]

There's also a COPYBLOCK <start>, <end>, <dest> command....

....I have no idea if that will actually work, but it looks as though it might.

(Note: this is a different technique to the relocdemo, which assembles to its final location but patches address references in the entry point code which will be loaded at a higher position. This makes use of the fourth parameter in SAVE, to supply a reload address.)

Can confirm this works beautifullly. Great suggestion and needed for something I have.

You're right, thanks, that works really well! I've switched to using this instead of the new OPT stuff in my code. Bit disappointing in a way but it is better.

[sweh]

Is there a way in beebasm to abort assembly if the beebasm version is too old?

For example, if I want to use a syntax that only works in 1.09 onwards then I'd like for the source to have a "Needs 1.09" command at the front, so anyone trying to assemble the code with an older version will be told their assembler is out of date.

I don't _think_ there is, and I don't think the current version is exposed...

[SteveF]

Is there a way in beebasm to abort assembly if the beebasm version is too old?

For example, if I want to use a syntax that only works in 1.09 onwards then I'd like for the source to have a "Needs 1.09" command at the front, so anyone trying to assemble the code with an older version will be told their assembler is out of date.

I don't _think_ there is, and I don't think the current version is exposed...

I don't think there is either, but this seems like a good idea - it would be trivial to add a new constant in the SymbolTable constructor in the theoretically upcoming 1.10 release. What should we call it? BEEBASM_VERSION, and have it be 110 for 1.10 etc?

Stating the obvious really, a half-decent compromise to check for 1.09 might be:

Code: Select all

ASSERT TRUE ; if this fails, you have an old beebasm; please upgrade to 1.09 or later

with the comment there to guide anyone hitting the error.

In Ozmoo I ended up parsing the beebasm help output to check the version but that's pretty fiddly.

Edit: It's a little tricksy but I think this will work to check for 1.09:

Code: Select all

; ASSERT is a command in beebasm 1.09 or later, so this macro can only be invoked in
; 1.08 or earlier.
MACRO ASSERT n
    ERROR "You're using beebasm 1.08 or earlier; please upgrade to 1.09 or later"
ENDMACRO

; No-op on beebasm 1.09 or later, invokes ASSERT macro on beebasm 1.08 or earlier.
ASSERT TRUE

[sweh]

Ha! That ASSERT macro trick is clever. Works nicely for 1.09.

Since tests can handle real numbers, why not allow the version number to be 1.10 ? Then "ASSERT BEEBASM_VERSION >= 1.10" becomes pretty readable code.

[SteveF]

Ha! That ASSERT macro trick is clever. Works nicely for 1.09.

Thanks!

Since tests can handle real numbers, why not allow the version number to be 1.10 ? Then "ASSERT BEEBASM_VERSION >= 1.10" becomes pretty readable code.

That's a good idea, although it stirs my latent paranoia with floating point comparisons. I am guessing it will always be fine, because <handwave>the same C library will probably be doing the string->float comparison when compiling beebasm with its hard-coded "I am X.Y" constant and when doing the string->float comparison at assembly time, and the conversion is probably all standardised by IEEE 754 and/or the language standard anyway</handwave>. (I'm thinking of "ASSERT BEEBASM_VERSION == 1.10" as well as >=, FWIW - it probably doesn't make much of a difference one way or another.)

If anyone with more confidence about floating point than me would like to opine one way or another, I will look at making this change on the proposed-updates branch.

[BigEd]

ooh, difficult floating point territory! The very fact that you might need to reason and test very carefully is a bad sign, I think. Is a string comparison possible?

[daveejhitchins]

Is it possible to round the value to 1 decimal point (or whatever number you need) before the comparison?

Dave H.

[BigEd]

You could, I think, compare against 1.0801 or similar. Or 1.0899 if that felt preferable.

What's important is to avoid the need for an exact equality.

[tricky]

Personally, I would go with the 110, it leaves 89 updates before v2 comes along, but is the comparison in float anyway?

[BigEd]

Oh, I missed that possibility, that the version isn't yet encoded in any way - so yes, integers are much better behaved!

[sweh]

Just from a usability perspective, "ASSERT BEEBASM_VERSION >= 110" may lead to confusion among newer users. I've seen it before; "I don't see version hundred and ten anywhere; just version one" type confusion. (Maybe I've just had to deal with a worse class of idiot than other people ).

If we're going to go with integer version numbers then perhaps a new command ("REQUIRE_VERSION >=1.10" ?) which can do string conversion into integer for the comparison behind the scenes. It could also produce a better error message ("To assemble this you need beebasm version >=1.10; you have version x.yz"). Older versions of beebasm would clearly fail, but even then the REQUIRE_VERSION should make it clear what's wrong

[SteveF]

ooh, difficult floating point territory! The very fact that you might need to reason and test very carefully is a bad sign, I think. Is a string comparison possible?

Well, maybe - but I am very edgy around floating point numbers, so it may just be me. As per my handwave I suspect it would actually be fine in practice.

I don't think beebasm really does string comparisons; I think there's a historical consensus that strings as first class values in beebasm would be smashing, but no one has felt up to implementing them yet.

Just from a usability perspective, "ASSERT BEEBASM_VERSION >= 110" may lead to confusion among newer users. I've seen it before; "I don't see version hundred and ten anywhere; just version one" type confusion. (Maybe I've just had to deal with a worse class of idiot than other people ).

This is a good point. Also, any kind of "let's allow for a bit of fuzz when testing a floating-point BEEBASM_VERSION to be safe" strategy by writing "ASSERT BEEBASM_VERSION >= 1.099" to test for 1.10 or better is going to be confusing for users, I think.

If we're going to go with integer version numbers then perhaps a new command ("REQUIRE_VERSION >=1.10" ?) which can do string conversion into integer for the comparison behind the scenes. It could also produce a better error message ("To assemble this you need beebasm version >=1.10; you have version x.yz"). Older versions of beebasm would clearly fail, but even then the REQUIRE_VERSION should make it clear what's wrong

This doesn't seem like a bad idea, but I'm not feeling too enthused about writing the code.

We could perhaps compromise with two "integer" values BEEBASM_MAJOR_VERSION (1 in 1.10) and BEEBASM_MINOR_VERSION (10 in 1.10) provided by beebasm itself. You (a generic you, not sweh particularly) could then write:

Code: Select all

BEEBASM_VERSION = BEEBASM_MAJOR_VERSION + BEEBASM_MINOR_VERSION / 100
ASSERT BEEBASM_VERSION >= 1.10

if you wished, and if it turns out there are lurking floating-point bogeymen you could fix it in your code - whereas once we label up a beebasm 1.10 we can't easily change it without confusing things.

[BigEd]

Splitting the version into major and minor might be a good way forward, but I think you'll need to do a multiplication rather than a division. Division by 100 is very much the sort of thing which will be inexact and might cause trouble, depending on which way the error is.

[SteveF]

Splitting the version into major and minor might be a good way forward, but I think you'll need to do a multiplication rather than a division. Division by 100 is very much the sort of thing which will be inexact and might cause trouble, depending on which way the error is.

Interesting - is multiplying by 0.01 more exact than dividing by 100? That's a genuine question... Having had a quick poke on the web, perhaps the floating point example in the top answer to this stackexchange post is relevant, where the result is consistent whether multiplication or division is used, but the rounding will be subtly different in each case.

That makes me wonder if beebasm should define (using 1.10 as an example):

• BEEBASM_MAJOR_VERSION=1
• BEEBASM_MINOR_VERSION=10
• BEEBASM_VERSION=1.10

and that way the "1.10" floating point value is generated directly with no multiplication or division and can probably be safely tested via things like "ASSERT BEEBASM_VERSION>=1.10" because the floating point value on both sides is the result of a string->float (double) conversion on the string "1.10". The integer constants are there if it turns out BEEBASM_VERSION can't be tested reliably or the user just prefers them. But then we'd have BEEBASM_VERSION hanging around forever even if it turns out it can't be used reliably, so maybe this is a bad idea and beebasm should just provide the first two of those constants.

[BigEd]

Ah good point you might hope that the same expression would get the same inexact value both times.

[Rich Talbot-Watkins]

Internally BeebAsm just stores all numerical values as doubles, so there'll be the usual precision problems with representing decimal numbers. Expecting an exact comparison with 1.10 to work would be relying on the compiler generating the same binary representation of the constant 1.10 as the runtime when parsing the text "1.10" in the assembler input. Perhaps that's reliable, but I wouldn't want to bet my life on it! I would always lean on integers for this kind of functionality.

[TobyLobster]

I’ve not been following BeebAsm version numbering but In general I think of 1.10 as the tenth minor revision and 1.1 as the first, but they are the same when expressed as floating point numbers. It could be better to check both major and minor integers.

[tricky]

It would probably be fine, but many GL games broke when going to v2.00 as many games only checked the minor version!

[julie_m]

I'm surprised JGH hasn't popped along to tell you sternly never to rely on checking version numbers but always to check for features directly!

Seriously, it's not bad advice; it'll come as second nature anyway, if you were developing JavaScript web apps in the days of Internet Explorer. *shudder*

[ctr]

Another common error in version checking is to write something like (BEEBASM_MAJOR_VERSION >= 1 AND BEEBASM__MINOR_VERSION >= 10), which fails on version 2.01.

(ASSERT BEEBASM_VERSION >= 110) might confuse some people initially but once you understand it, it is simple and lacks footguns. It could even be renamed to BEEBASM_VERSION_TIMES_100! But I do think it's the least bad option.

[sweh]

I'm surprised JGH hasn't popped along to tell you sternly never to rely on checking version numbers but always to check for features directly!

As far as I can tell, BeebAsm doesn't have that sort of capability though. If my code had "FOO =? 100" then with an old version of beebem you just get an error and no help on how to fix it. A version check would at least help the person doing the build understand that they've got to upgrade.

[sweh]

(ASSERT BEEBASM_VERSION >= 110) might confuse some people initially but once you understand it, it is simple and lacks footguns. It could even be renamed to BEEBASM_VERSION_TIMES_100! But I do think it's the least bad option.

Since VERSION already exists as a string, and we've done 2-digit subversion (eg 1.08) then probably just a simple string comparison would work using string.compare()... but I'm not a C++ coder so I might be wrong

[ctr]

Another common error in version checking is to write something like (BEEBASM_MAJOR_VERSION >= 1 AND BEEBASM__MINOR_VERSION >= 10), which fails on version 2.01.

(ASSERT BEEBASM_VERSION >= 110) might confuse some people initially but once you understand it, it is simple and lacks footguns. It could even be renamed to BEEBASM_VERSION_TIMES_100! But I do think it's the least bad option.

On second thoughts... someone could write (BEEBASM_VERSION / 100 >= 1.10), which would have the floating point issue. Every solution has its downsides.

[ctr]

I've added string value support with VAL, EVAL, STR$, LEN, CHR$, ASC, MID$, STRING$, LOWER$, UPPER$ and ASM.

LOWER$ and UPPER$ change case. ASM takes a string and assembles it. The rest duplicate BBC BASIC functions.

You can see the updated documentation or download the Windows exe.

This exe includes all the proposed changes for version 1.10 (as documented at the above link), not just the string changes.

It's quite an extensive change so it would be great if people could try it out. In particular, it ought to assemble all existing code without any differences. (David Given's bogomandel and Kieran's Prince of Persia have both been tested.)

Thanks to SteveF for testing and very helpful design feedback.

[0xC0DE]

Really useful, can't wait to try this out!

[VectorEyes]

It assembles and runs Evil Influences fine.

Now to take a look at all this lovely new functionality! Thanks for all the changes.

[lovebug]

heres a small bit of code and the listing it generates

Code: Select all

org	page8000
.swramStart
	skip 16
.chrTable
	incbin "img-font.bin"
.chrTableEnd

Code: Select all

.swramStart
     8000
.chrTable
.chrTableEnd

you can see that swramStart address label is generated but chrTable chrTableEnd address labels are missing, i have a lot of incbins one after the other and im not getting any address lables

however i can work around this problem by adding skip 0

Code: Select all

org	page8000
.swramStart
	skip 16
.chrTable
	skip 0
	incbin "img-font.bin"			; load font table into memory
.chrTableEnd
	skip 0

Code: Select all

.swramStart
     8000
.chrTable
     8010
.chrTableEnd
     810F

so my question is have i missed some command that enables address label output ?

thanks

[Rich Talbot-Watkins]

so my question is have i missed some command that enables address label output ?

No, I don't think so - when I originally wrote BeebAsm, I added verbose output as an afterthought, because I had never used it or needed it. Probably the INCBIN command should add the address it's INCBINning to, maybe along with the first few bytes in hex with a "...", or even all of them!

[lovebug]

ah thanks