Basic assembler dialects

I’m intrigued to see FOR being used for this kind of thing. I thought that LET might be more appropriate. ;-)

The last time I saw creative reuse of the for keyword was in Limbo, where it is used to define a collection of interfaces for a type. Here, the find function can operate on values of type T as long as it defines an eq method with the appropriate signature:

find: fn[T](x: T, l: list of T): list of T

    for { T => eq: fn(a, b: T): int; };

But why not add another optional argument to OPT?

why not add another optional argument to OPT?

The interpreter would be perfectly happy if the command was sP&n£?*@ – the keywords are for humans to read.

This command (primarily) specifies what device the code is for, so FOR"Z80" really couldn’t be any clearer for the human. OPT is not clearer.

How about TARGET as the keyword – unambiguous?

How about TARGET as the keyword – unambiguous?

Well TARGET certainly doesn’t engender any user confusion with the likes of a FOR loop.

Interesting idea, have you consulted with Mr Richard Russell, given that BBC SDL also implements an assembler, (as does BBC BASIC for Windows)?

[ FOR seems to be an interesting syntax though, especially, if by means of Modules you effectively got a powerful “cross-assembler”, for various architectures.

Did you also plan to implement a SWI call to convert bytecode back into basic mnemonics? (i.e a dissassembler) RISC OS at one point had a SWI to do this for ARM code to assist debugging I think. I’m not sure how straightforward a modularised approach to do this for other ARM variants by user selection would be.
(There are of course various scripts for disassembly written for 8bit processors, not so sure for other architectures like the 68000 or ia-32 architectures)

RISC OS at one point had a SWI to do this for ARM code to assist debugging I think

Always had – https://www.riscosopen.org/wiki/documentation/show/Debugger_Disassemble

There’s no reason why a disassembler couldn’t be written for any specific architecture, however the flexibility of RISC OS’ ARM disassembler may be hard to match when we’re talking about variable length opcodes (such as the 6502 or x86) because you won’t necessarily know where an instruction begins. One can make educated guesses, but it’s not as simple as backing up four bytes each time…

There are of course various scripts for disassembly written for 8bit processors, not so sure for other architectures like the 68000 or ia-32 architectures

The 6502 was pretty easy, a table of 256 instructions. It’s a little harder for the likes of 68000 or x86, but not impossible – just step through the data and interpret what you see: http://goldencrystal.free.fr/M68kOpcodes.pdf and http://ref.×86asm.net/ for instance. Also http://clrhome.org/table/ for Z80. If you want to kick it old school, try http://www.stackosaurus.com/pdp11.html!
And finally, of you ever plan to deal with toasters, bread makers, and all manner of older (pre-ARM) embedded devices, this will be invaluable: https://www.win.tue.nl/~aeb/comp/8051/set8051.html

FOR s$ AND s$ “look” odd to me, using a comma seems more natural, viz:
FOR “6502”
FOR “ARM”,“VFP2”

I’ve written loads of disassembly modules that use OSWORD 190 as the API, you pass the CPU code, the address and the data to disassemble. See http://beebwiki.mdfs.net/OSWORD_%26BE

It would be do-able to have a SWI call similar to Debugger_Disassemble that had a register to specify a CPU.

FOR s$ AND s$ “look” odd to me, using a comma seems more natural

Point taken. I blame Knuth for the over-literal literate-programming of AND.

I’ve written loads of disassembly modules that use OSWORD 190 as the API.

Hmm. The problem with that approach is that architectures have to be predefined, and there’s never enough numbers. One then runs the risk of disassembling instructions that don’t actually exist on the target. NMOS6502 is different from MOS65C02 which is different from Rockwell65C02 which is different from WDC65C02… etc.

Rick said:

the flexibility of RISC OS’ ARM disassembler may be hard to match when we’re talking about variable length opcodes (such as the 6502 or x86) because you won’t necessarily know where an instruction begins

And with something like 65816 you don’t know where the instruction ends either. For example &A0, LDY #imm, is either two or three bytes long depending on processor mode (the confusingly named X flag). Disassembling that is… impossible in general.

Alex asked:

Interesting idea, have you consulted with Mr Richard Russell, given that BBC SDL also implements an assembler, (as does BBC BASIC for Windows)?

I’ve only discussed it here, and only this week. However, one would like Basics to recognise their own platform CPU at least, and error otherwise. Then BBfW could treat FOR"x86" as a NOP and error anything else.

Although “No such opcode” is likely, false friends do exist between incompatible mnemonics (eg 6502 and Sunplus) so it would be nice to be specific. How easy it is to provide plug-in interfaces for additional assemblers on other platforms, others are better placed to judge.

I really should have learned by now to never look too closely.

How big is Basic?

In the Beeb it was 16K of course, and that included a full 6502 assembler.

ARM is less dense, and Basic V added a lot of features, so we have to shrug slightly when the first version of Arthur’s Basic was 56K. It contained an ARM2 assembler.

By RO2 it had grown slightly to 61K, and when RO3 arrived it was 65K.

The RiscPC’s RO3.50 introduced internationalisation via BASICTrans, so it grew again to 68K, but still no change to the venerable assembler.

The significant moment in this story is 3.80, the prototype Phoebe OS, and the basis for the two forks of the OS. Significant, because the assembler instruction set grew significantly for the first time, gaining MSR, MRS etc, and the FPU instructions. Even so, it was only 72K.

On the one hand

ROL did very little with Basic. By 4.39 it was still 73K. It grew appreciably in 6.20, but only because they forgot to tokenise the Messages. Oops.

On the other hand

RO5’s Basic is a development of RO3.80’s, which was 72K. The only real difference I can recall is that it gained the SIMD instructions. So it grew a bit…

I lie. It grew a lot. By 56%. Let me put that in context: The entire assembler in 3.80 is 4K – all the code, the mnemonics, the help text, all of it. 4K.

The SIMD support in RO5 grew Basic by 40K. I’m not proposing fixing it with a new one at the moment, but it needs hitting with a mallet until it’s very sorry indeed, and one tenth the size. (The developer too, probably)

Anyway, one of the nice things about Basic Assembler Dialects is that they allow the assembler to be shared between Basic and Basic64, so that’ll be a saving.

it needs hitting with a mallet until it’s very sorry indeed, and one tenth the size. (The developer too, probably)

Bad Nemo, go sit in the naughty corner. We’re short of OS developers, don’t break them.

The SIMD support in RO5 grew Basic by 40K. I’m not proposing fixing it with a new one at the moment, but it needs hitting with a mallet until it’s very sorry indeed, and one tenth the size.

If you looked, the big VFPData file (Resources:$.Resources.BASIC.VFPData, 32K) consists mostly of data tables, and about half of it (a little over 14K) consists of text that shows the syntax of each command (uncompressed). Given the VFP instruction set, how would you suggest cutting that down to “a tenth of its size”?

BTW, open question to anybody – why are these things not listed when one enters HELP [? There’s no indication that BASIC can assemble VFP or what the syntax in use is…

Talking of vantages will we ever see a 32 bit arm 7/8 version??? Please, pretty please.

How big is Basic?

The SIMD support in RO5 grew Basic by 40K

Well, whoopeedoo. Who cares?

And why should anyone care about such a piffling usage of memory thse days?

why are these things not listed when one enters HELP [

Because that help string is entirely unrelated to the data structures or state machine used by the assembler. Nothing appears because nothing has been put in the string. Which would make it bigger again, of course.

don’t break them

I forget where I read this…

Q: If, during peer review of 100 lines of code, you discover an off-by-one error in a loop, how many lines of code are suspect?

A: Everything they’ve ever written.

Please, pretty please.

Please give Martin your money. ;-)

Q: If, during peer review of 100 lines of code, you discover an off-by-one error in a loop, how many lines of code are suspect?

A: Everything they’ve ever written.

Everything I’ve ever written is definitely suspect, although I’m not aware of ever having made that particular error (that’s not to say I haven’t). Everything anyone has ever written is suspect, really – although certainly the level of suspicion varies a great deal.