* Re: [TUHS] DEC Compilers (was: Re: SDB debugger
@ 2020-05-06 2:52 Doug McIlroy
0 siblings, 0 replies; 8+ messages in thread
From: Doug McIlroy @ 2020-05-06 2:52 UTC (permalink / raw)
To: tuhs
> random small C programs with computable expected outputs
"computable" is subtle here. The only way to compute the
outputs was to run the program. McKeeman's trick was to
sic several completely unrelated compilers on the program
and let them vote on the answer.
Compile time was measured. My favorite "bug" was the
mmany minutes it took to compile a constant expression
that involved shifting a constant INT_MAX bits by
performing that many 1-bit shifts.
Doug
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [TUHS] DEC Compilers (was: Re: SDB debugger
@ 2020-05-06 15:53 Doug McIlroy
2020-05-06 20:21 ` Tim Rylance
0 siblings, 1 reply; 8+ messages in thread
From: Doug McIlroy @ 2020-05-06 15:53 UTC (permalink / raw)
To: tuhs
>> Compile time was measured. My favorite "bug" was the
>> many minutes it took to compile a constant expression
>> that involved shifting a constant INT_MAX bits by
>> performing that many 1-bit shifts.
>
> I don't know if this anecdote is an urban legend or if it really
> happened. I was told [a similar] story when I was interning as an operator
> at my alma mater, which was an IBM System/360 shop.
I heard it not from the grapevine, but from McKeeman himself.
Doug
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [TUHS] DEC Compilers (was: Re: SDB debugger
2020-05-06 15:53 Doug McIlroy
@ 2020-05-06 20:21 ` Tim Rylance
0 siblings, 0 replies; 8+ messages in thread
From: Tim Rylance @ 2020-05-06 20:21 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 1570 bytes --]
>>> Compile time was measured. My favorite "bug" was the
>>> many minutes it took to compile a constant expression
>>> that involved shifting a constant INT_MAX bits by
>>> performing that many 1-bit shifts.
>>
>> I don't know if this anecdote is an urban legend or if it really
>> happened. I was told [a similar] story when I was interning as an operator
>> at my alma mater, which was an IBM System/360 shop.
>
> I heard it not from the grapevine, but from McKeeman himself.
It’s mentioned in the paper (https://www.hpl.hp.com/hpjournal/dtj/vol10num1/vol10num1art9.pdf <https://www.hpl.hp.com/hpjournal/dtj/vol10num1/vol10num1art9.pdf>) on page 105, table 1
Results of Testing C Compilers
Source Code Resulting Problem
1>>INT_MAX Twenty-minute compile time
but not explained.
My favourite is
int(…(x)…) enough nested parentheses to kill the compiler
Spurious diagnostic (10 parentheses)
Compiler crash (100 parentheses)
Server crash (10,000 parentheses)
explained on page 104:
… the server crash occurred when the tested compiler got a stack overflow on a heavily loaded machine with a very large memory. The operating system attempted to dump a gigabyte of compiler stack, which caused all the other active users to thrash, and many of them also dumped for lack of memory. The many disk drives on the server began a dance of the lights that sopped up the remaining free resources, causing the operators to boot the server to recover. Excellent testing can make you unpopular with almost everyone.
[-- Attachment #2: Type: text/html, Size: 2960 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* [TUHS] SDB debugger
@ 2020-05-01 20:48 Paul Ruizendaal
2020-05-02 0:49 ` Noel Hunt
0 siblings, 1 reply; 8+ messages in thread
From: Paul Ruizendaal @ 2020-05-01 20:48 UTC (permalink / raw)
To: TUHS main list
Reading some more stuff about the road from 7th Edition to 8th Edition, this time about debuggers.
My current understanding is as follows:
- On 6th edition the debugger was ‘cdb’
- On 7th edition it was ‘adb’, a rewrite / evolution from ‘cdb’
- In 32V a new debugger appears, ‘sdb’. Its code seems a derivative from ‘adb’, but the command language is substantially reworked and it uses a modified variant of the a.out linker format - in essence the beginnings of ‘stabs’. Of course the compiler, assembler, linker and related tools all emit/recognize these new symbol table elements.
- The July 78 file note by London/Reiser does not mention a reworked debugger at all; the 32V tape that is on TUHS has ’sdb' files that are dated Feb/Mar 1979. This stuff must have been developed between July 78 and March 79.
- In the SysIII and 3BSD code on TUHS (from early 80 and late 79 respectively) the stabs format is more developed. For SysIII it is ‘VAX only’. With these roots, it is not surprising that it is also in 8th Edition.
Two questions:
(1) According to Wikipedia the original author of the stabs format is unknown. It also says that the original author of ‘sdb’ is unknown. Is that correct, is the author really unknown?
(2) As far as I can tell, the ’sdb’ debugger was never back ported to 16 bit Unix, not in the SysIII line and not in the 2.xBSD line. It would seem to me that the simple stabs format of 32V would have lent itself to being back ported. Is it correct that no PDP11 Unix used (a simple) stabs tool chain and debugger?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [TUHS] SDB debugger
2020-05-01 20:48 [TUHS] " Paul Ruizendaal
@ 2020-05-02 0:49 ` Noel Hunt
2020-05-02 20:16 ` Paul Ruizendaal
0 siblings, 1 reply; 8+ messages in thread
From: Noel Hunt @ 2020-05-02 0:49 UTC (permalink / raw)
To: Paul Ruizendaal; +Cc: TUHS main list
[-- Attachment #1: Type: text/plain, Size: 1995 bytes --]
When it comes to Eight Edition, please don't forget Tom Cargill's
'pi'. There was also a version I believe that was used as the
debugger for programs on the Blit/Jerq; it seems to be known as
'4pi' in the source.
On Sat, May 2, 2020 at 6:49 AM Paul Ruizendaal <pnr@planet.nl> wrote:
> Reading some more stuff about the road from 7th Edition to 8th Edition,
> this time about debuggers.
>
> My current understanding is as follows:
>
> - On 6th edition the debugger was ‘cdb’
>
> - On 7th edition it was ‘adb’, a rewrite / evolution from ‘cdb’
>
> - In 32V a new debugger appears, ‘sdb’. Its code seems a derivative from
> ‘adb’, but the command language is substantially reworked and it uses a
> modified variant of the a.out linker format - in essence the beginnings of
> ‘stabs’. Of course the compiler, assembler, linker and related tools all
> emit/recognize these new symbol table elements.
>
> - The July 78 file note by London/Reiser does not mention a reworked
> debugger at all; the 32V tape that is on TUHS has ’sdb' files that are
> dated Feb/Mar 1979. This stuff must have been developed between July 78 and
> March 79.
>
> - In the SysIII and 3BSD code on TUHS (from early 80 and late 79
> respectively) the stabs format is more developed. For SysIII it is ‘VAX
> only’. With these roots, it is not surprising that it is also in 8th
> Edition.
>
>
> Two questions:
>
> (1) According to Wikipedia the original author of the stabs format is
> unknown. It also says that the original author of ‘sdb’ is unknown. Is that
> correct, is the author really unknown?
>
> (2) As far as I can tell, the ’sdb’ debugger was never back ported to 16
> bit Unix, not in the SysIII line and not in the 2.xBSD line. It would seem
> to me that the simple stabs format of 32V would have lent itself to being
> back ported. Is it correct that no PDP11 Unix used (a simple) stabs tool
> chain and debugger?
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 2659 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [TUHS] SDB debugger
2020-05-02 0:49 ` Noel Hunt
@ 2020-05-02 20:16 ` Paul Ruizendaal
2020-05-03 16:13 ` Clem Cole
0 siblings, 1 reply; 8+ messages in thread
From: Paul Ruizendaal @ 2020-05-02 20:16 UTC (permalink / raw)
To: TUHS main list
Thanks, all, for that input.
The ddt debugger appears to be a fork of 5th edition cdb. It survived in the Interdata 7/32 port:
https://www.tuhs.org/cgi-bin/utree.pl?file=Interdata732/usr/source/chicago
It appears to have originated from Bill Allen at the Naval Postgraduate School.
Some more reading appears to show a much more gradual development than I first thought. Working along Doug’s list:
- First there was db, which claims to be loosely based on DEC’s ODT in its man page. Written in assembler.
- Then there is cdb, a rewrite in C, as from 3rd edition. Judging from the man pages, in 3rd and 4th edition it is a mostly incomplete project.
- The first reasonably complete version of cdb appears in 5th edition. It only handles “normal” symbols (see below for “normal”). The ddt debugger forks from this version, presumably to fill in some missing features (e.g. access to non-C identifiers, single stepping, etc.; I have not done a full feature comparison).
- In 6th edition “pseudo” symbols are introduced: symbols starting with a tilde that provide names for auto and register variables. The cdb debugger is updated to allow references to local variables using a “procname:varname” syntax. The ddt debugger picked this up as well. It is a first step towards the stabs format.
I would assume that db and cdb are the work of dmr/ken.
- In 7th edition there is the new adb, by Steve Bourne. Main focus of adb appears to have been portability more than major new features. Again, I have not compared the feature sets of ddt and adb to see if there was an influence.
- In 32V the symbol format is changed: (i) the “tilde hack” is replaced by a new assembler pseudo op “.stabs”; (ii) this is then used to include more pseudo symbols, for line numbers, for file names, etc.; (iii) the symbol struct is extended with a field to hold the symbol's type. It is essentially stabs, but with 8 char names. A new source level debugger, sdb, allows source level debugging. Its command language is the first to feel like a gdb ancestor. Author Howard Katseff.
The dbx debugger appears to stand on the shoulders of sdb, and gdb on the shoulders of dbx.
In 8th edition there are 3 debuggers: adb, sdb and pi (for use with the Blit).
> On 2 May 2020, at 02:49, Noel Hunt <noel.hunt@gmail.com> wrote:
>
> When it comes to Eight Edition, please don't forget Tom Cargill's
> 'pi'. There was also a version I believe that was used as the
> debugger for programs on the Blit/Jerq; it seems to be known as
> '4pi' in the source.
>
>
> On Sat, May 2, 2020 at 6:49 AM Paul Ruizendaal <pnr@planet.nl> wrote:
> Reading some more stuff about the road from 7th Edition to 8th Edition, this time about debuggers.
>
> My current understanding is as follows:
>
> - On 6th edition the debugger was ‘cdb’
>
> - On 7th edition it was ‘adb’, a rewrite / evolution from ‘cdb’
>
> - In 32V a new debugger appears, ‘sdb’. Its code seems a derivative from ‘adb’, but the command language is substantially reworked and it uses a modified variant of the a.out linker format - in essence the beginnings of ‘stabs’. Of course the compiler, assembler, linker and related tools all emit/recognize these new symbol table elements.
>
> - The July 78 file note by London/Reiser does not mention a reworked debugger at all; the 32V tape that is on TUHS has ’sdb' files that are dated Feb/Mar 1979. This stuff must have been developed between July 78 and March 79.
>
> - In the SysIII and 3BSD code on TUHS (from early 80 and late 79 respectively) the stabs format is more developed. For SysIII it is ‘VAX only’. With these roots, it is not surprising that it is also in 8th Edition.
>
>
> Two questions:
>
> (1) According to Wikipedia the original author of the stabs format is unknown. It also says that the original author of ‘sdb’ is unknown. Is that correct, is the author really unknown?
>
> (2) As far as I can tell, the ’sdb’ debugger was never back ported to 16 bit Unix, not in the SysIII line and not in the 2.xBSD line. It would seem to me that the simple stabs format of 32V would have lent itself to being back ported. Is it correct that no PDP11 Unix used (a simple) stabs tool chain and debugger?
>
>
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [TUHS] SDB debugger
2020-05-02 20:16 ` Paul Ruizendaal
@ 2020-05-03 16:13 ` Clem Cole
2020-05-03 17:13 ` Henry Bent
0 siblings, 1 reply; 8+ messages in thread
From: Clem Cole @ 2020-05-03 16:13 UTC (permalink / raw)
To: Paul Ruizendaal; +Cc: TUHS main list
[-- Attachment #1: Type: text/plain, Size: 2324 bytes --]
On Sat, May 2, 2020 at 4:16 PM Paul Ruizendaal <pnr@planet.nl> wrote:
> The dbx debugger appears to stand on the shoulders of sdb, and gdb on the
> shoulders of dbx.
>
Mumble ... It's true rms started with dbx and peed on it in their
usually way - similar to the Gosling EMACS to GnuEMACS story.
But Mark wrote DBX from scratch, although I would be surprised if looked
at how adb and sdb handled the symbol table and could have lifted that code
from their. If I remember discussions with him about it, his interface
model was really more VMS debugger more than sdb. As I said, I really
don't remember anyone at UCB in those days using sdb.
At the time, there was a huge push (mostly from the Stanford crew) to make
VMS the Arpa standard system replacing the PDP-10, TOPS, Tenex, ITS, et
al. Besides the performance argument (hence the 4.1 FASTVAX work), one of
the arguments from the pro-VMS side was the language toolchain, including
comments that UNIX did not have a debugger in the same vein as VMS (and
also that the Fortran system was considered pretty weak).
When he was still at UCB, Mark had tried to make sure dbx worked with both
C and Fortran (i.e. at the beginning of the project I did some testing for
him because I was working on a large array processor in the CAD group, that
needed to compile EE CAD suite which at that point was heavily dominated by
Fortran codes). The whole BSD UNIX Fortran was not great and I know when
Masscomp built their debugger, they started with dbx and had to gut the
multiple language support (thus rewriting much of the Fortran & Pascal
support); but the person that did it, had been part of DEC's TLG team
previously and had a direct knowledge of how the DEC debugger actually
handled multiple languages. BTW the time, I personally did not really
care, as long as C support worked.
Paul W -- do you remember if DEC TLG did a version of dbx for Ultrix
(Leslie might remember)? FWIW: I know that DEC had a number of different
debugger projects so on the UNIX side over the years, and I really don't
remember what was done for the VAX, as I was not there at the time. By
MIPS/Alpha in the mid-late 90's there was a whole new debugger stream that
had been developed at part of GEM, but there was another one that came from
MIPs too which was based on dbx.
Clem
[-- Attachment #2: Type: text/html, Size: 3751 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [TUHS] SDB debugger
2020-05-03 16:13 ` Clem Cole
@ 2020-05-03 17:13 ` Henry Bent
2020-05-03 20:26 ` Clem Cole
0 siblings, 1 reply; 8+ messages in thread
From: Henry Bent @ 2020-05-03 17:13 UTC (permalink / raw)
To: Clem Cole; +Cc: TUHS main list, Paul Ruizendaal
[-- Attachment #1: Type: text/plain, Size: 615 bytes --]
On Sun, 3 May 2020 at 12:14, Clem Cole <clemc@ccc.com> wrote:
>
> By MIPS/Alpha in the mid-late 90's there was a whole new debugger stream
> that had been developed at part of GEM, but there was another one that came
> from MIPs too which was based on dbx.
>
This raises a question I've always had - what was the relationship between
DEC's compilers on MIPS/Alpha and the work the MIPS folks did? Early
versions of OSF/1 on both platforms have tools that are very, very similar
to the MIPS compiler suite - ugen, uopt, two-pass assembler, etc. - and
I've always been curious what the heritage was there.
-Henry
[-- Attachment #2: Type: text/html, Size: 1051 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [TUHS] SDB debugger
2020-05-03 17:13 ` Henry Bent
@ 2020-05-03 20:26 ` Clem Cole
2020-05-05 0:22 ` [TUHS] DEC Compilers (was: " Win Treese
0 siblings, 1 reply; 8+ messages in thread
From: Clem Cole @ 2020-05-03 20:26 UTC (permalink / raw)
To: Henry Bent; +Cc: TUHS main list, Paul Ruizendaal
[-- Attachment #1: Type: text/plain, Size: 3838 bytes --]
On Sun, May 3, 2020 at 1:13 PM Henry Bent <henry.r.bent@gmail.com> wrote:
> This raises a question I've always had - what was the relationship between
> DEC's compilers on MIPS/Alpha and the work the MIPS folks did? Early
> versions of OSF/1 on both platforms have tools that are very, very similar
> to the MIPS compiler suite - ugen, uopt, two-pass assembler, etc. - and
> I've always been curious what the heritage was there.
>
I can answer that ;-)
You need to understand/remember that the first OS that ran on Alpha was a
port of the Ultrix/MIPS base. We debugged the hardware with Ultrix (not
VMS). The key is that DEC had full rights to all the MIPS tools. So a
quick redo of the MIPS/3000 backend was made to emit Alpha since GEM was
not really ready yet and Ultrix was way more portable than VMS was.
There was a big fight about if Ultrix/Alpha should ship or not, which as we
know never happened as Tru64 was to be the new OS base (particularly since
DC had taken Mica to Microsoft which became NT etc..). In practice, one of
the big problems was that Tru64 was OSF/1 really in name and command system
only. The Tru64 team kept rewriting large kernel subsystems under the
rules of "this code is not 64-bit clean", or "it's immature, I need to
rewrite I can't understand it", "We need better SCSI support," "the TTY
driver sucks," *etc*. ...
The idea of 'perfection' was very high on people's minds. As I have
always said, every one of those choices could be argued as the correct one
technically and in the small, but when you integrate against the whole,
Tru64 was 3 years late (and DEC had not revenue because other than a little
bit of business in system refresh, few people wanted to buy new Vaxen or
MIPS boxes -- they went to Sun). So it was actually a bad idea. They
should have shipped OSF/1-Alpha as is and then tweaked it to become Tru64
over time. Or they could have shipped the early OSF/1 for Alpha and MIPS
together as a stepping stone - the later did actually Shipp under a special
license to a few research sites but was never productive. I don't think
the former ever left the building.
Anyway back to compilers, Tru64 had a 'good enough' compiler based on the
MIPS code base to get us all going, but GEM's primary target was VMS since
one of the important features of GEM was the VAX->Alpha transpiler
technology. VMS was still heavily written in VAX Assembler at the time.
Plus, It actually was a little hairy because GEM had a new C/C++
front-end. So TLE's high order bit was VMS for the Alphas. GEM for
Tru64 was about 18 months later.
This was also a mixed blessing -- one thing was GEM caught a huge number of
64-bit-ism (God Bless Judy Ward's error detection code). Most large
ISV's were having big issues with 32-bit dirty code and in particular the
ILP32 assumption (all 64-bit UNIX's use the LP64 model). At that point,
there were absolutely no tools in the market to help people move to the new
64-bit world. So until the GEM compiler showed up, ISVs were pretty slow
in getting their code cleaned. The funny part of all that work is that DEC
basically paid the big ISVs (read Oracle et al) to make their code work on
later generations of MIP, SUN, and INTEL*64. I know of a number of ISV's
that discovered after the Tru64/Alpha port, their bug rate dropped and a
whole ton of bugs in the basic codebase had been eliminated. As an aside,
to do this day, if I am given an old piece of C or C++ that I want to run
on a modern system (like I was a couple of weeks ago to read some old
tapes), I fire up my Alpha and feed the sources to Judy'd front-end and
listen very carefully to her warnings -- if the GEM Tru64 compiler can
accept it without warnings, I have never had a case where the code did not
'just work' when I recompiled for my Mac when I brought it back.
[-- Attachment #2: Type: text/html, Size: 5279 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [TUHS] DEC Compilers (was: Re: SDB debugger
2020-05-03 20:26 ` Clem Cole
@ 2020-05-05 0:22 ` Win Treese
2020-05-05 17:36 ` Paul Winalski
2020-05-05 21:49 ` Henry Bent
0 siblings, 2 replies; 8+ messages in thread
From: Win Treese @ 2020-05-05 0:22 UTC (permalink / raw)
To: TUHS main list
> On May 3, 2020, at 4:26 PM, Clem Cole <clemc@ccc.com> wrote:
>
> Anyway back to compilers, Tru64 had a 'good enough' compiler based on the MIPS code base to get us all going, but GEM's primary target was VMS since one of the important features of GEM was the VAX->Alpha transpiler technology. VMS was still heavily written in VAX Assembler at the time. Plus, It actually was a little hairy because GEM had a new C/C++ front-end. So TLE's high order bit was VMS for the Alphas. GEM for Tru64 was about 18 months later.
In the early days of Alpha, I was at DEC’s Cambridge Research Laboratory (directed then by Vic Vyssotsky, having retired from Bell Labs). The lab had various connections to Alpha projects, and we learned that there were (I think) 7 different C compilers running on the early port of Ultrix. That number, I think, did not include the port of gcc that DEC was funding outside the company.
Andy Payne, a recent hire at the lab, had been an intern in DEC’s semiconductor group, where he had worked on randomized testing for hardware verification. With all the compilers available, he decided to hack up a program to generate random small C programs with computable expected outputs. His program then compiled the random code with each compiler and tested the result. After finding a number of bugs this way, he got tired of submitting the bug reports, and changed his program to write and submit the bug reports automatically.
This caused a little bit of consternation with some of the compiler teams at first.
Eventually, this led to some collaboration with the DEC languages and tools team, and Bill McKeeman published a paper that line of work in the Digital Technical Journal in 1998[1].
- Win
[1] https://www.hpl.hp.com/hpjournal/dtj/vol10num1/vol10num1art9.pdf
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [TUHS] DEC Compilers (was: Re: SDB debugger
2020-05-05 0:22 ` [TUHS] DEC Compilers (was: " Win Treese
@ 2020-05-05 17:36 ` Paul Winalski
2020-05-05 18:53 ` Dr Iain Maoileoin
2020-05-05 21:59 ` Dan Cross
2020-05-05 21:49 ` Henry Bent
1 sibling, 2 replies; 8+ messages in thread
From: Paul Winalski @ 2020-05-05 17:36 UTC (permalink / raw)
To: Win Treese; +Cc: TUHS main list
On 5/4/20, Win Treese <treese@acm.org> wrote:
>
> Andy Payne, a recent hire at the lab, had been an intern in DEC’s
> semiconductor group, where he had worked on randomized testing for hardware
> verification. With all the compilers available, he decided to hack up a
> program to generate random small C programs with computable expected
> outputs. His program then compiled the random code with each compiler and
> tested the result. After finding a number of bugs this way, he got tired of
> submitting the bug reports, and changed his program to write and submit the
> bug reports automatically.
>
> This caused a little bit of consternation with some of the compiler teams at
> first.
I remember that very well. IIRC it was called fuzz testing, and
indeed it was controversial, for the reasons Bill McKeeman discusses
in his paper. [1] On the one hand, compiler developers said, "nobody
would ever write something like that--we can't waste our time on these
issues when there are real bugs waiting to be fixed." On the other
hand, some of the bugs that fuzz testing turned up provoked reactions
such as, "OMG! THAT caused the compiler to crash?" I think the
turning point was when fixing one of the fuzz testing bugs also fixed
an obscure and hard-to-debug customer problem. Intel's C and Fortran
compiler team has also used random testing technology.
> [1] https://www.hpl.hp.com/hpjournal/dtj/vol10num1/vol10num1art9.pdf
-Paul W.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [TUHS] DEC Compilers (was: Re: SDB debugger
2020-05-05 17:36 ` Paul Winalski
@ 2020-05-05 18:53 ` Dr Iain Maoileoin
2020-05-05 21:59 ` Dan Cross
1 sibling, 0 replies; 8+ messages in thread
From: Dr Iain Maoileoin @ 2020-05-05 18:53 UTC (permalink / raw)
To: Paul Winalski; +Cc: TUHS main list
> On 5 May 2020, at 18:36, Paul Winalski <paul.winalski@gmail.com> wrote:
>
> On 5/4/20, Win Treese <treese@acm.org> wrote:
>>
>> ….
>> This caused a little bit of consternation with some of the compiler teams at
>> first.
>
> I remember that very well. IIRC it was called fuzz testing, and
> ….
> compiler team has also used random testing technology.
>
>> [1] https://www.hpl.hp.com/hpjournal/dtj/vol10num1/vol10num1art9.pdf
>
> -Paul W.
Way back in the deep past - late 70s I think - The Computer Science Department at Strathclyde Uni in Scotland had a contract to develop a test suite generator for the C compiler on the ICL perq computer. I think the testing/development for that compiler was happening at Dalkeith in Scotland - but dont quote me.
Like the above we generated programs (e.g. mixing short, int, long signed and unsigned and doing all sort of ops on them). The expected output was computed by the same C program running on a BSD unix vax and something else. We had a few issues with the vax and the other system disagreeing on the arithmetic results, but generally we were confident the random C programs would reasonably test the system under test. We did not get to see the results of the tests, we developed the suite and handed it over to ICL.
Overall we were not impressed by the PERQ and on a trip to Rutherford Appleton Labs (RAL) one November there was a HUGE bonfire being prepared (for our Guy Falkes(sp) celebration). The bonfire was generally comprised of the PERQ cardboard packing cases. It just looked like they were planning to burn the PERQs themselves. We agreed with the sentiment.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [TUHS] DEC Compilers (was: Re: SDB debugger
2020-05-05 17:36 ` Paul Winalski
2020-05-05 18:53 ` Dr Iain Maoileoin
@ 2020-05-05 21:59 ` Dan Cross
1 sibling, 0 replies; 8+ messages in thread
From: Dan Cross @ 2020-05-05 21:59 UTC (permalink / raw)
To: Paul Winalski; +Cc: TUHS main list
[-- Attachment #1: Type: text/plain, Size: 1902 bytes --]
On Tue, May 5, 2020 at 1:37 PM Paul Winalski <paul.winalski@gmail.com>
wrote:
> On 5/4/20, Win Treese <treese@acm.org> wrote:
> >
> > Andy Payne, a recent hire at the lab, had been an intern in DEC’s
> > semiconductor group, where he had worked on randomized testing for
> hardware
> > verification. With all the compilers available, he decided to hack up a
> > program to generate random small C programs with computable expected
> > outputs. His program then compiled the random code with each compiler and
> > tested the result. After finding a number of bugs this way, he got tired
> of
> > submitting the bug reports, and changed his program to write and submit
> the
> > bug reports automatically.
> >
> > This caused a little bit of consternation with some of the compiler
> teams at
> > first.
>
> I remember that very well. IIRC it was called fuzz testing, and
> indeed it was controversial, for the reasons Bill McKeeman discusses
> in his paper. [1] On the one hand, compiler developers said, "nobody
> would ever write something like that--we can't waste our time on these
> issues when there are real bugs waiting to be fixed." On the other
> hand, some of the bugs that fuzz testing turned up provoked reactions
> such as, "OMG! THAT caused the compiler to crash?" I think the
> turning point was when fixing one of the fuzz testing bugs also fixed
> an obscure and hard-to-debug customer problem. Intel's C and Fortran
> compiler team has also used random testing technology.
>
Ah, very cool. The same approach has come into favor again recently. I've
dealt personally with https://github.com/google/syzkaller, which is a
kernel fuzzer that generates random inputs to system calls and detects e.g.
panics. It's a neat approach.
- Dan C.
> [1] https://www.hpl.hp.com/hpjournal/dtj/vol10num1/vol10num1art9.pdf
>
> -Paul W.
>
[-- Attachment #2: Type: text/html, Size: 2716 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [TUHS] DEC Compilers (was: Re: SDB debugger
2020-05-05 0:22 ` [TUHS] DEC Compilers (was: " Win Treese
2020-05-05 17:36 ` Paul Winalski
@ 2020-05-05 21:49 ` Henry Bent
1 sibling, 0 replies; 8+ messages in thread
From: Henry Bent @ 2020-05-05 21:49 UTC (permalink / raw)
To: Win Treese; +Cc: TUHS main list
[-- Attachment #1: Type: text/plain, Size: 2164 bytes --]
On Mon, 4 May 2020 at 20:33, Win Treese <treese@acm.org> wrote:
>
> > On May 3, 2020, at 4:26 PM, Clem Cole <clemc@ccc.com> wrote:
> >
> > Anyway back to compilers, Tru64 had a 'good enough' compiler based on
> the MIPS code base to get us all going, but GEM's primary target was VMS
> since one of the important features of GEM was the VAX->Alpha transpiler
> technology. VMS was still heavily written in VAX Assembler at the time.
> Plus, It actually was a little hairy because GEM had a new C/C++
> front-end. So TLE's high order bit was VMS for the Alphas. GEM for
> Tru64 was about 18 months later.
>
> In the early days of Alpha, I was at DEC’s Cambridge Research Laboratory
> (directed then by Vic Vyssotsky, having retired from Bell Labs). The lab
> had various connections to Alpha projects, and we learned that there were
> (I think) 7 different C compilers running on the early port of Ultrix. That
> number, I think, did not include the port of gcc that DEC was funding
> outside the company.
>
> Andy Payne, a recent hire at the lab, had been an intern in DEC’s
> semiconductor group, where he had worked on randomized testing for hardware
> verification. With all the compilers available, he decided to hack up a
> program to generate random small C programs with computable expected
> outputs. His program then compiled the random code with each compiler and
> tested the result. After finding a number of bugs this way, he got tired of
> submitting the bug reports, and changed his program to write and submit the
> bug reports automatically.
>
> This caused a little bit of consternation with some of the compiler teams
> at first.
>
> Eventually, this led to some collaboration with the DEC languages and
> tools team, and Bill McKeeman published a paper that line of work in the
> Digital Technical Journal in 1998[1].
>
> - Win
>
> [1] https://www.hpl.hp.com/hpjournal/dtj/vol10num1/vol10num1art9.pdf
Does this software still exist anywhere? The link to the download is long
gone, archive.org did not preserve the download, and I had no success
finding the files on the web.
-Henry
[-- Attachment #2: Type: text/html, Size: 2685 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-05-06 20:27 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-06 2:52 [TUHS] DEC Compilers (was: Re: SDB debugger Doug McIlroy
-- strict thread matches above, loose matches on Subject: below --
2020-05-06 15:53 Doug McIlroy
2020-05-06 20:21 ` Tim Rylance
2020-05-01 20:48 [TUHS] " Paul Ruizendaal
2020-05-02 0:49 ` Noel Hunt
2020-05-02 20:16 ` Paul Ruizendaal
2020-05-03 16:13 ` Clem Cole
2020-05-03 17:13 ` Henry Bent
2020-05-03 20:26 ` Clem Cole
2020-05-05 0:22 ` [TUHS] DEC Compilers (was: " Win Treese
2020-05-05 17:36 ` Paul Winalski
2020-05-05 18:53 ` Dr Iain Maoileoin
2020-05-05 21:59 ` Dan Cross
2020-05-05 21:49 ` Henry Bent
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).