[Info-vax] OT: lightweight 90s viewer for Level 2 Postscript. Plus compiler-related obscureness.

[John Wallace]

On Aug 22, 11:39 pm, ChrisQ <m... at devnull.com> wrote:
> On 08/22/12 20:48, John Wallace wrote:
>
>
>
> > For the last few days I have been trying to sort an unfortuante
> > scenario where embedded compiler A does the right thing but embedded
> > compiler B doesn't, and for regulatory reasons life would be (much)
> > easier with compiler B.
>
> > Today I covered my desktop with five columns of A4. Four columns of
> > four sections where compiler A matches compiler B, and one for the one
> > where the differences are. Lots of scribbling. Green and white would
> > have been good too.
>
> I assume you are comparing asm source outputs ?. I know it's windows,
> but have found windiff quite usefull for comparing text files. It's a
> free download as well.
>
> As for the code, have you tried rewriting the buggy section in a different
> way, or unnest loops, simplify excessive levels of  if/then/else etc ?.
> Something i've had to do in the past to work around compiler bugs, though
> not for some years.
>
> Post more details. Source code snippet and asm output in both cases.
> Enquiring minds and all that :-).
>
>
>
> > A CDA-like implementation of something like PDF would in principle
> > have meant that compatible apps would be able to read a the text from
> > a PDF file, by means of some intervening layer whose API was all they
> > needed to know, without actually needing to know about PDF itself.
> > Gee, would anyone be able to use something like that?
>
> > Give it another ten years, maybe CDA will get reinvented and Apple or
> > MS will patent it in the US and elsewhere.
>
> I always liked vax decwrite, which I guess depended quite a bit on cda.
> Years before open orifice and actually very good.
>
> One of the problems I have with 90's era docs are that many are in
> postscript and it would be really, really good to find a simple, lean
> and fast postscript viewer...
>
> Regards,
>
> Chris

Quick one first: what OS is in your PS viewer requirement, bow old are
the documents (ie PS 2 vs PS 3)? Back in the 90s, RoPS was worth a
look in terms of fast, lightweight, low cost (but somewhat
unconventional) PS viewer for Windows. Still around, now has PS 3
support, but PS 3 will cost money (but for 90s documents that won't
matter as you won't need PS 3).

Wrt the other question... I can't say much (bills to pay) but here's
the highlights. They don't quite match your (entirely reasonable)
assumptions, in part because this is an "unusual" setup (though not
that unusual for its industry).

Compiler A: mature, used locally in regulatorily approved stuff,
passes industry standard tests but fails the recently introduced local
test suite (which *may* mean the test suite is currently broken).
Compiler B: new, shiny, passes industry standard tests and recently
introduced (and still developing) local test suite in this picture,
regulatory status: not yet qualified.

Only one of several failing subtests has currently been investigated
in any detail, but there are signs that several (if not all) of the
failures relate to the same underlying cause.

The tests for compiler A and compiler B use the same source (and
indeed the same build process, including the same makefiles, linker
config files, etc), but the results are different. So look at the
generated code and data and any other relevant files and work out
what's different and what differences make one set fail. Fortunately
it's a small embedded environment, only a tiny part of which is
relevant.

I could in principle have looked at the compiler intermediate .s
files, as per your assumption, but decided it was wise not to change
the build process in any way so I didn't have easy access to the .s
files. The existin build process does leave the interim object files
around so I did try looking at the disassembly of the intermediate .o
files.

Both of these interim file sets have the characteristic that addresses
aren't resolved at that stage, which depending on needs can be A Good
Thing or A Bad Thing. In this case I concluded that comparing all
those unresolved addresses all showing as zero was A Bad Thing.
Ultimately most of the comparison was performed on disassembly of
relevant sections of the fully linked executable, with fully resolved
addresses.

The two compilers don't allocate registers identically, and don't
always generate identically sequenced code within a block. So the same
source fed into the two different compilers can correctly generate
radically different instructions. And fully resolved addresses can be
validly different between the two file sets.

Classical text comparison tools don't handle this situation well,
whichever tool you pick (this month I have been mostly using diff,
kdiff3, and WinMerge, depending on context, though local IT suggest
BeyondCompare).

The Mark 1 Eyeball and some understanding of assembly code and
processor architecture for this project (please don't ask) is really
needed for this particular task-specific comparison, but this tends to
be slow, in short supply, and not 100% reliable without an independent
check (also in short supply). Locally available Mark 1 Eyeballs work
best with paper input which isn't restricted to 2 * 19" monitors and
can easily be scribbled on, but which is not entirely convenient for
the longer term record.

After days of analysis not just of disassembled source but of gdb
trace logs, the code turns out to be functionally identical anyway,
according to current analysis. The failing is in the data generated by
the compiler(s) as part of the test input.

An array of pointers to variables is involved as input in several of
the failing tests. In the 'fully' investigated test, in the one which
passes, the array of pointers is allocated in ROM and all is well. In
the one which fails, the array of pointers is allocated in BSS and
does not appear to be initialised (this bit needs analysing further).
So when the array is passed to the routine that uses it, there's
nothing there for it to use (in the failing case). There is no accvio/
segfault, but obviously the result isn't what is expected either.

Sorry, no actual code snippets, but you can hopefully work it out.
Just think of an array of "char *" and you're not far wrong.

That was the situation at the end of yesterday. Work continues today.

It wasn't that exciting, was it?