Thanks to some feedback from Richard (tricky), I've released a new version of BeebAsm, which can be downloaded here.

Main change is a bugfix to EQUD which generated the wrong object code when passed values greater than &7FFFFFFF.

Also new is an ERROR directive for explicitly aborting assembly (use in conjunction with IF...ENDIF to catch error conditions), and a -opt command line switch which sets the *OPT 4,n of the generated disc image.

There are a few other issues (case-sensitivity in assembler mnemonics for one) which I'll look at when I have more time. I'm also thinking about removing the restriction which makes variables non-reassignable (so hardly "variables" really...) but I need a little time to think how to do that.

I haven't had any feedback so far on any problems with macros, so I'll assume for the moment that their implementation is flawless I certainly haven't had any trouble with them so far.

Trying to catch up ...

I wasted most of this eve trying to work out how to get my MinGW environment working again ... it worked fine before I left for my big trip. What was that magical combination of environment variables required?

But I can confirm BeebAsm 1.06 builds fine under Linux, MinGW gcc-4 (Command Prompt) and MinGW gcc-4 (MSYS). However the platform auto-detection fails in both MinGW environments so you have to specify the PLATFORM variable. Auto-detection does work in Linux. I'm sure before I left, it was only the MSYS shell on my particular laptop which required the platform to be specified (as it defaulted PLATFORM to "MCD" for some bizarre HP-related reason).

Ah, well. So long as it's compilable ... now I'm off to (finally) try the BASIC tokenising out properly!

Sam.

Oh, forgot to add - are there any compilation instructions in with the package? Might be worth including those including the whole PLATFORM variable stuff. I know you can just do make and get some info, but might be worth adding for beginners.

The wiki page is also a bit out of date - if you update the package with your preferred instructions, I don't mind doing the wiki, if you want some help.

Sam.

How very dare you!!!!

I brought it up to date with my own fair, erm, fingers - just the other day! (It's quite likely that I've forgotten something though).

I don't have the MinGW shell installed (I always launch gcc from a regular command prompt), but if I have time, I'll try and figure out what's wrong with that. Compilation instructions are a good idea, I'll add them into the readme.

The BASIC tokeniser stuff (PUTBASIC) in particular is really untested, particularly with regards to error messages - so feel free to stress test it and report any problems back.

Cheers,
Rich

I'm referring to the Downloads section which is where people are most likely to end up, unless they're following the forums.

It refers to separate Linux and Mac build processes and refers to v1.04 and v1.01 for them, respectively.

I suspect you probably just want to replace that with a generic set of compilation instructions, describing the use of the PLATFORM variable ... and maybe mention it should work on MinGW too.

I would imagine the same set of compilation instructions being in the package.

I could write them generic ones from scratch, but I figured you'd prefer to document your specific way.

As for the BASIC stuff - I've got a working environment ... so I'll start testing it and shout if I find anything!!

Sam.

P.S. As for the MinGW auto-detection, I'm not complaining, really, so long as it compiles. But it's not under msys that I was drawing attention too - due to my HP laptop, that didn't work before. This is from a basic Windows Command Prompt - and I thought the auto-detection /did/ work from there when I tested a pre-1.05 build.

I'm using it under Linux, anyway, and I expect most Windows users to just use your binary anyway. Testing it compiles under MinGW is just for completeness, really.

Just an observation on the latest release: it looks like VC++ libraries (MSVCP100.DLL) are needed to run the 1.06 version. I assume you're no longer statically linking in the dll's, as these did not need to be installed for V1.04 (& I currently don't have them installed ).

Ahhh this is an interesting Windows-ism - I didn't realise that this DLL wasn't present in a standard Windows installation (i.e. one which doesn't have Visual Studio installed on it).

I guess I'll have to update the documentation to say that the MS Visual C++ 2010 Redistributable Package should be installed from here, if it throws an error saying it can't find the DLL.

The difference, by the way, is that the 1.04 executable was created with MinGW (back in the days when it was easy to statically link with the C++ runtime libs), whilst the 1.06 executable was created with MS Visual Studio. The latest releases of MinGW just seem kinda temperamental (and also, by default, seem to want to dynamically link the C++ runtime libraries - which doesn't work), as discussed here.

If anyone knows how I should be invoking the linker in MinGW with GCC 4, so that C++ runtime libs are dynamically linked ok, please let me know! At the moment, I use a barely-documented command line switch to statically link the runtime libs when compiled in MinGW, but this makes the executable huge.

Can't help with the linking question, I'm afraid! No big deal to install the libs, once the MS Download Center eventually played ball [spent hours trying to download 'em, long before you posted their link [maybe it's a Firefox .vs. IE thing ]]. Anyways, got there in the end! I'm now Macro-enabled

You're probably better off providing the non-statically-linked .exe, given the size difference, not to mention the world of hurt involved in MiniGW/GCC - just been catching up on that thread! Whew!

Speaking of macros, (maybe this should be in a separate thread [I'm sure Samwise will split it out if I'm out of order ]), I noticed that the macros need to be defined before you use 'em - kinda sounds like a no-brainer! But, initially I figured BeebAsm would resolve such references during a multi-pass assembly.

I was dumping my macros to the back end of my source code, but now I'm doing the smart/logical thing and have them in a "Macros File" that's included at the beginning of my source.

Once again, not a problem, I suppose I'm just stating the obvious for those of us (read: me) that don't always see the obvious. D'oh!

I'll furnish you with the technical reason why macros have to be defined before they're used - just so it doesn't look like a cop-out

BeebAsm, under the surface, works the same way as the BBC BASIC assembler (and many assemblers) in that it performs two passes of the source code. The first is like a dummy-run, which establishes the addresses of all the labels, forward-referenced or otherwise; and the second is the real thing which, hopefully, now knows the values of everything it has to.

Macros can expand to any number of instructions, which means that the assembler has to know what they expand to on the first pass, so that any subsequent labels will be assigned the correct addresses on the first pass. In fact, BeebAsm won't let you write any code that could lead to the first pass and the second pass generating code of different sizes. For this reason, the conditions in IF blocks also must be known in advance.

I'm trying to install v1.6 on a W7 64 machine. It also comes up with the msvcp100.dll missing message. I tried to install the x64 version of the C++ redistributable but to no avail. Any ideas on how to resolve this without installing on a 32 bit VM?

Have you tried installing the x86 redistributable package (as linked to above), rather than the x64 one? Visual C++ 2010 Express doesn't generate x64 code (it's one of its limitations) so it's quite likely that it needs to link with x86 DLLs.

Just tried it and it works now. Got it going under SWIFT.

I assumed that it would pick up the older version (2008) of the redistributable but it needs the 2010 one.

Working with Swift, that's promising Might not be too much work to fix the glitches that seem to be happening.

Yip, I was a bit surprised as I gathered from other forum topics this is a bit of a headache.

I took the Hello World example into a test project with beebasm & beebem. When I run the project it fires up beebem and runs the program.
Haven't tried anything else, so maybe it's too trivial....