> The __asm___ and splitting up the assembly code into multiple string
> literals and the consistent formatting of the register addendums are
> all fine, because those are read by gcc and this whole code block is
> gcc-only. But the assembly code string literal will be spit out
> essentially verb
Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > I believe the formatting problem was that some code had
> > > "command;command; : lkjasfd : asldfk" while some had them spread over
> > > separate lines, and others used \n\, all very randomly. Now at l
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Interestingly, we have very few non-gcc ASM entries in s_lock.h. The
> only non-gcc one I see are Univel/i386, and I didn't touch that. Isn't
> the semicolon the standard command terminator for all gcc assemblers?
No.
It is for most, but not for the
* Tom Lane <[EMAIL PROTECTED]> [010119 13:08]:
>
> > Oh, wow, I never suspected gcc could work without gas. Can it?
>
> Gcc with platform-specific as used to be the standard configuration
> on HPUX, and may still be standard on some platforms.
Still is the standard on UnixWare with GCC. The st
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I believe the formatting problem was that some code had
> > "command;command; : lkjasfd : asldfk" while some had them spread over
> > separate lines, and others used \n\, all very randomly. Now at least
> > they are all consistent and use similar fo
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I believe the formatting problem was that some code had
> > "command;command; : lkjasfd : asldfk" while some had them spread over
> > separate lines, and others used \n\, all very randomly. Now at least
> > they are all consistent and use similar fo
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> And they may all be broken, except for the one(s) you have tested.
>> You shouldn't be assuming that a platform that uses gcc necessarily
>> also uses gas.
> I can tell you that they all used __asm__, and all used the colon
> terminators for each __asm
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Bruce Momjian writes:
> >> In looking at the VAX ASM problem, I realized that the ASM in s_lock.h
> >> is all formatted differently, making it even more confusing. I have
> >> applied the following patch to s_lock.h to try and clean it up.
>
> >
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I believe the formatting problem was that some code had
> "command;command; : lkjasfd : asldfk" while some had them spread over
> separate lines, and others used \n\, all very randomly. Now at least
> they are all consistent and use similar formatting.
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Bruce Momjian writes:
>> In looking at the VAX ASM problem, I realized that the ASM in s_lock.h
>> is all formatted differently, making it even more confusing. I have
>> applied the following patch to s_lock.h to try and clean it up.
> I don't belie
> Bruce Momjian writes:
>
> > In looking at the VAX ASM problem, I realized that the ASM in s_lock.h
> > is all formatted differently, making it even more confusing. I have
> > applied the following patch to s_lock.h to try and clean it up.
>
> I don't believe in this patch at all. It makes th
Bruce Momjian writes:
> In looking at the VAX ASM problem, I realized that the ASM in s_lock.h
> is all formatted differently, making it even more confusing. I have
> applied the following patch to s_lock.h to try and clean it up.
I don't believe in this patch at all. It makes the assumption t
12 matches
Mail list logo
