Re: retf for 16bit or 32bit? CS:IP or CS:EIP?

Herbert wrote:
> Beth wrote:
> > Frank, Frank, Frank...don't you know? Germans have no sense of humour,
so
>
> Yes, you are completely right. In Germany and the USA people
> have a sense of HUMOR, only the Britains have a sense for
> a somthing different HUMOUR.
>
> > they wouldn't be able to tell you were joking around there...
>
> It's easy to prove that I have a sense of humor, because
> I even think LUXASM is some sort of a joke. I find it
> funny that people try to implement "improved" assemblers
> by modifying the macro system or adding an integrated
> development environment but not wasting a single second
> whether the low level syntax (specifying the operand
> size, order of the operands, specifying the addressing
> modes) is appropriate (if God Intel says it's appropriate,
> then it is appropriate by definition). This is like you
> want to improve the Roman numerals by modifying the
> used symbols instead of thinking about a binary or decimal
> system. But at least there is a French comrade with the
> same sort of HUMOUR.

See, Frank? Didn't I tell you that they couldn't work out when you're
making a joke?

Even when I delibrately tag it with "Guildo hat euch lieb!" as a postscript
to give the game away as blatantly as possible that the entire thing was
said with tongue firmly in cheek...

Regards your oh-so-serious point, Herbert: I _DID_ 100% engage in
discussions about an alternative syntax to Intel's, due to its inherent
ambiguities...a point on which I've always agreed with you...and the
"compromise" solution was to support alternative prefixes, such as "dmov"
for "double-word move" or "wpush" and similar...

A proposal to which Randy - the guy I'm said to agree with regardless,
apparently, even when, ummm, I'm not agreeing with him at all - kicked up a
fuss that "size in the mnemonics" was an a terrible idea and Intel were
"fantastic" or something for having created the first screwed up assembly
language syntax, to which I had a bit of an argument with him about...

It's all in the archives...though, it would save a lot of time if you
actually _paid attention_ to this stuff while it's on-going rather than
having to be redirected to the archives to confirm that your assertions
about no effort being expended on this matter is entirely false...

I drew attention to this point myself independently of yourself (Frank may
remember the thread where I pointed out this "inherent ambiguity" to, in
fact, defend AT&T's syntax as NOT suffering this problem that it is
arguably a better syntax, even if not a "familiar" one)...and did propose a
set of "alternative mnemonics" to deal with this (I personally wouldn't
care about going further to "fix" up those other little Intel syntax
"issues"...but, at the same time, this does have to be usable by
others...who, for better or worse, insist on "Intel syntax" as it
is...hence, the "compromise" was to leave the essential syntax "as is" but
to introduce extra "alternative mnemonics" with "size prefixes"...choosing
an Intel-like style of "dmov" (the idea of "movd" was my first suggestion
because this is already employed by Intel on "movsd" and such...but there
were possible confusions and conflicts in "size suffix" because good ol'
Intel have NOT been sufficiently "consistent" in their approach...so the
next alternative was "size prefix"...an additional proposal to which I've
not retracted support for...although, whether it actually makes an
appearance is not up to me alone, so I'll see what the rest of the team has
to say on the matter...these would simply be additional "alternatives" and
would compliment what's already Intel syntax...yes, I know this isn't going
far enough for your tastes but, on such a project as this, there is a need
for some "compromise" here and there...I already surrendered semi-colons to
newlines in the interests of "team harmony" ;)...

Beth :)


.

Relevant Pages

  • Re: newbe about API
    ... sure...because the Intel encodings and prefixes for 16-bit and 32-bit ... know - from only looking at those instruction encodings - which way ... Hence, even with your great "size suffix" syntax, Intel's encodings ... But, yeah, I looked at your code, Herbert, and you employed something ...
    (alt.lang.asm)
  • Re: HLA History
    ... Intel don't really define a "syntax", ... to try to provide the "HLL" style, ... "incompatibilitise" are minor things like "proprietary assembler ...
    (alt.lang.asm)
  • Re: ASM386 Manual On-Line
    ... >> original Intel syntax. ... But that doesn't change the fact that "Intel ... Intel designed the syntax for their assembler when they first ... Let me get this straight- You hate Intel. ...
    (alt.lang.asm)
  • Re: HLA History
    ... whatever (but was never really covered by Intel formally that _everyone_ - ... As "weird" as Herbert is using his own syntax and, ordinarily, you might ... different (for example, to get rid of the "ambiguity", you get the GAS / ... word register and a dword register all sharing the same space (which isn't ...
    (alt.lang.asm)
  • Re: SUMIF w/ Multiple criteria?? (double minus sign in SUMPRODUCT formula)
    ... Frank ... I see this syntax with double minus sign in connection with the SUMPRODUCT function again and again. ... >> spreadsheet that links to this spreadsheet with mulitple ... >> don't know how to add a second criteria to that. ...
    (microsoft.public.excel.worksheet.functions)