Oh, I had to make a poll. :alright:

Note: SpASM doesn't require the comma and can do multiple instructions per line (which is another poll :)) Another option would be to make move the default action and so it wouldn't have to be explicitly stated. Or an extreme symbolic version. :)

=eax.b 1, +eax.b 1, &eax.b 1
Posted on 2001-08-11 16:12:38 by bitRAKE
I am very much a fan of the standard Intel notation used by MASM, TASM and most inline assemblers, its the manufacturers specification and it is well understood around the world.

It has the necessary distinctions of DATA,

1. Immediate
2. Memory
3. Register

and it has the SIZE specifier in cases of ambiguity. The use of square brackets indicates addressing in the form or a stack variable
var[0].

Regards,

hutch@pbq.com.au
Posted on 2001-08-11 19:31:32 by hutch--
I VERY much like the nasm syntax, at it removes all ambiguities and
doesn't require much typing. Too bad nasm doesn't remember sizes of variables :(
Posted on 2001-08-11 20:18:54 by f0dder
Hope I'm understanding this right. This is MASM:

mov , byte ptr 1 (MASM)

Something I liked about 68k was the instruction looked like this:

move.b
move.w
move.d

add.b

sub.w

etc.


It was short and you always knew what size you were moving. Been ages since I've used it however.
Posted on 2001-08-11 21:39:47 by ThoughtCriminal
CoffeeDrinker, I've noted in parenthesis some of the assemblers that support the syntax listed. Sorry, as I'm not familiar with all the assembler syntaxes, and have taken it for grated that most people here use MASM.

It would be even possible to support many forms with an intermediate representation. :) PTR is redundant. I think brackets slow down my typing, and they could be used for something else. Just because something has been done a certain way for a long period of time and many people are familiar with that way, doesn't mean a different way isn't better. Just means it'll be hard to migrate mentally. Could appeal to the young or new. Starting over isn't something anybody with a deep investment likes doing. :) This is the only reason many things are still around. :grin:
Posted on 2001-08-11 22:53:16 by bitRAKE
Rake, in nasm, all the times I've typed [] are easily outweighed by
the times I *haven't* typed "offset ":). Just so you can see that
aren't necessarily needed. Also, I really *DO* like brackets. They are
needed on register indirection, so why not have them standard while
at the same alleviating the needed for ptr and et al... ).

Just my thoughts, have fun. 06:22 (AM), drinking, still drinking, DRINKING;
Posted on 2001-08-11 23:24:40 by f0dder
When i did my choices for this, i have considered that having different
conventions for different cases is confusing and that having a typing
convention that does not immediately tells what it is, is confusing too.

At my opinion, the important point in writing conventions definition is
not so much about how long it takes for typing. The main point is
readibility. When you see, for example, in MASM:

>mov ebx ThisSymbol

you can *not* know WHAT is "ThisSymbol". You have to do a search.

When you see, in Spasm (if you add upper cases use, for Equates):

>mov eax &THIS_SYMBOL
>mov ebx THIS_SYMBOL
>mov ebx ThisSymbol
>mov ebx D?ThisSymbol
>mov ebx
>mov ebx D@ThisSymbol

you immidiately know that 1) is a Win32 Equate, 2) is a user defined
Equate, 3) is an Address, 4) and 5) are Values in Memory, 6) is a Local
Variable content. This is hundread times more important than how long it
takes for writing, because we do not spend so much time at pure writing as
we can spend at structuring, bug fixing, maintaining, learning, and so on.

Now, having different conventions for Data declarations, (example, in MASM
when you declare a String symbol as an Adress and a dWord symbol as content),
is simply completely crazy, and can not, at my opinion be validated by the
fact that you will not have to type the '[]' when evocating. This is an
evident cause for no-end error search, as we can see every days, here, in many
"help" threads. These errors are not due to weakness of the programmer, they
are due to wrong syntax.

The fact that the wrong syntax is actually the more in use is not a strong
argument for Asm programming because x86 Assembly is dead many years ago,
and just reborn 3 or 4 years ago. So, this is the right time to restart from
scratch with fresh ideas. The loose of MASM written recent sources is not
important. We have very few of them and they can be translated when they are
of interrest. I did it for Test Departement, Iczelion and Ron Thomas Tuts, and
this was not so far killing.


Betov.
Posted on 2001-08-12 04:47:54 by Betov
I vote for none of the above. I prefer the FAsm sytax:


mov b[eax], 1
Posted on 2001-08-12 22:13:25 by eet_1024
That's very close to:
movb , 1 ;I like FASM :) Nice simple macros, too :)

How about numbering the registers and doing something like:
0b=1 :grin:
Posted on 2001-08-13 08:26:00 by bitRAKE
I have to say that i like brackets because i want to be able to understand in a second (without search up/down) any code i read about 3 months after i last modifyed it

Maybe IF you dont like typeing instructions you are not a programmer or have choosen the wrong job?...

I belive that typeing has little to do with code, and more time is wasted in my experience in hours and hours of degugging and searching...typeing a lot is the last one of our problems...

if only typeing less text and faster matters then secretary will be the best programmers in this world ;)

Beeing able to easy understand and debug your code if FAR MORE important then some typeing saveings...

but i have to agree here (brackets) that there are PARSING problems in the compiler (esp macro parameter substitution) that made MASM go in the "no brackets also" direction

i like those forms:
===================
mov byte ,1 ; or
mov.b ,1 ;or
movb ,1

so i vote for BRACKETS ALLWAYS like in NASM ;)
this is very much needed for fast and correct interpretation of code/pointers after some time....

besides one thing i whould like to see will be a way to access the high bytes of eax, a more important thing IMHO for the Intel hardware team ;)

like: mov eax.hl,1

where
eax.ll = al
eax.lh = ah
eax.hl = low byte of high word of eax
eax.hh = high byte of high word of eax

those are really NEEDED instructions for grafix....and little can assemblers do about it as hardware support is required
Posted on 2001-08-13 18:09:31 by BogdanOntanu
I certainly see the point about brackets, I just like exploring other possiblities. I really got into asm on the 68000 and that has got me conditioned to 'move.b' and [] :)

We should all design our own processor. I'd like 256 bit registers that are accessable as byte arrays:
add a0F, b ;the two digits after the a are indexes into the register :)
mov b0V, cV0 ;quickly reverse the order of bytes :)
Posted on 2001-08-13 21:58:44 by bitRAKE
BogdanOntanu:
The correct notation would be:
• eax
  + eal
    • ea0
    • ea1
  + eah
    • ea2
    • ea3

Why less typing is better:
   Less chance of a stupid error. Who here has 100% typing accuracy? In a better world, we would use cp instead of mov/move.
Posted on 2001-08-14 04:06:13 by eet_1024
Of course, all this is a mix of opinions, taste and experience.

About Typing, i am exactely in the same vue as Bodgan (the fact that
he prefers "BYTE " and that i prefer "B$_MySymbol" is a side
detail -anyway, i have made all of these variants available in SpAsm-).

For saving typing time, i am sure that all experienced programmers
around here will be in the same vue as Bodgan and me: Typing counts
for nop // Readibility counts for ALL.

This primar saving time concept makes me think of this other thread about
"Code Completion": This may be very attractive for younger guys who much
like toys, but i would be very estonished that an older programmer, like
Hutch or Bodgan, whould like to live with such a stupid and killing feature
inside his Editor.

Or this makes me think of these "illusion IDEs" that offer the possibility
of building a Base Window with one -or couple- of click(s) (impressive power
illusion of building an Application with the mouse), whereas this part of
developpement, in real world, is a couple of minutes among, at least, one
year of crazy hard work for any consistant Application...

eeet_, when you say that the more we have to type, the more we got error
chances, this is true for the so called "typos" (simple typing errors).
Such errors are immidiately pointed out by any Asm Parser. So, this is
not the point. Important errors are these errors that take time to point
out, like, for example, when the wrong syntax induces you to tell an
adress when you mean a value (and reverse). In such cases, the time you
spend at bug hunting is the time to write hundreads or thousands of
"dWord" (or whatever form), instead of "Something".

The general well known rule for errors management is that the sooner
they are detected, the better it is. This is *true* saving time. At this
point of vue, my humble opinion is that the absolute sooner time is the
writing time. Explicit markers use the brain of the programmer as a first,
very fast an easy error checker (and this one is the best available one).


Betov.
Posted on 2001-08-14 07:28:16 by Betov
When I talk about typing less, I don't talk about function/variable
names. Sure, I often call a temporary variable "temp", and (in C)
use i,j and k in for loops. But any global data/functions I will dub
with meaningful (and often semi-long) names. When I say less typing,
I primarily mean "byte" instead of "byte ptr", and not having to type
"offset"... this works fine in nasm. No ambiguities, because
are required when dereferencing memory addresses, be it registers
or variables, or even direct addresses :).

Readability is VERY important, but typing *does* matter some. But
it takes pretty extreme cases (working with the winnt.h PE structures,
ugh) before typing really matters.

Code Completion can be nice, but I don't like when it's too automagic.
A keystroke like ctrl+b to finish a long variable name is *very* nice
though... especially when you use long and meaningful variable
and function names a lot :).

As for "illusion IDE", would that apply to using a resource editor as
well? I like using dialogs, they make IDE development faster so I
can concentrate on the *real* code. Even hutch has his prostart
to make IDE development faster.
Posted on 2001-08-14 07:43:29 by f0dder


BogdanOntanu, I made my post refering to 68k style, but also knowing that style might not be possible with the x86 architecture.
--------------------
eax.ll = al
eax.lh = ah
eax.hl = low byte of high word of eax
eax.hh = high byte of high word of eax

mov.hl eax,1
--------------------

I don't think that can be encoded to an instruction. 68k architecture allowed you to specify if you wanted to work on a byte, word, or dword. It would be nice if the intel arcitecture people added that kind of support.
Posted on 2001-08-14 13:18:14 by ThoughtCriminal