s_lock.h cleanup

As long as we're cleaning things up, I would suggest that all the ports
that use gcc assembler be made to declare it uniformly, as

__asm__ __volatile__ ( ... );

As I read the GCC manual, there's some risk of the asm sections getting
moved around in the program flow if they are not marked volatile. Also
we oughta be consistent about using the double-underscore keywords IMHO.

regards, tom lane

Done and applied.

As long as we're cleaning things up, I would suggest that all the ports
that use gcc assembler be made to declare it uniformly, as

__asm__ __volatile__ ( ... );

As I read the GCC manual, there's some risk of the asm sections getting
moved around in the program flow if they are not marked volatile. Also
we oughta be consistent about using the double-underscore keywords IMHO.

regards, tom lane

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

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 that all
assemblers have equally forgiving lexical rules as a certain subset of
said assemblers. For example, the VAX code does not look at all like the
one back when it still worked.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

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 that all
assemblers have equally forgiving lexical rules as a certain subset of
said assemblers. For example, the VAX code does not look at all like the
one back when it still worked.

I agree the VAX code was changed in the patch, but the VAX person sent
email that he had to add the semicolons to make it work on his platform,
and that the original " \n\" code did compile at all.

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.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Peter Eisentraut <peter_e@gmx.net> 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 believe in this patch at all. It makes the assumption that all
assemblers have equally forgiving lexical rules as a certain subset of
said assemblers. For example, the VAX code does not look at all like the
one back when it still worked.

Good point. I think it's safe to use the split-up-string-literal
feature, but assuming that ';' can replace '\n' is sheer folly, and so
is assuming that whitespace doesn't matter (ie, that opcodes starting
in column 1 are OK). Bruce, I'd suggest a format more like

"[label] opcode operands \n"

for each line of assembly code.

regards, tom lane

Bruce Momjian <pgman@candle.pha.pa.us> 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.

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.

regards, tom lane

Peter Eisentraut <peter_e@gmx.net> 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 believe in this patch at all. It makes the assumption that all
assemblers have equally forgiving lexical rules as a certain subset of
said assemblers. For example, the VAX code does not look at all like the
one back when it still worked.

Good point. I think it's safe to use the split-up-string-literal
feature, but assuming that ';' can replace '\n' is sheer folly, and so
is assuming that whitespace doesn't matter (ie, that opcodes starting
in column 1 are OK). Bruce, I'd suggest a format more like

"[label] opcode operands \n"

for each line of assembly code.

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?

I see non-gcc stuff in s_lock.c, but I didn't touch that. I also see
volatile missing in s_lock.c, which I will add for GCC entries.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> 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.

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.

Oh, wow, I never suspected gcc could work without gas. Can it?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> 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.

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.

regards, tom lane

I can tell you that they all used __asm__, and all used the colon
terminators for each __asm__ block:

* __asm__ __volatile__(
* "command;"
* "command;"
* "command;"
* : "=r"(_res) return value, in register
* : "r"(lock) argument, 'lock pointer', in register
* : "r0"); inline code uses this register

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> 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__ block:

* __asm__ __volatile__(
* "command;"
* "command;"
* "command;"
* : "=r"(_res) return value, in register
* : "r"(lock) argument, 'lock pointer', in register
* : "r0"); inline code uses this register

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 verbatim by gcc to the assembler, and the assembler may
not be nearly as forgiving as you think.

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.

Bottom line: I see no point in taking any risks, especially not this
late in beta, with code that you cannot test for yourself, and
*especially* not when the change is only for cosmetic reasons.

regards, tom lane

* Tom Lane <tgl@sss.pgh.pa.us> [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 standard assembler
and linker are used.

Bottom line: I see no point in taking any risks, especially not this
late in beta, with code that you cannot test for yourself, and
*especially* not when the change is only for cosmetic reasons.

I agree with this sentiment.

LER

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Bruce Momjian <pgman@candle.pha.pa.us> 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 a29k, AVR, CRIS, d10v, d30v, FR30,
H8/300, HP/PA, TIC30, TIC54x, or TIC80.

Aren't you glad you know that now?

Ian
Former GNU binutils maintainer

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Bruce Momjian <pgman@candle.pha.pa.us> 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.

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.

Oh, wow, I never suspected gcc could work without gas. Can it?

Yes.

In fact, I don't think there is any Unix system on which gcc requires
gas. There used to be at least one, but I think they have all been
cleaned up at this point.

Ian

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 verbatim by gcc to the assembler, and the assembler may
not be nearly as forgiving as you think.

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.

Bottom line: I see no point in taking any risks, especially not this
late in beta, with code that you cannot test for yourself, and
*especially* not when the change is only for cosmetic reasons.

OK, remove semicolons and put back the \n at the end of each line.
Patch attached.

I wasn't going to mess with this while in beta, but when I found the VAX
code broken, it seemed worth making sure they were all OK. The VAX
stuff was broken because in 7.0.3 it shows:

__asm__(" movl $1, r0 \
bbssi $0, (%1), 1 f \
clrl r0 \
1: movl r0, %0 "

The '1 f' we broken, but also the thing missing here is \n\. With \, it
just makes one long line, which certainly can't be asembled. The VAX
guy added semicolons, but I can see that \n\ is safer, and have done
that.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026