Re: Re: [PATCHES] s_lock.h cleanup - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: [PATCHES] s_lock.h cleanup
Date
Msg-id 9458.979928691@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCHES] s_lock.h cleanup  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Re: [PATCHES] s_lock.h cleanup  (Bruce Momjian <pgman@candle.pha.pa.us>)
List 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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Mikheev, Vadim"
Date:
Subject: RE: Possible performance improvement: buffer replacemen t policy
Next
From: Tom Lane
Date:
Subject: Re: Re: [PATCHES] s_lock.h cleanup