Extended version of print macro.

[hutch--]

I am just playing with the idea of an extended version of print called print_ex. This is the macros so far.

Code Select Expand


  ; ----------------------------------------------------
  ; bytecount must be set at assembly time as a constant
  ; ----------------------------------------------------
    set_printex_buffer MACRO bytecount
      @@_print_ex_buffer_size_@@ equ <bytecount>
    ENDM

    print_ex MACRO args:VARARG
      IFNDEF @@_print_ex_buffer_size_@@
        @@_print_ex_buffer_size_@@ equ <260>
      ENDIF
      push esi
      mov esi, alloc(@@_print_ex_buffer_size_@@)
      print cat$(esi,args)
      free esi
      pop esi
    ENDM


The test piece uses the macros as follows.

Code Select Expand


    set_printex_buffer 1024

    mov var, 12345678

    print_ex "decimal : ",ustr$(var),chr$(13,10), \
             "hex     : ",uhex$(var),chr$(13,10)


Any comments welcome.

[Phil]

Hi Hutch,

  I like the idea behind what you are suggesting and your implimentation is very straight forward. I don't like the idea of having another print function though.

Edit:

  Wouldn't it be better if we just found a way to extend the current definition of print and perhaps fprint to handle this directly?

  Here's a simple redefinition of the print macro that allows the following code to work but it breaks current functionality.  I'm working on a way to allocate/deallocate a buffer, call StdOut only once, and handle the current usage. Anyway, this gives you an idea about what I'm suggesting as an alternative. I think it's all possible.

Code Select Expand

    print MACRO arg1:REQ,varname:VARARG      ;; display zero terminated string
        invoke StdOut,reparg(arg1)
      FOR var,<varname>
        IFNB <var>
          invoke StdOut,reparg(var)
        ENDIF
      ENDM
    ENDM

    .data

    var dd 0

    .code

start:

    mov var,12345678

    print "decimal : ",ustr$(var),chr$(13,10), \
          "hex     : ",uhex$(var),chr$(13,10)



[hutch--]

 :bg

Phil,

Its probably too many years grinding API calls but I don't see the problem of overlapping capacity with similar procedures. The current version of "print" handles either an address or quoted text plus whatever you want to tack onto the end where the extended version was aimed at being able to handle either an address, quoted text, numeric conversions and anything that works with the cat$ macro. The piece of genius to set the buffer size was if someone wanted to use it with string adresses that were larger than the 260 byte buffer that was set by default.

The fprint macro is aimed at being consistent with the rest of the file IO macros which mainly wrap API calls but it doing somethoing different in that it must have a file handle for the specific file it writes to where a console output proc can routinely get the console handle without needing to specify it.

[Phil]

Okay. There's certainly no problem with the print_ex you've described and it looks good so far! Just thought I'd offer my nickel's worth and suggest just extending the definition of print.