Can confirm this works beautifullly. Great suggestion and needed for something I have.Rich Talbot-Watkins wrote: ↑Thu Dec 17, 2020 12:01 pm 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.)
BeebAsm
Re: BeebAsm
Re: BeebAsm
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.melchett wrote: ↑Mon May 24, 2021 2:45 pmCan confirm this works beautifullly. Great suggestion and needed for something I have.Rich Talbot-Watkins wrote: ↑Thu Dec 17, 2020 12:01 pm 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.)
Re: BeebAsm
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...
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...
Rgds
Stephen
Stephen
Re: BeebAsm
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?sweh wrote: ↑Fri Jun 18, 2021 12:10 am 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...
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
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
Re: BeebAsm
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.
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.
Rgds
Stephen
Stephen
Re: BeebAsm
Thanks!
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.
Re: BeebAsm
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
- Posts: 7878
- Joined: Wed Jun 13, 2012 6:23 pm
- Location: Newton Aycliffe, County Durham
- Contact:
Re: BeebAsm
Is it possible to round the value to 1 decimal point (or whatever number you need) before the comparison?
Dave H.
Dave H.
Available: ARA II : ARA III-JR/PR : ABR : AP5 : AP6 : ABE : ATI : MGC : Plus 1 Support ROM : Plus 3 2nd DA : Prime's Plus 3 ROM/RAM : Pegasus 400 : Prime's MRB : ARCIN32 : Cross-32
Re: BeebAsm
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.
What's important is to avoid the need for an exact equality.
Re: BeebAsm
Personally, I would go with the 110, it leaves 89 updates before v2 comes along, but is the comparison in float anyway?
Re: BeebAsm
Oh, I missed that possibility, that the version isn't yet encoded in any way - so yes, integers are much better behaved!
Re: BeebAsm
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
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
Rgds
Stephen
Stephen
Re: BeebAsm
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.
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.sweh wrote: ↑Sat Jun 19, 2021 12:53 pm 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 doesn't seem like a bad idea, but I'm not feeling too enthused about writing the code.sweh wrote: ↑Sat Jun 19, 2021 12:53 pm 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
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
Re: BeebAsm
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.
Re: BeebAsm
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.BigEd wrote: ↑Sat Jun 19, 2021 3:46 pm 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.
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
Re: BeebAsm
Ah good point you might hope that the same expression would get the same inexact value both times.
- Rich Talbot-Watkins
- Posts: 2054
- Joined: Thu Jan 13, 2005 5:20 pm
- Location: Palma, Mallorca
- Contact:
Re: BeebAsm
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
- Posts: 618
- Joined: Sat Aug 31, 2019 7:58 am
- Contact:
Re: BeebAsm
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.
Re: BeebAsm
It would probably be fine, but many GL games broke when going to v2.00 as many games only checked the minor version!
Re: BeebAsm
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*
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*
Re: BeebAsm
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.
(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.
Re: BeebAsm
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.
Rgds
Stephen
Stephen
Re: BeebAsm
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
Rgds
Stephen
Stephen
Re: BeebAsm
On second thoughts... someone could write (BEEBASM_VERSION / 100 >= 1.10), which would have the floating point issue. Every solution has its downsides.ctr wrote: ↑Sat Jun 19, 2021 10:16 pm 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.
Re: BeebAsm
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.
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.
Re: BeebAsm
Really useful, can't wait to try this out!
0xC0DE
"I program my home computer / Beam myself into the future"
Follow me on Twitter
Visit my YouTube channel featuring my games and demos for Acorn Electron and BBC Micro
"I program my home computer / Beam myself into the future"
Follow me on Twitter
Visit my YouTube channel featuring my games and demos for Acorn Electron and BBC Micro
-
- Posts: 572
- Joined: Fri Apr 13, 2018 2:48 pm
- Contact:
Re: BeebAsm
It assembles and runs Evil Influences fine.
Now to take a look at all this lovely new functionality! Thanks for all the changes.
Now to take a look at all this lovely new functionality! Thanks for all the changes.
Re: BeebAsm
heres a small bit of code and the listing it generates
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
so my question is have i missed some command that enables address label output ?
thanks
Code: Select all
org page8000
.swramStart
skip 16
.chrTable
incbin "img-font.bin"
.chrTableEnd
Code: Select all
.swramStart
8000
.chrTable
.chrTableEnd
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
thanks
- Rich Talbot-Watkins
- Posts: 2054
- Joined: Thu Jan 13, 2005 5:20 pm
- Location: Palma, Mallorca
- Contact:
Re: BeebAsm
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!