23 May
2012
23 May
'12
1:54 p.m.
I was wondering if there are any VAX coders on the list who are
willing (and brave/strange enough) to poke into gcc internals?
I have a (relatively speedy) little VAXstation 4000/90 happily
running NetBSD-6, which is built using gcc-4.1.
All of the other NetBSD ports have switched across to gcc-4.5, but
some changes in 4.5 have caused codegen issues in the VAX backend.
Essentially you can cross compile a vax system with gcc-4.5, but
the resultant system exhibits certain, shall we say, glitches (most
annoyingly in the boot program), and the generated compiler is
unable to reliably compile anything.
Additionally the gcc DWARF2 stack unwinding for VAX appears to be
incomplete, causing issues for C++ exceptions, and potentially
making libffi unbuildable on VAX.
( http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=44155 )
The latter point is quite annoying as it blocks building glib2,
and any app that depends upon it.
I know the VAX is pretty much the poster child for legacy platform
nowdays, but from a certain perspective a VAX has similar
characteristics to an unusual embedded system, (just built using
steam pipes & valves), so should be able to run the same basic
apps, tools, and even graphical apps.
Besides, to quote Dylan Thomas I feel the VAX should not go gentle
into that good night, but rage, rage against the dying of the light
:)
23 May
23 May
2:35 p.m.
On Wed, May 23, 2012 at 1:54 PM, David Brownlee <abs at absd.org> wrote:
I was wondering if there are any VAX coders on the
list who are
willing (and brave/strange enough) to poke into gcc internals?
A noble cause, but I have no spare cycles and will not for some time.
If you are still recruiting for this in the Fall, I may be able to put
in some effort.
I have real VAXen on hand (including a lesser model of VAXstation
4000), and used to grub down in the guts of compiler output back when
we were transitioning from Whitesmith C to VAX (DEC) C.
Good luck!
-ethan
7:13 p.m.
On 23 May 2012 19:35, Ethan Dicks <ethan.dicks at gmail.com> wrote:
On Wed, May 23, 2012 at 1:54 PM, David Brownlee
<abs at absd.org> wrote:
As I just mentioned in another reply, if come the fall you are looking for
a real VAX compiler project to get into then an LLVM backend for vax
code generation could be probably more work but much less frustration
than fixing up the gcc vax codegen :)
I was wondering if there are any VAX coders on
the list who are
willing (and brave/strange enough) to poke into gcc internals?
A noble cause, but I have no spare cycles and will not for some time.
If you are still recruiting for this in the Fall, I may be able to put
in some effort.
I have real VAXen on hand (including a lesser model of VAXstation
4000), and used to grub down in the guts of compiler output back when
we were transitioning from Whitesmith C to VAX (DEC) C. 
3:47 p.m.
Probably the best thing to do is reproduce the problem on an emulation
platform and start reporting the issues to the gcc group. I doubt that
they have access to do builds to do their verification, so working to be
the supporter of the vax with the emulated or real platform would be the
other thing to do.
I don't know if they have automated test suites to test all of this, but
I'd hope the core development group isn't hand testing everything for
regression problems.
Have they stated that they are actively going to remove the support at
some time? Then you're probably on your own.
However the access to the platform is probably the crucial key thing.
Having a way to download an emulator, vm image with compiler development
tools installed would greatly boost the effort.
Jim
On 5/23/2012 10:54 AM, David Brownlee wrote:
I was wondering if there are any VAX coders on the
list who are
willing (and brave/strange enough) to poke into gcc internals?
I have a (relatively speedy) little VAXstation 4000/90 happily
running NetBSD-6, which is built using gcc-4.1.
All of the other NetBSD ports have switched across to gcc-4.5, but
some changes in 4.5 have caused codegen issues in the VAX backend.
Essentially you can cross compile a vax system with gcc-4.5, but
the resultant system exhibits certain, shall we say, glitches (most
annoyingly in the boot program), and the generated compiler is
unable to reliably compile anything.
Additionally the gcc DWARF2 stack unwinding for VAX appears to be
incomplete, causing issues for C++ exceptions, and potentially
making libffi unbuildable on VAX.
( http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=44155 )
The latter point is quite annoying as it blocks building glib2,
and any app that depends upon it.
I know the VAX is pretty much the poster child for legacy platform
nowdays, but from a certain perspective a VAX has similar
characteristics to an unusual embedded system, (just built using
steam pipes& valves), so should be able to run the same basic
apps, tools, and even graphical apps.
Besides, to quote Dylan Thomas I feel the VAX should not go gentle
into that good night, but rage, rage against the dying of the light
:)
5:01 p.m.
On Wed, 23 May 2012 12:47:40 -0700, jim s <jws at jwsss.com> wrote:
Probably the best thing to do is reproduce the problem
on an
emulation platform and start reporting the issues to the gcc group. I
doubt that they have access to do builds to do their verification, so
working to be the supporter of the vax with the emulated or real
platform would be the other thing to do.
I don't know if they have automated test suites to test all of this,
but I'd hope the core development group isn't hand testing everything
for regression problems.
The best test suite there is for a compiler:
ITSELF.
The normal workflow when compiling gcc is to have it build itself.
One of the last steps before installation was to check for differences
between
one build of the compiler and the result of the same build iteration
build of itself.
24 May
24 May
9:11 a.m.
The best test suite there is for a compiler:
ITSELF.
The normal workflow when compiling gcc is to have it
build itself.
At least one version of gcc has documentation calling that test suite
"surprisingly weak". I would concur; for example, gcc is designed to
be buildable with other compilers, so it doesn't use any of its own
extensions, meaning compiling itself doesn't test those extensions.
In general, any program not designed as a test suite is unlikely to be
a good test suite. (It is more likely to be _part of_ a good test
suite.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
2:05 p.m.
New subject: Compilers (Was: Calling all bored VAX hackers :)
On Wed, 23 May 2012, Stefan Skoglund wrote:
The best test suite there is for a compiler:
ITSELF.
The normal workflow when compiling gcc is to have it build itself.
One of the last steps before installation was to check for differences
between one build of the compiler and the result of the same build
iteration build of itself.
While it is an essential (arguable about whether truly NECESSARY) rite of
passage for the compiler's development, often there are BETTER test suites
for a compiler. The test suites should include large bodies of the kind
of code that the compiler is intended to process. For example, a compiler
for handling scientific calculations should be tested with a lot of those,
which is NOT what compiling the compiler will test.
If a compiler is being created for use in teaching beginners a language,
then perhaps the most important aspect of it would be the code-error
handling and reporting, whereas compiling the compiler is going to have
little or none of that. By the time the compiler is compiling itself,
there will presumably not be errors, and how many instances
(non-deliberate) will there be of
if(a=b)
if(...);
that the compiler should produce WARNINGs (not ERRORs) for?
Should the compiler suppress the warnings on the common case of
while(*t++=*s++); ?
Veering off onto that tangent (Compilers for Language Teaching), . . .
I would have loved to have had a C compiler explicitly for
TEACHING C that would have included a warning of
"WARNING: While valid C code, your prof will FLUNK YOU,
and you will get fired from jobs, if you don't improve
readability with some indenting!"
and
"WARNING: while valid C code, your total lack of comments will likely
be unacceptable to whomever you are writing this program for!"
"WARNING: while possibly valid, you have used a constant without
esplanation of its origin. Consider adding a comment to explain
what it is and where it came from."
"WARNING: when plagiarizing somebody else's project,
change more than just the variable names."
(OK, THAT is still a manual correction and message)
YES, teaching how to program in C (or any other language) is NOT
just about the technical requirements of the language itself.
YES, when teaching C (and other languages), I DID have requirements
besides that the program compile, run, and produce the correct output.
The GOALS are different when writing a program to perform a
specific task V writing a program to demonstrate proficiency.
3:26 p.m.
New subject: Compilers (Was: Calling all bored VAX hackers :)
On Wed, 23 May 2012, Stefan Skoglund wrote:
The best test suite there is for a compiler:
ITSELF.
The normal workflow when compiling gcc is to have it build itself.
One of the last steps before installation was to check for
differences between one build of the compiler and the result of
the
same build iteration build of itself.
Speaking as an old compiler wrangler, I strongly dispute this
statement. People who write compilers (and I'm one of them) tend to
be blind to various aspects of the language. While a compiler may
consistently produce working code from the source that you yourself
write, a compiler author should never be allowed near the testing of
the product.
For ANSI-specified products, there are standards conformance and
autiting tests. One of my fondest nightmares was running the Navy
COBOL audit tests against a new version of the compiler.
You see, there are several types of errors. There are the "this
generates code, but the code doesn't work" type of tests and then
there's the "I can write this statement and produce working code, but
the standard says that it's an error to accept the statement at all"
type of test. Some of the more frustrating tests can be those that
test conformance with the language specification.
Optimization can be another great steaming mass of trouble. Some
optimizations may appear to be benign, but turn out to be anything
but.
For a language as vast as C++, I'd never trust any code that I wrote
to find all of the chinks in the armor.
--Chuck
6:25 p.m.
New subject: Compilers (Was: Calling all bored VAX hackers :)
On 24/05/2012 20:26, Chuck Guzis wrote:
On Wed, 23 May 2012, Stefan Skoglund wrote:
> The best test suite there is for a compiler:
> ITSELF.
Not true. I spent ages trying to fix a bug in the old IBM370 GCC code
generator. It looked like the floating point was failing but it was
actually generating code for unsigned short operations.
The normal
workflow when compiling gcc is to have it build itself.
One of the last steps before installation was to check for
differences between one build of the compiler and the result of
the
same build iteration build of itself.
Speaking as an old compiler wrangler, I strongly dispute this
statement. People who write compilers (and I'm one of them) tend to
be blind to various aspects of the language. While a compiler may
consistently produce working code from the source that you yourself
write, a compiler author should never be allowed near the testing of
the product.
For ANSI-specified products, there are standards conformance and
autiting tests. One of my fondest nightmares was running the Navy
COBOL audit tests against a new version of the compiler.
You see, there are several types of errors. There are the "this
generates code, but the code doesn't work" type of tests and then
there's the "I can write this statement and produce working code, but
the standard says that it's an error to accept the statement at all"
type of test. Some of the more frustrating tests can be those that
test conformance with the language specification.
Optimization can be another great steaming mass of trouble. Some
optimizations may appear to be benign, but turn out to be anything
but.
For a language as vast as C++, I'd never trust any code that I wrote
to find all of the chinks in the armor.
--Chuck
3:27 p.m.
Stefan,
I know that is probably the case, not arguing that. However someone has
to regularly check and report the errors in some intelligent fashion
back to the compiler group, or they won't get acted upon. If someone
here can do that more the better, but I'm betting that maybe that
platform lacks a champion in the compiler developer group, and it may be
off the radar.
My buddy took up the cause for the c++ boost package as well as the ace
macro set for the S390. The gcc group supports s390, but a lot of the
other open source tool sets like these, not so much.
jim
On 5/23/2012 2:01 PM, Stefan Skoglund wrote:
On Wed, 23 May 2012 12:47:40 -0700, jim s<jws at jwsss.com> wrote:
Probably the best thing to do is reproduce the
problem on an
emulation platform and start reporting the issues to the gcc group. I
doubt that they have access to do builds to do their verification, so
working to be the supporter of the vax with the emulated or real
platform would be the other thing to do.
I don't know if they have automated test suites to test all of this,
but I'd hope the core development group isn't hand testing everything
for regression problems.
The best test suite there is for a compiler:
ITSELF.
The normal workflow when compiling gcc is to have it build itself.
One of the last steps before installation was to check for differences
between
one build of the compiler and the result of the same build iteration
build of itself.
23 May
23 May
7:10 p.m.
On 23 May 2012 20:47, jim s <jws at jwsss.com> wrote:
Probably the best thing to do is reproduce the problem
on an emulation
platform and start reporting the issues to the gcc group. ?I doubt that they
have access to do builds to do their verification, so working to be the
supporter of the vax with the emulated or real platform would be the other
thing to do.
I should be able to setup simh and install & reproduce inside it. I have
two easy to reproduce fail cases - gcc, and the boot program. The
latter is much smaller and potentially easier to test, as it just fails to
run and can be worked around with appropriate optimisation flags.
I don't know if they have automated test suites to
test all of this, but I'd
hope the core development group isn't hand testing everything for regression
problems.
I'm assuming they have some continual integration environment setup. Doesn't
everyone now? :) NetBSD does, but only for certain architectures so far - I
believe just sparc64, i386 & amd64 and macppc. Might be interesting to get
vax added onto the list to try to determine if there is any other compiler
codegen fallout... hmmm.
Have they stated that they are actively going to
remove the support at some
time? ?Then you're probably on your own.
Well, they accepted back a set of patches to fix vax codegen issues for 4.1,
and I suspect they will leave it as long as there is some life, but if
we had someone
wanting to do serious vax compiler work then writing a backend for llvm would
probably be a better longterm goal.
However the access to the platform is probably the
crucial key thing.
?Having a way to download an emulator, vm image with compiler development
tools installed would greatly boost the effort.
Well for NetBSD the dev tools is probably the easiest stage as you
just to download
the source onto pretty much any posix system and run './build.sh -m
vax tools', or
'./build.sh -m vax release' to build the full release :)
I'll definitely look at getting a test emulator image setup - thanks
for the pointer!
5:43 p.m.
Hi David!
On Wed, 2012-05-23 18:54:24 +0100, David Brownlee <abs at absd.org> wrote:
All of the other NetBSD ports have switched across to
gcc-4.5, but
some changes in 4.5 have caused codegen issues in the VAX backend.
Essentially you can cross compile a vax system with gcc-4.5, but
the resultant system exhibits certain, shall we say, glitches (most
annoyingly in the boot program), and the generated compiler is
unable to reliably compile anything.
ISTR that the breakage was already traced down to one single
optimization pass. To get that fixed, the first thing would be to
have a GCC bugzilla ticket for it (I'm not sure if anybody opened one.)
At least, I couldn't find one ad hoc when I tried a simple bugzilla
search.
MfG, JBG
--
Jan-Benedict Glaw jbglaw at lug-owl.de +49-172-7608481
Signature of: They that give up essential liberty to obtain temporary safety,
the second : deserve neither liberty nor safety. (Ben Franklin)
4391
days inactive
4392
days old
11 comments
9 participants
participants (9)
-
abs＠absd.org -
cclist＠sydex.com -
cisin＠xenosoft.com -
cpuser_stefskog＠bredband.net -
dave.g4ugm＠gmail.com -
ethan.dicks＠gmail.com -
jbglaw＠lug-owl.de -
jws＠jwsss.com -
mouse＠Rodents-Montreal.ORG