Re: HLA and embedded controllers

this is gonna be long one...

Not really. I can't imagine any FASM programmer not grabbing and using
both sets of library code, if they're interested in library code.
sure, competition is always good, we can "steal" ideas from ourselves
;)
for example maybe you could steal my CF/EAX-based error
returning/throwing/catching

Indeed, if you're interested, I'll be more than happy to work with you
and supply you with code to use as I clean up the HLA stdlib.
i often could take some inspiration. for example, do you have text
input system? i would be really interested in it. I mean routines like
"read decimal number from console" or "read 8-byte string from file"
etc.

If you're pretty good with FASM macros, I could even use a little help getting
the FASM include files up and operational for FASM.
you can post any question about macrosolutions on the board, i
preferably answer there, so other can see it.
and yes, i am of those better FASM macrowriters ;)

It certainly is *not* limited to HLA, only. While there are a couple of
routines that don't make sense outside the context of HLA, most of the
routines are relatively generic. You push the parameters on the stack
(or in registers), you call the routine, the results come back in
appropriate places. Indeed, as a sort of "proof of concept" I'd
written a header file for MASM to demonstrate calling HLA stdlib
routines,

http://webster.cs.ucr.edu/AsmTools/MASM/index.html
you are forgetting ambigous syntax, and that new MASM requires .NET
framework (~20MB) to run, and that MASM code can't be compiled with
MASM for anything else than win32 (no COFF / ELF), etc. etc.
really, MASM is just the most often used. not bad, but far from best in
any other area.

from your examples to use MASM, only "Most Windows' assembly language
examples on the Internet today use MASM syntax" counts, others are
"off"

to HLA4MASM: looks like it works. too bad you don't have prebuilt
executable there. But, i am against such usage, because you are in fact
redefining MASM language with these macros. in MASM "language" calling
procedure is "call gets", not "gets". you are pushing MASM outside it's
bounds, into something unnatural. MASM is not designed for that.

in FASM there are macros, which allow you to do:
MessageBox(0, "Caption", GetText(GetText()), MB_OK)
but i am against using them too. There is no reason to code assembly
then. I have myself several ideas about implementing OO language in
assembly via macros in MUCH more efficient way than C++. But if i would
do that, it will be just "look how it could have been done without
backward C compatibility ". Nothing to use.

i wonder how will pure assembly (no macros) example, with HLA exception
handling look like. after that, i can judhe.

http://webster.cs.ucr.edu/AsmTools/FASM/index.html
FASM is "reasonably capable" while MASM is "very powerful" and TASM is
"even more powerful"?!? what useful can MASM do (besides symbolic info
support and inline macros...), that FASM can't? i can give tons of
counter examples.

These examples are far from perfect; but they do demonstrate that it's
pretty easy to call HLA stdlib routines from different assemblers. Of
course, it should be pretty obvious that most of the HLA stdlib
routines can be called from MASM, TASM, FASM, and Gas because HLA emits
source code for these different assemblers. Obviously, you can call the
stdlib routines using the same code sequences that HLA emits.
sure, question if these "code sequences that HLA emits" are reasonably
simple for handwritten code

OTOH, I feel that a *decent* implementation of the HLA stdlib for other
assemblers will define a set of macros that make it easy to call the
stdlib routines, in a more "HLA style". For example, under FASM you
should be able to write:
stdout.puts someStrVar
and it would automatically emit the code
push someStrVar
call stdout_puts
this is no problem in FASM

That's where the real work for ports to other assemblers will be, in
providing decent macros for data structures and all the functions to
give them a consistent (as possible) calling sequence.
well, this is your decision. I believe that ASM library should be
neatly usable
from pure asm code. Otherwise, it can't become "real" ASM library

To use exception handling requires linking in (and calling from the
main program) one small routine and a small data structure.
*static* data structure? is it thread-safe?

do you want to have it usable for pure-asm coders? (these were some of
main questions i was solving when designing FASMLIB)
Of course it's usable by people who want to write bare machine
instructions. But my goal is to supply macros to make the calls a
little more palatable.
so, then, please show me example how try/throw/except pure asm code
looks like...

Agreed. That's why I laugh when people start talking about how "HLA is
just a high-level language" and the "proof" of this they give is
stdout.put( "Hello world" nl );
The stdout.put macro invocation isn't a part of the HLA language at
all.
sure, that doesn't imply HLA is HLL.
My opinion is that HLA is neither assembler nor HLL. It just doesn't
fit into any usual category. I personally dislike the idea of putting
abstraction into assembly code. That abstraction is only speed/size
disadvantage C has over ASM. And you got ASM rid of this, so you often
end up with using ASM where HLL would do better, and using HLL where
ASM would do better.

It is usable by other assemblers. The biggest problem I can see to
porting it to FASM is using the HLA stdlib's 'put' macros since FASM
lacks type-casting. So you can't do something like
stdout.put uns32Var, nl, stringPtr, csetVar, int32Var
sure it can't, and shouldn't, FASM is assembler, even lower level
assembler, eg. symbolic notation of processor instructions. Processor
doesn't differentiate types, only sizes (like FASM). How do you know if
"db 0" is empty string, or byte variable?

And have the macro sort out the correct routines to call. If there is
a way to write a macro like that in FASM, I would sure like to know
about it :)
you can get size assigned to symbol with various tricks, but i think
"clean" solution will be to create macros to define each data type.
Then
it is easy to check type.

.

Relevant Pages

  • Re: Rocket Science
    ... >> Also, logically, if MASM is the underlying assembler being used by ... then MASM must always be being run in addition to HLA so ... the MASM or FASM or whatever underlying assembler's speed into its own ...
    (alt.lang.asm)
  • Re: A whole group dedicated for programmers to throw crap at each other?
    ... As for your phrase "one thing other assemblers can't really provide", ... massive material available for MASM: ... MASM aren't any better than NASM, Gas, and HLA. ... > I might move to HLA though or FASM. ...
    (alt.lang.asm)
  • Re: Between Assemblers
    ... If I were starting HLA ... there is no way that I would use MASM as the back end of the HLA ... regardless of what Rene might claim; I *do* provide FASM as part of the ... Linux has nothing to do with it. ...
    (alt.lang.asm)
  • Re: maz v. taz
    ... try to defend your C-Side toy against FASM. ... for dedicated Windows support MASM has many large ... > prefer the lower level approach that assemblers like NASM and FASM ... the very simple reason that its Macros System is not ...
    (alt.lang.asm)
  • Re: Definitions - What are yours?
    ... I challenge you, about Macros, to output a Bitmap created ... by MASM Macros (Yes, clown, FASM *CAN* do that). ... I never claimed that MASM has a complete superset of FASM's ... The reason why it is not Assembler. ...
    (alt.lang.asm)