If yes, then I will have questions that involve more than the syntax. 
Things like, well I'll just ask one.

Microsoft has eliminated the inline assembler in it's 64-bit versions of 
Visual Studio. I was getting ready production code based upon 
C/C++/inline-assembly in 32-bit land, but now I will not deploy because 
of the removal of the inline assembler (and the imminent ubiquitousness 
of 64-bit computing in desktop and server environments). I feel 
"flabergasted" or something. Rug pulled out from under me! Your (any/all 
of you that I have yet to meet and are surely gurus of the technology) 
thoughts? 

Tony wrote:
> If yes, then I will have questions that involve more than the syntax.
> Things like, well I'll just ask one.
>
> Microsoft has eliminated the inline assembler in it's 64-bit versions of
> Visual Studio. I was getting ready production code based upon
> C/C++/inline-assembly in 32-bit land, but now I will not deploy because
> of the removal of the inline assembler (and the imminent ubiquitousness
> of 64-bit computing in desktop and server environments). I feel
> "flabergasted" or something. Rug pulled out from under me! Your (any/all
> of you that I have yet to meet and are surely gurus of the technology)
> thoughts?
>
MSVC breaking the C(++) standard this way was a bit of a downer to me as 
well. :-(

The workaround is mostly to separate out all the functions that need 
inline asm, and then compile that code with Intel's C compiler.

The alternative is of course to use a proper assembler, but that can 
make interfacing, particularly to C++ code, a bit harder. :-(

Terje

PS. Compiler intrinsics still work, so you can write 64-bit SSE2+ code, 
and by taking a bit care, write code that compiles in both 32 and 64 bit 
mode, even using MMX/inline asm for conditionally compiled 32-bit code.

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On Nov 28, 9:59=A0pm, "Tony" <nos...@nospicedham.myisp.net> wrote:
> If yes, then I will have questions that involve more than the syntax.
> Things like, well I'll just ask one.
>
> Microsoft has eliminated the inline assembler in it's 64-bit versions of
> Visual Studio. I was getting ready production code based upon
> C/C++/inline-assembly in 32-bit land, but now I will not deploy because
> of the removal of the inline assembler (and the imminent ubiquitousness
> of 64-bit computing in desktop and server environments). I feel
> "flabergasted" or something. Rug pulled out from under me! Your (any/all
> of you that I have yet to meet and are surely gurus of the technology)
> thoughts?


So write an external assembler subroutine.

There are other 64 bit C and C++ compilers for Windows, some of which
support inline assembler, although most of them are not as well suited
for developing Windows applications as are MS's compilers (GCC is a
good example, ICC is another, and rather better for writing Windows
applications that GCC - although it's not free).

Or just ship a 32 bit application.  Works just fine on x86-64 Windows
systems.

Nor is this news.  We've known that inline assembler has been removed
from MS's 64 bit C/C++ compiler since the first beta versions of
Windows XP x86-64, back in '04, or so.  Nor was there inline assembler
in the IPF (all 64 bit) versions of Windows (dating back to 2001).

"Terje Mathisen" <"terje.mathisen at tmsw.no"@giganews.com> wrote in message 
news:ja7cs7-d7t2.ln1@ntp.tmsw.no...

> MSVC breaking the C(++) standard this way was a bit of a downer to me as 
> well. :-(

> The workaround is mostly to separate out all the functions that need 
> inline asm, and then compile that code with Intel's C compiler.

> The alternative is of course to use a proper assembler, but that can make 
> interfacing, particularly to C++ code, a bit harder. :-(

You always seemed to me to use inline assembler as your first choice
and I have to admit that I never understood it.  Like for example the
way the assembly language code accesses the data of the HLL code.  If
a variable is passed to a function in a register, can the assembly
language code assume it's still in the same register, even after a
number of intervening function calls?  Or the explosion of parentheses
that occurs when a function is passed as an argument in C -- how does
that explosion get expressed when the function gets passed farther
down or invoked in inline asm?

Watcom had that #pragma aux stuff that could set up an effective
interface for the transition between C and assembly code, but since
other compilers lack it I suppose that means that the details of the
interface have to be known to the programmer on a per-compiler basis.
These kinds of questions led me to conclude that inline assembler is
hard for an HLL programmer to understand because it's assembler and
hard for an assembly language programmer to understand because of
all the context one has to know about how the assembly code meshes
with the HLL code, so the only person who can touch the code
subsequently in the original programmer.

The only time I ever used inline assembly was when I was writing
code for the 21164 using Compaq Visual Fortran.  I couldn't get
QueryPerformanceCOunter to work so I wrote some inline assembly to
access the RPCC instruction.  Also CVF couldn't be forced to
assemble a naked right shift instruction, so I used inline
assembly again for that.  The code is now useless of course because
Alpha died subsequently.  When the question came up about how to
access the floating status word and other registers in Fortran
without linking to external libraries you would think inline
assembly would be the ideal solution, but most Fortran compilers
don't implement inline assembly so instead I decided to poke the
code into memory (using VirtualAlloc or mmap depending on OS)
and pass addresses of the created functions back to the Fortran
code, just like we used to do in the good old days.

> PS. Compiler intrinsics still work, so you can write 64-bit SSE2+ code, 
> and by taking a bit care, write code that compiles in both 32 and 64 bit 
> mode, even using MMX/inline asm for conditionally compiled 32-bit code.

Or you could use ambivalent code.  We got the jump down to 5 bytes in
http://groups.google.com/group/comp.lang.asm.x86/browse_frm/thread/8a0436840d1f1b1a/4cada42116ca77a3?hl=en
Do you see a shorter method?

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

James Van Buskirk wrote:
> "Terje Mathisen"<"terje.mathisen at tmsw.no"@giganews.com>  wrote in message
>> The alternative is of course to use a proper assembler, but that can make
>> interfacing, particularly to C++ code, a bit harder. :-(
>
> You always seemed to me to use inline assembler as your first choice
> and I have to admit that I never understood it.  Like for example the
> way the assembly language code accesses the data of the HLL code.  If
> a variable is passed to a function in a register, can the assembly
> language code assume it's still in the same register, even after a
> number of intervening function calls?  Or the explosion of parentheses
> that occurs when a function is passed as an argument in C -- how does
> that explosion get expressed when the function gets passed farther
> down or invoked in inline asm?

My inline asm functions have always used very simple calling interfaces, 
i.e. pass on the stack, access using parameter name:

i.e. like this:

uint32_t ror(uint32_t x, int count)
{
   __asm {
     mov eax,[x]
     mov ecx,[count]
     ror eax,cl
   }
}

MSVC can take that piece of code and inline it, avoiding the call/ret 
overhead, but leaving the parameter setup/access stuff.

The most common inline code I use is simply RDTSC for cycle timing:

int64_t rdtsc(void)
{
   __asm rdtsc
}

Normally I use inline asm for much more substantial code, where the 
setup/parameter overheads become negligible.

>
> Watcom had that #pragma aux stuff that could set up an effective
> interface for the transition between C and assembly code, but since

I did like Watcom. :-)

> The only time I ever used inline assembly was when I was writing
> code for the 21164 using Compaq Visual Fortran.  I couldn't get
> QueryPerformanceCOunter to work so I wrote some inline assembly to
> access the RPCC instruction.  Also CVF couldn't be forced to
> assemble a naked right shift instruction, so I used inline
> assembly again for that.  The code is now useless of course because
> Alpha died subsequently.  When the question came up about how to
> access the floating status word and other registers in Fortran
> without linking to external libraries you would think inline
> assembly would be the ideal solution, but most Fortran compilers
> don't implement inline assembly so instead I decided to poke the
> code into memory (using VirtualAlloc or mmap depending on OS)
> and pass addresses of the created functions back to the Fortran
> code, just like we used to do in the good old days.

Ouch. :-)
>
>> PS. Compiler intrinsics still work, so you can write 64-bit SSE2+ code,
>> and by taking a bit care, write code that compiles in both 32 and 64 bit
>> mode, even using MMX/inline asm for conditionally compiled 32-bit code.
>
> Or you could use ambivalent code.  We got the jump down to 5 bytes in
> http://groups.google.com/group/comp.lang.asm.x86/browse_frm/thread/8a0436840d1f1b1a/4cada42116ca77a3?hl=en
> Do you see a shorter method?

No, but my code would probably always be distributed as source, not as a 
compiled library, so there wouldn't really be a gain from having the 
same function callable in both 32 and 64-bit mode.

I did follow the ambi thread of course, the "winner" is really neat. :-)

Terje
-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

"Terje Mathisen" <"terje.mathisen at tmsw.no"@giganews.com> wrote in message 
news:jh7ds7-udu2.ln1@ntp.tmsw.no...

> My inline asm functions have always used very simple calling interfaces, 
> i.e. pass on the stack, access using parameter name:

> i.e. like this:

> uint32_t ror(uint32_t x, int count)
> {
>   __asm {
>     mov eax,[x]
>     mov ecx,[count]
>     ror eax,cl
>   }
> }

It's just this kind of code I don't understand.  What if the
surrounding function had x as a dummy argument and was
compiled for 64 bits?  Then there isn't really an address of
x, so does mov eax,[x] make any sense?

> MSVC can take that piece of code and inline it, avoiding the call/ret 
> overhead, but leaving the parameter setup/access stuff.

> The most common inline code I use is simply RDTSC for cycle timing:

> int64_t rdtsc(void)
> {
>   __asm rdtsc
> }

Again, I find it so hard to follow this snippet.  Here is what I
poked into memory for the above:

_rdtsc:
  0000000000000080: 31 C0              xor         eax,eax
  0000000000000082: 40 75 0A           jne         000000000000008F
  0000000000000085: 0F 31              rdtsc
  0000000000000087: 48 C1 E2 20        shl         rdx,20h
  000000000000008B: 48 09 D0           or          rax,rdx
  000000000000008E: C3                 ret
  000000000000008F: 0F 31              rdtsc
  0000000000000091: C3                 ret
----------------------------------------------------------
_rdtsc:
  00000080: 31 C0              xor         eax,eax
  00000082: 40                 inc         eax
  00000083: 75 0A              jne         0000008F
  00000085: 0F 31              rdtsc
  00000087: 48                 dec         eax
  00000088: C1 E2 20           shl         edx,20h
  0000008B: 48                 dec         eax
  0000008C: 09 D0              or          eax,edx
  0000008E: C3                 ret
  0000008F: 0F 31              rdtsc
  00000091: C3                 ret

Does the compiler know that it's supposed to repackage edx:eax into
rax if compiled for 64 bits, or is an alternative code with #ifdef
required?

> Normally I use inline asm for much more substantial code, where the 
> setup/parameter overheads become negligible.

I think that for more substantial code it is more readable if placed
in its own separately assembled file.  Maybe if C is your first
language and you see the world through C-colored glasses, phrasing
your assembly language code as inline assembly in C makes it more
palatable, but for my part I never understood C until I learned to
read machine language, so the interaction between the high-level
aspects of C and the machine code implied by inline assembly seems
full of ambiguities and hidden context.

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

James Van Buskirk wrote:
> "Terje Mathisen"<"terje.mathisen at tmsw.no"@giganews.com>  wrote in message
> news:jh7ds7-udu2.ln1@ntp.tmsw.no...
>
>> My inline asm functions have always used very simple calling interfaces,
>> i.e. pass on the stack, access using parameter name:
>
>> i.e. like this:
>
>> uint32_t ror(uint32_t x, int count)
>> {
>>    __asm {
>>      mov eax,[x]
>>      mov ecx,[count]
>>      ror eax,cl
>>    }
>> }
>
> It's just this kind of code I don't understand.  What if the
> surrounding function had x as a dummy argument and was
> compiled for 64 bits?  Then there isn't really an address of
> x, so does mov eax,[x] make any sense?

No, but the compiler can generate a MOV EAX,reg or whatever else is 
needed to make the value end up in that register.
>
>> MSVC can take that piece of code and inline it, avoiding the call/ret
>> overhead, but leaving the parameter setup/access stuff.
>
>> The most common inline code I use is simply RDTSC for cycle timing:
>
>> int64_t rdtsc(void)
>> {
>>    __asm rdtsc
>> }
>
> Again, I find it so hard to follow this snippet.  Here is what I
> poked into memory for the above:
>
> _rdtsc:
>    0000000000000080: 31 C0              xor         eax,eax
>    0000000000000082: 40 75 0A           jne         000000000000008F
>    0000000000000085: 0F 31              rdtsc
>    0000000000000087: 48 C1 E2 20        shl         rdx,20h
>    000000000000008B: 48 09 D0           or          rax,rdx
>    000000000000008E: C3                 ret
>    000000000000008F: 0F 31              rdtsc
>    0000000000000091: C3                 ret
> ----------------------------------------------------------
> _rdtsc:
>    00000080: 31 C0              xor         eax,eax
>    00000082: 40                 inc         eax
>    00000083: 75 0A              jne         0000008F
>    00000085: 0F 31              rdtsc
>    00000087: 48                 dec         eax
>    00000088: C1 E2 20           shl         edx,20h
>    0000008B: 48                 dec         eax
>    0000008C: 09 D0              or          eax,edx
>    0000008E: C3                 ret
>    0000008F: 0F 31              rdtsc
>    00000091: C3                 ret
>
> Does the compiler know that it's supposed to repackage edx:eax into
> rax if compiled for 64 bits, or is an alternative code with #ifdef
> required?

Always the latter, in my case.

>
>> Normally I use inline asm for much more substantial code, where the
>> setup/parameter overheads become negligible.
>
> I think that for more substantial code it is more readable if placed
> in its own separately assembled file.  Maybe if C is your first
> language and you see the world through C-colored glasses, phrasing
> your assembly language code as inline assembly in C makes it more
> palatable, but for my part I never understood C until I learned to
> read machine language, so the interaction between the high-level
> aspects of C and the machine code implied by inline assembly seems
> full of ambiguities and hidden context.

I'm exactly like you:

I started with Fortran, Simula, ModulaII and then Pascal.

Shortly after getting Turbo Pascal (1982/83) I had to write (inline) asm 
interrupt handlers for my Pascal code, then went on to write a _lot_ of 
standalone asm programs.

(About 18 MB of pure asm source code over the first 3-5 years.)

I understand C(++) to the exact degree that I know how it maps to asm.
:-)

Terje

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Tony wrote:
>
> Microsoft has eliminated the inline assembler in it's 64-bit versions of
> Visual Studio. I was getting ready production code based upon
> C/C++/inline-assembly in 32-bit land, but now I will not deploy because
> of the removal of the inline assembler (and the imminent ubiquitousness
> of 64-bit computing in desktop and server environments).

Well, one issue is that you are using the phrase "64-bit computing" when
you really mean "amd64 computing".  Windows supports (for some definition
of the word) two completely different 64-bit processors -- amd64 and
Itanium.  They have two different instruction sets.  When you include
inline assembler, you only work with that one specific processor.  By
forcing you to use C, your code compiles for ALL of the processors.

Terje Mathisen <"terje.mathisen at tmsw.no"@giganews.com> wrote:
>
>MSVC breaking the C(++) standard this way was a bit of a downer to me as 
>well. :-(

Surely you must realize that inline assembler has ALWAYS been an extension
to the C/C++ standards.
-- 
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Tim Roberts wrote:
> Terje Mathisen<"terje.mathisen at tmsw.no"@giganews.com>  wrote:
>>
>> MSVC breaking the C(++) standard this way was a bit of a downer to me as
>> well. :-(
>
> Surely you must realize that inline assembler has ALWAYS been an extension
> to the C/C++ standards.

Yes and no:

I distinctly remember being positively surprised maybe 10 years ago when 
I was told that the asm (or __asm) keyword is actually defined in the 
C++ standard.

Whatever happens inside an asm { } wrapper is of course almost 
completely undefined. :-)

Terje

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On Nov 28, 9:59=A0pm, "Tony" <nos...@nospicedham.myisp.net> wrote:
> If yes, then I will have questions that involve more than the syntax.
> Things like, well I'll just ask one.
>
> Microsoft has eliminated the inline assembler in it's 64-bit versions of
> Visual Studio. I was getting ready production code based upon
> C/C++/inline-assembly in 32-bit land, but now I will not deploy because
> of the removal of the inline assembler (and the imminent ubiquitousness
> of 64-bit computing in desktop and server environments). I feel
> "flabergasted" or something. Rug pulled out from under me! Your (any/all
> of you that I have yet to meet and are surely gurus of the technology)
> thoughts?

Are you saying there is no longer a ml.exe and link.exe?

I use the 32 bit versions to write my code.

Andy

On Dec 2, 12:55=A0am, Andy <chocolatemint77...@nospicedham.yahoo.com>
wrote:
> On Nov 28, 9:59=A0pm, "Tony" <nos...@nospicedham.myisp.net> wrote:
>
> > If yes, then I will have questions that involve more than the syntax.
> > Things like, well I'll just ask one.
>
> > Microsoft has eliminated the inline assembler in it's 64-bit versions o=
f
> > Visual Studio. I was getting ready production code based upon
> > C/C++/inline-assembly in 32-bit land, but now I will not deploy because
> > of the removal of the inline assembler (and the imminent ubiquitousness
> > of 64-bit computing in desktop and server environments). I feel
> > "flabergasted" or something. Rug pulled out from under me! Your (any/al=
l
> > of you that I have yet to meet and are surely gurus of the technology)
> > thoughts?
>
> Are you saying there is no longer a ml.exe and link.exe?
>
> I use the 32 bit versions to write my code.


No, ML is still there, you just can'y use "__asm" *inside* a C program
anymore.

Terje Mathisen <"terje.mathisen at tmsw.no"@giganews.com> wrote:
>
>I distinctly remember being positively surprised maybe 10 years ago when 
>I was told that the asm (or __asm) keyword is actually defined in the 
>C++ standard.

In the 1999 standard, it is defined in Appendix J.5 "Common Extensions".
All that means is that your compiler can support the "asm" keyword and
still be standard-compliant.  Otherwise, a compiler that rejected this
program would not be compliant:

    int main()
    {
        int asm = 3;
        return asm;
    }

However, a compiler that does NOT support it is ALSO compliant.
-- 
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Terje Mathisen" <"terje.mathisen at tmsw.no wrote:
> Tony wrote:
>> If yes, then I will have questions that involve more than the syntax.
>> Things like, well I'll just ask one.
>>
>> Microsoft has eliminated the inline assembler in it's 64-bit
>> versions of Visual Studio. I was getting ready production code based
>> upon C/C++/inline-assembly in 32-bit land, but now I will not deploy
>> because of the removal of the inline assembler (and the imminent
>> ubiquitousness of 64-bit computing in desktop and server
>> environments). I feel "flabergasted" or something. Rug pulled out
>> from under me! Your (any/all of you that I have yet to meet and are
>> surely gurus of the technology) thoughts?
>>
> MSVC breaking the C(++) standard this way was a bit of a downer to me
> as well. :-(
>
> The workaround is mostly to separate out all the functions that need
> inline asm, and then compile that code with Intel's C compiler.
>
> The alternative is of course to use a proper assembler, but that can
> make interfacing, particularly to C++ code, a bit harder. :-(


I wanted to do something with function prologs, not entire functions.


>
> Terje
>
> PS. Compiler intrinsics still work, so you can write 64-bit SSE2+
> code, and by taking a bit care, write code that compiles in both 32
> and 64 bit mode, even using MMX/inline asm for conditionally compiled
> 32-bit code.

I wanted inline assembler capability in the 64-bit offering. 

James Van Buskirk wrote:
> If
> a variable is passed to a function in a register, can the assembly
> language code assume it's still in the same register, even after a
> number of intervening function calls?

VC++ seems to leave ebx alone, but only as far as my first investigation 
into the generated code shows. All bets are off for the other registers 
it seems.

Tim Roberts wrote:
> Tony wrote:
>>
>> Microsoft has eliminated the inline assembler in it's 64-bit
>> versions of Visual Studio. I was getting ready production code based
>> upon C/C++/inline-assembly in 32-bit land, but now I will not deploy
>> because of the removal of the inline assembler (and the imminent
>> ubiquitousness of 64-bit computing in desktop and server
>> environments).
>
> Well, one issue is that you are using the phrase "64-bit computing"
> when you really mean "amd64 computing".

Well the noting of Visual Studio pretty much makes it clear what my 
target platforms are.

> Windows supports (for some
> definition of the word) two completely different 64-bit processors --
> amd64 and Itanium.  They have two different instruction sets.  When
> you include inline assembler, you only work with that one specific
> processor.  By forcing you to use C, your code compiles for ALL of
> the processors.

Well you said one word in there that hits home: FORCE. IOW, lack of 
choice, narrowing of the design possibilities and capbilities, etc.

>
> Terje Mathisen <"terje.mathisen at tmsw.no"@giganews.com> wrote:
>>
>> MSVC breaking the C(++) standard this way was a bit of a downer to
>> me as well. :-(
>
> Surely you must realize that inline assembler has ALWAYS been an
> extension to the C/C++ standards.

I'm not worried about PL standards: note that I am using assemly language 
(!). 

robertwessel2@yahoo.com wrote:
> On Nov 28, 9:59 pm, "Tony" <nos...@nospicedham.myisp.net> wrote:
>> If yes, then I will have questions that involve more than the syntax.
>> Things like, well I'll just ask one.
>>
>> Microsoft has eliminated the inline assembler in it's 64-bit
>> versions of Visual Studio. I was getting ready production code based
>> upon C/C++/inline-assembly in 32-bit land, but now I will not deploy
>> because of the removal of the inline assembler (and the imminent
>> ubiquitousness of 64-bit computing in desktop and server
>> environments). I feel "flabergasted" or something. Rug pulled out
>> from under me! Your (any/all of you that I have yet to meet and are
>> surely gurus of the technology) thoughts?
>
>
> So write an external assembler subroutine.

I just need control of the prologues. I'm not interested in developing 
entire routines in assembler. Just fixing some problems with those 
"standard" languages.

>
> There are other 64 bit C and C++ compilers for Windows, some of which
> support inline assembler, although most of them are not as well suited
> for developing Windows applications as are MS's compilers (GCC is a
> good example, ICC is another, and rather better for writing Windows
> applications that GCC - although it's not free).

Well that non-MacroAssembler syntax doesn't appeal to me (it would wear 
out my % key surely).

>
> Or just ship a 32 bit application.  Works just fine on x86-64 Windows
> systems.

I wanted to move to or start playing around in 64-bit though and the lack 
of inline assembler closed that door. I really like the VS IDE, so moving 
to (god-forbid) a commaneline compiler isn't really an option.

>
> Nor is this news.  We've known that inline assembler has been removed
> from MS's 64 bit C/C++ compiler since the first beta versions of
> Windows XP x86-64, back in '04, or so.  Nor was there inline assembler
> in the IPF (all 64 bit) versions of Windows (dating back to 2001).

Well I didn't says it was news, just news to me, as I just recently 
started using assembly. 

On Thu, 02 Dec 2010 22:07:38 -0800, Tim Roberts
<timr@nospicedham.probo.com> wrote:

> Terje Mathisen <"terje.mathisen at tmsw.no"@giganews.com> wrote:
> >
> >I distinctly remember being positively surprised maybe 10 years ago when 
> >I was told that the asm (or __asm) keyword is actually defined in the 
> >C++ standard.
> 
> In the 1999 standard, it is defined in Appendix J.5 "Common Extensions".

That's *C*, and was the same in C90 except then it was G.5.

*C++* (98) 2.11[lex.key] normatively makes it a keyword, as Terje
said, and 7.4[dcl.asm] gives the toplevel syntax.

The specific asm instructions (strings) are implementation-dependent,
as they also are for C-with-extension.

> All that means is that your compiler can support the "asm" keyword and
> still be standard-compliant.  <snip> 
> a compiler that does NOT support it is ALSO compliant.

Not quite. A conforming C compiler must allow asm as a user
identifier, so it can't be a reserved keyword. Most C compilers have
multiple modes e.g. -standard and -extended and only -standard is
intended to be (and documented as) conforming, so only there do the
requirements of the Standard apply.

__asm isn't defined in either Standard; in both, identifiers of this
form are reserved to the implementation, so it's a permitted (and
quite reasonable) extension.

On Dec 13, 9:44=A0pm, "Tony" <nos...@myisp.net> wrote:
> robertwess...@yahoo.com wrote:
> > On Nov 28, 9:59 pm, "Tony" <nos...@nospicedham.myisp.net> wrote:
> >> If yes, then I will have questions that involve more than the syntax.
> >> Things like, well I'll just ask one.
>
> >> Microsoft has eliminated the inline assembler in it's 64-bit
> >> versions of Visual Studio. I was getting ready production code based
> >> upon C/C++/inline-assembly in 32-bit land, but now I will not deploy
> >> because of the removal of the inline assembler (and the imminent
> >> ubiquitousness of 64-bit computing in desktop and server
> >> environments). I feel "flabergasted" or something. Rug pulled out
> >> from under me! Your (any/all of you that I have yet to meet and are
> >> surely gurus of the technology) thoughts?
>
> > So write an external assembler subroutine.
>
> I just need control of the prologues. I'm not interested in developing
> entire routines in assembler. Just fixing some problems with those
> "standard" languages.


Write wrappers with the prolog/epilog code you want and call the C
routines with the normal convention?

But what are you doing at the application level where just modifying
the prologs gains you something?


> > There are other 64 bit C and C++ compilers for Windows, some of which
> > support inline assembler, although most of them are not as well suited
> > for developing Windows applications as are MS's compilers (GCC is a
> > good example, ICC is another, and rather better for writing Windows
> > applications that GCC - although it's not free).
>
> Well that non-MacroAssembler syntax doesn't appeal to me (it would wear
> out my % key surely).
>
>
>
> > Or just ship a 32 bit application. =A0Works just fine on x86-64 Windows
> > systems.
>
> I wanted to move to or start playing around in 64-bit though and the lack
> of inline assembler closed that door. I really like the VS IDE, so moving
> to (god-forbid) a commaneline compiler isn't really an option.


ICC works just fine under VS.  As does standalone assembler code with
MASM/ML.

You do realize the MS managed to write an entire OS without inline
assembler?  You may not agree with that approach, but it's hardly an
insurmountable obstacle.

robertwessel2@yahoo.com wrote:
> On Dec 13, 9:44 pm, "Tony" <nos...@myisp.net> wrote:
>> robertwess...@yahoo.com wrote:
>>> On Nov 28, 9:59 pm, "Tony" <nos...@nospicedham.myisp.net> wrote:
>>>> If yes, then I will have questions that involve more than the
>>>> syntax. Things like, well I'll just ask one.
>>
>>>> Microsoft has eliminated the inline assembler in it's 64-bit
>>>> versions of Visual Studio. I was getting ready production code
>>>> based upon C/C++/inline-assembly in 32-bit land, but now I will
>>>> not deploy because of the removal of the inline assembler (and the
>>>> imminent ubiquitousness of 64-bit computing in desktop and server
>>>> environments). I feel "flabergasted" or something. Rug pulled out
>>>> from under me! Your (any/all of you that I have yet to meet and are
>>>> surely gurus of the technology) thoughts?
>>
>>> So write an external assembler subroutine.
>>
>> I just need control of the prologues. I'm not interested in
>> developing entire routines in assembler. Just fixing some problems
>> with those "standard" languages.
>
>
> Write wrappers with the prolog/epilog code you want and call the C
> routines with the normal convention?

No, I want to return a value in a non-volatile register in addition to 
the return value that is in eax. See my other thread here for the issue 
in more detail.

>
> But what are you doing at the application level where just modifying
> the prologs gains you something?

Not at the application level: at the language level. Developing an 
interim language (a dialect of an existing language).

>
>
>>> There are other 64 bit C and C++ compilers for Windows, some of
>>> which support inline assembler, although most of them are not as
>>> well suited for developing Windows applications as are MS's
>>> compilers (GCC is a good example, ICC is another, and rather better
>>> for writing Windows applications that GCC - although it's not free).
>>
>> Well that non-MacroAssembler syntax doesn't appeal to me (it would
>> wear out my % key surely).
>>
>>
>>
>>> Or just ship a 32 bit application. Works just fine on x86-64 Windows
>>> systems.
>>
>> I wanted to move to or start playing around in 64-bit though and the
>> lack of inline assembler closed that door. I really like the VS IDE,
>> so moving to (god-forbid) a commaneline compiler isn't really an
>> option.
>
>
> ICC works just fine under VS.

ICC?

> As does standalone assembler code with
> MASM/ML.

Standalone assembler doesn't fit the bill right now for what I'm doing. 
It will for another project though (compiler dev).

>
> You do realize the MS managed to write an entire OS without inline
> assembler?  You may not agree with that approach, but it's hardly an
> insurmountable obstacle.

I'm not writing an OS. I'm developing a dialect (well, probably much more 
than just a dialect at this point) of an existing language. It seems to 
be working but haven't thrashed it out yet, but won't work on x86-64 with 
Visual Studio because they removed the inline assembler. 

On Dec 14, 6:05=A0am, "Tony" <nos...@nospicedham.myisp.net> wrote:
> robertwess...@yahoo.com wrote:
> > ICC works just fine under VS.
>
> ICC?


http://software.intel.com/en-us/articles/c-compilers/

robertwessel2@yahoo.com wrote:
> On Dec 14, 6:05 am, "Tony" <nos...@nospicedham.myisp.net> wrote:
>> robertwess...@yahoo.com wrote:
>>> ICC works just fine under VS.
>>
>> ICC?
>
>
> http://software.intel.com/en-us/articles/c-compilers/

Thanks for reminding me! (I get it now. I coulda had a V8!).

(I'll report back here on how my return of my 6-cylinder/alternator-based 
car went. Wish me luck!)

<-- hurries off to buy stock in General Electric to reduce cost per mile.