BASM? Yes we can!

BASM may not be in the Delphi 64 preview, but a proof of concept of “BASM-for-DWS” is now available for DWScript in the SVN!

It builds upon recently introduced “language extensions”, to allow “asm” blocks, which will be pre-parsed (to allow BASM-like references to local variables), and then fed to NASM for actual assembling (which you’ll need to download).

const cOne = 1.0;
function RSqrt(x : Float) : Float;
   asm // Result := 1/Sqrt(x);
      fld x;
      fld cOne;  // could have used fld1 here
      fstp Result;


You can have multiple asm sections, intersperse them with regular code, etc.

Language extensions for DWScript

The language extension mechanism allows to hook into the compiler, and handle part of the parsing on a source file. You can add to the language without affecting the DWS compiler core itself, and if not used explicitly, language extensions won’t be compiled, referred, or otherwise impact in any way DWS.

You activate extensions per TDelphiWebScript component, by dropping the relevant extension component (a subclass of TdwsCustomLangageExtension) anywhere you wish, and linking the relevant Script component via the Script property.

More pragmatic targets for extensions would be introducing unsafe features (like DLL imports), compile-time parsed SQL, opcodes for industrial automatons/printers, introducing constructs from other languages that may not fit with the general canon of Pascal, experimenting with alien syntaxes, etc. you name it.

Notes on DWScript’s asmExtension

BASM was picked to experiment with the extension mechanism, as it’s kind of a low hanging fruit: a block delimited by asm and end, with access to the symbol table, that generates a custom expression, and whose actual parsing can be handled by a ready-made tool.

Note that the BASM part introduced here, though usable, will likely remain minimalistic, at least until Delphi 64 comes around.

The assembler uses NASM, and so supports all the instructions NASM supports, though there are a few things to keep in mind:

  • you must place nasm.exe in the same directory as your applications. Temporary files will be used during the assembly (in the temp folder). NASM may be bundled in a later version, but right now, it isn’t.
  • a semi-colon ‘;’ is expected after instructions, a colon ‘:’ after labels, and comments are regular ones (not NASM-style).
  • right now, BASM for DWS exposes constants, local variables, regular parameters (that are neither var nor const) and Result (for functions), when they are of type Integer (64bit), Float (double precision), String (pointer to the PChar) and Boolean (word).
  • DWS variables are stored in variants, its arrays are thus array of variants, though the exposed address goes to the data portion of variants.
  • the exposure mechanism is still simplistic, via defines, and if you have a local variable named ‘eax‘ f.i., it will take precedence over the similarly named register… Same goes for instructions.
  • the EBP register with offsets is used to expose variables, constants are exposed with absolute addresses (and are unified, btw), if you want to return before the exit point, you’ll have to “pop ebp” manually. As usual, you can do whatever you wish with eax, edx & ecx, other registers have to be preserved.
  • you can use @variable to get only the address of a variable, f.i. for a float variable, myfloat could be “qword [ebp-8]” and @myfloat would be “ebp-8“.
  • you can only jump and call within the asm block.

Of course, using any asm makes the script execution wholly unsafe, that’s why it’s in a language extension.

11 thoughts on “BASM? Yes we can!

  1. @Arnaud Bouchez
    Thanks, though apparently PCasm hasn’t been updated since 2004…
    I’m hoping to have a look someday at libYasm, though if yasm is still maintained, libYasm seems to have been left untended (still no dll version available f.i.)

  2. I can’t even begin to say how impressed I am with how DWScript is coming along. I intend using it in at least one major project, replacing RemObjects PascalScript, but have not yet reached a point where I need to start looking at that aspect of that particular project and so haven’t yet actually got my hands on DWS. YET.

    But everything I read about it, and the apparent speed with which the project is progressing, makes me very excited to get to that point just as soon as I can!!

    Keep it up!

  3. “Language extensions” sounds very interesting. It would be really great to “experiment with alien syntaxes” 🙂 (e.g. associative arrays)

  4. asmExtensionTest
    Syntax Error: asm error: symbol ‘ADC920h’ undefined


  5. @miab
    This error appears only on Win XP 32-bits computers (C2D, P4, D4, Atom).
    On Win Vista 32-bits(C2D, CeleronM) and Win 7 32-bits(C2D) it not appears.

  6. Indeed, but 64bit isn’t supported, also the license isn’t very clear (MPL?, public domain?), and at this point, I wouldn’t have time to support it myself even if the license allowed it, as I’d rather work on DWS.
    Still if someone were to resume support, it could be a nice way to have full integration, there even seems to be support for a variety of constructs.

  7. This seems to be some issue with NASM and floating point, it has since been worked around using a different hex format in the codegen.

Comments are closed.