Re: Re: [PATCHES] s_lock.h cleanup

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Re: [PATCHES] s_lock.h cleanup
Дата
Msg-id 200101191839.NAA03380@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: Re: [PATCHES] s_lock.h cleanup  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> 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,
Pennsylvania19026
 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Re: [PATCHES] s_lock.h cleanup
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Re: [PATCHES] s_lock.h cleanup