Re: [Simh] PDP-11 MARK

[Leo Broukhis]

It would have been nice of you, Dave Porter, to include a link to the
source of inspiration for your question:

https://retrocomputing.stackexchange.com/q/7056/4025

Leo

On Wed, Aug 1, 2018 at 5:26 PM, dave porter 
wrote:

> Not really a simh question, but this might be an appropriate
> bunch of people.  What actually used MARK on PDP-11?
>
> I think I recall that some Fortran system (F4P?) used it,
> but that's a vague feeling at most.
>
> Certainly as a Macro-11 kernel-mode weenie, I never
> felt the need.
>
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Fwd: [TUHS] An abandoned piece of K C

[Leo Broukhis]

On the StackExchange page https://retrocomputing.stackex
change.com/q/4965/4025

I got a comment: Re: the Ken Thompson addition and, therefore, the idea of
asking the people that were actually there; Kernighan remains an employee
of Google and can sometimes be spotted at the NYC office. Sadly I recently
left but if anybody else here is a Googler then the usual internal means
might allow a query to be put if appropriate respect is applied. I attended
a presentation he gave while I was there and he seems like a very
approachable fellow.

Can anyone contact Mr. Kernighan?

Thanks,
Leo

On Fri, Nov 3, 2017 at 1:42 PM, Leo Broukhis <l...@mailcom.com> wrote:

> Well, somebody had to have done it!
>
>
> On Fri, Nov 3, 2017 at 1:22 PM, Larry Stewart <l.s...@stewart.org> wrote:
>
>> I took the liberty of cross posting this earlier to TUHS and I got
>> an authoritative answer :)
>> -Larry
>>
>>
>> Begin forwarded message:
>>
>> *From: *Ken Thompson <k...@google.com>
>> *Subject: **Re: [TUHS] Fwd: [Simh] An abandoned piece of K C*
>> *Date: *2017, November 3 at 2:30:08 PM EDT
>> *To: *Lawrence Stewart <stew...@serissa.com>
>>
>> it's news to me.
>>
>>
>>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Fwd: [TUHS] An abandoned piece of K C

[Leo Broukhis]

Well, somebody had to have done it!


On Fri, Nov 3, 2017 at 1:22 PM, Larry Stewart <l.s...@stewart.org> wrote:

> I took the liberty of cross posting this earlier to TUHS and I got
> an authoritative answer :)
> -Larry
>
>
> Begin forwarded message:
>
> *From: *Ken Thompson <k...@google.com>
> *Subject: **Re: [TUHS] Fwd: [Simh] An abandoned piece of K C*
> *Date: *2017, November 3 at 2:30:08 PM EDT
> *To: *Lawrence Stewart <stew...@serissa.com>
>
> it's news to me.
>
>
> On Fri, Nov 3, 2017 at 5:53 AM, Lawrence Stewart <stew...@serissa.com>
> wrote:
>
> This caught my attention.  Did early C really have min and max?  Were they
> used for anything?  In those days I was a BCPL user, which IIRC, did not
> have such things.
>
> -Larry
>
> Begin forwarded message:
>
> From: Leo Broukhis <l...@mailcom.com>
> Subject: [Simh] An abandoned piece of K C
> Date: 2017, November 3 at 1:14:42 AM EDT
> To: "simh@trailing-edge.com" <simh@trailing-edge.com>
>
> https://retrocomputing.stackexchange.com/q/4965/4025
>
>
> In the UNIX V7 version of the C language, there were the /\ (min) and the
> \/
> (max) operators. In the source of the scanner part of the compiler,
>
> case BSLASH:
>if (subseq('/', 0, 1))
>return(MAX);
>goto unkn;
>
> case DIVIDE:
>if (subseq('\\', 0, 1))
>return(MIN);
> ...
>
> However, attempting to use them reveals that the corresponding part in the
> code generator is missing. Trying to compile
>
> foo(a, b) { return a \/ b; }
>
> results in
>
> 1: No code table for op: \/
>
> The scanner piece survived in the copies of the compiler for various
> systems
> for several years. I tried to look for copies of the code generator table
> which would contain an implementation, but failed. Has anyone ever seen a
> working MIN/MAX operator in K C?
>
> Thanks,Leo
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>
>
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An abandoned piece of K C

[Leo Broukhis]

Bob,

The symbols may stem from BCPL, but the idea to use them for MIN and MAX is
specific to V7.

In V6, http://www.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/c/c00.c
doesn't have them.

Leo

On Fri, Nov 3, 2017 at 3:33 AM, Bob Eager <r...@tavi.co.uk> wrote:

> On Thu, 2 Nov 2017 22:14:42 -0700
> Leo Broukhis <l...@mailcom.com> wrote:
>
> > https://retrocomputing.stackexchange.com/q/4965/4025
> >
> >
> > In the UNIX V7 version of the C language, there were the /\ (min) and
> > the \/ (max) operators.
>
> As an aside, many will know that C is based on B, and B was based on
> BCPL.
>
> I used BCPL a *lot*. The logical AND operator in BCPL could be written
> as:
>
>   AND
>   &
>   /\
>
> and logical OR could be written as:
>
>   LOGOR
>   |
>   \/
>
> Perhaps someone decided it would be confusing.
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An abandoned piece of K C

[Leo Broukhis]

Will,

Please don't hesitate to ask on the TUHS mailing list.

Thanks,
Leo

On Fri, Nov 3, 2017 at 2:56 AM, Will Senn <will.s...@gmail.com> wrote:

> On 11/3/17 12:14 AM, Leo Broukhis wrote:
>
> https://retrocomputing.stackexchange.com/q/4965/4025
>
>
> In the UNIX V7 version of the C language, there were the /\ (min) and the
> \/ (max) operators. In the source of the scanner part of the compiler,
> snip
>
>
> Leo,
>
> This is a great question for the TUHS mailing list as well as SIMH, I know
> a lot of those folks are here as well, but you might think about
> cross-posting, or if you aren't on the list, I'd be happy to pass it along.
>
> On the source code side of things, in case you haven't seen it, Diomidis
> Spinellis pieced together the most comprehensive Unix repo I've seen (44
> years of code with comments):
> https://github.com/dspinellis/unix-history-repo
>
> and his write up about it can be found here:
> https://www2.dmst.aueb.gr/dds/pubs/conf/2015-MSR-Unix-
> History/html/Spi15c.html
>
> Later,
>
> Will
>
> GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] An abandoned piece of K C

[Leo Broukhis]

https://retrocomputing.stackexchange.com/q/4965/4025


In the UNIX V7 version of the C language, there were the /\ (min) and the
\/ (max) operators. In the source of the scanner part of the compiler,

case BSLASH:
if (subseq('/', 0, 1))
return(MAX);
goto unkn;

case DIVIDE:
if (subseq('\\', 0, 1))
return(MIN);
...

However, attempting to use them reveals that the corresponding part in the
code generator is missing. Trying to compile

foo(a, b) { return a \/ b; }

results in

1: No code table for op: \/

The scanner piece survived in the copies of the compiler for various
systems for several years. I tried to look for copies of the code generator
table which would contain an implementation, but failed. Has anyone ever
seen a working MIN/MAX operator in K C?

Thanks,Leo
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An obscure dialect of Pascal: MULTICS roots?

[Leo Broukhis]

Hello Adam,

Thank you for the references! May I copy your answer to my SE post, or
would you like to answer there as well under your name?

I have a binary of a game (Mankala) written in that dialect of Pascal; I
might get to decompiling it to see if the branch operator was used.

Thank you,
Leo

On Aug 26, 2017 15:30, "Adam Sampson" <a...@offog.org> wrote:

Leo Broukhis <l...@mailcom.com> writes:

> I'm specifically interested in the branch/back feature. What
> theoretical paper does it come from?

I think it's fairly likely that the designers of your 1979 dialect of
Pascal were thinking of this as a feature to support (what was then
called) "backtrack programming" for AI-like applications, rather than as
an exception handling mechanism...

There were several programming languages experimenting with approaches
to backtracking in the mid-late 70s, Prolog probably being the
best-known result ("branch" is equivalent to a Prolog predicate with
multiple rules, where failure inside one rule causes control flow to
backtrack to the next rule). Your branch/back construct would be pretty
handy if you were trying to write a tree search algorithm with pruning
(e.g. a classic board game AI), or a backtracking parser.

Here's a 1974 survey which sketches the backtracking idea (p157) and
describes some early implementations:
http://dl.acm.org/citation.cfm?id=356632

This 1977 paper gives a denotational semantics for backtracking, and is
fairly widely cited by later work:
https://link.springer.com/article/10.1007/BF00289245

(Note in particular that it calls its equivalent of "branch" the
"alternative" operator -- which might explain your "exit on ALT"
message?)

This 1979 paper takes the idea and generalises it to work with
coroutines (using Pascal for examples, although with different syntax):
http://dl.acm.org/citation.cfm?id=357062.357063

Thanks,

--
Adam Sampson <a...@offog.org> <http://offog.org/>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] An obscure dialect of Pascal: MULTICS roots?

[Leo Broukhis]

While exploring implementations of Pascal on BESM-6, I've encountered two
peculiar language extensions about which I've asked on SE:

BRANCH/BACK: an analog of try/catch:
https://retrocomputing.stackexchange.com/q/3150/4025

Structural labels as a way to implement generalized break/continue:
https://retrocomputing.stackexchange.com/q/3296/4025

Both posts are quite verbose so I'm not quoting them here.

Regarding the first feature, I was told in a private conversation that the
message "exit on ALT" for an uncaught "exception" - the equivalent of C++
terminate() - might have its roots in MULTICS.

Does any of the above ring any bells? I'm specifically interested in the
branch/back feature. What theoretical paper does it come from?

Thanks,
Leo
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] 8" Floppy disk image getting HALT error

[Leo Broukhis]

I think that the proper image size should be 256256, as 6656 is exactly
256x26, w which is a multiple of 13, as well as 256256.

On floppy disks with 77 tracks of 26 128-byte sectors each, or 13 256-byte
sectors, track 0 could be treated as the last one when the media was
accessed at the application level (probably because it tended to be less
reliable due to the heads spending more time there).

Moreover, as the media size is not a multiple of 512, reading the last one
or two sectors may be problematic in some systems if the system block size
is 512. This hindered my recovering of the Terak boot disk for several
years.


Leo


On Jul 11, 2017 10:26 AM, "Walker Sampson" 
wrote:

Hi everyone,

Many thanks for this feedback. A fair amount to chew on here. I’ve sent a
request to the donor to share the disk image, if I get a positive I’ll be
happy to throw up a Dropbox link to it for others to examine.

This may mean a problematic read of the disk itself, but addresses 0 –
019D0 are all zeroed out, or about bytes 0 – 6655.

Data begins at byte 6657, and that is the document I mentioned. Last byte
of the document is 73080 and then just blocks of either zero or E5E5E5E5
till the end of the disk.

To Paul’s point of mounting a RK05 drive – which drive should I be mounting
here, assuming it is the RX02 disk it seems to be? “AT RX01 ”
still gets a HALT error. Of course, as you all point out, perhaps this
isn’t a bootable disk, period. “SH RX01” gives “RX1, 256KB, attached to
test-decrx01.img, write enabled”

FYI as well, on a modern HFS+ system, the disk image file is coming in at
256 KB.

Any thoughts on the run of zeroes and E5E5E5E5?

Thanks again,

Walker

 On 7/11/17, 6:29 AM, "Simh on behalf of Johnny Billquist" <
simh-boun...@trailing-edge.com on behalf of b...@softjar.se> wrote:

Hi.

On 2017-07-10 22:10, Walker Sampson wrote:
> Hi everyone,
>
> Let me preface this by saying that I’m unfamiliar with the original
PDP
> machines. I work as a digital archivist and have received 8” floppy
> disks from which I need to recover data.
>
> I believe I have recovered at least partial data from these disks;
I’ve
> connected a Y-E Data 8” floppy drive to a KryoFlux floppy disk
> controller and gotten positive sector results setting the format to a
> DEC RX02 sector image. When I investigate the resulting disk image in
a
> hex editor, I am seeing clearly a report document, so I don’t believe
I
> have a false positive.
>
> Outside of observing in a hex editor however, I don’t know how to
access
> the disk or its contents. Using SIMH, I haven’t gotten the virtual
> machine to boot the floppy disk image.
>
> Commands “AT RK01 ” and then “BOOT RK01” give me a “HALT
> instruction, PC: 02 (HALT)” message for the PDP-11 program. The
> PDP-8 stalls indefinitely and the PDP-10 outputs “Non-existent device”
> as well.
>
> I can’t go back to the donors and ask what machines these 8” floppies
> were used with, so I’m not sure how to begin troubleshooting.
>
> Any advice in that area is much appreciated!
>
> Thanks,
>
>
> Walker

To sum things up. You can probably ignore all the questions about if
this really is some DEC floppy, what kind of format it has, and so on.
If kryoflux managed to extract data that looks valid with RX02 parameter
settings, then I'd say we can be sure it is an RX02 disk. And this
format was unique to DEC, so it can't be anything else.

Which also means, you already have managed to exact all the bits, and
most probably correct. The next question is just about restoring the
data in a more coherent form, which means getting it in the form of
files, and understanding the format of the files.

For this, we need to know what system the floppy was written on. Paul
Koning gave the most useful advice. The first few blocks will usually be
enough to find out what system the floppy was written on.

RX02 floppies could certainly be bootable, but most are not. OS/8 (and
derivatives) for the PDP-8, and RT-11 for the PDP-11 were the ones that
supported RX02 as a bootable system. Other systems supported the
floppes, but only as a way of carrying bits around, so not being able to
boot from the floppy is probably to be expected.

So, if you could give us just the first few blocks, it should be
possible to tell what file system it has, and that gives us OS, file
structure and probably the ability to work out the rest in quick order.

Johnny

--
Johnny Billquist  || "I'm on a bus
   ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
   

[Simh] The SIMH project is on Coverity Scan

[Leo Broukhis]

Please visit https://scan.coverity.com/projects/simh

If you have a GitHub account and have contributed a commit, you can add
yourself to the project to view the defects after logging in with your
GitHub ID.

Leo
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] Is the CDC 1700 FORTRAN compiler available?

[Leo Broukhis]

In the very first BESM-6 FORTRAN compiler -- the one derived from the CDC
1604 FORTRAN compiler by manually retargeting the assembly language source
-- there is a peculiar bug: the line
IF (X=Y) stmt
which should be rejected as syntactically incorrect (and is rejected by
another, independently written compiler), does compile, and the resulting
code is like
X=Y
IF(0.NE.0) stmt

I'd like to check if the bug was there in the CDC compiler, or was
introduced in the process of retargeting. As there is no CDC 1604 emulator
in SIMH, CDC 1700 is the closest thing available (I know that their
architectures are different; it's still worth checking in case the CDC 1700
compiler uses the same parsing algorithm).

Does anyone have the knowledge how to run FORTRAN on the CDC 1700 emulator?

Thanks,
Leo
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] State of the 940

[Leo Broukhis]

Cool! I've been avoiding implementing the tape driver for BESM-6 because it
had formatted tapes and in-place overwrite of individual records. I'll be
able to do it soon, then!

Thanks,
Leo

On Mon, 24 Oct 2016 12:24:25 -0400, Bob Supnik  wrote:

> Mark,
>
> Dave Bryan and I are trying to work out the kinks in the 'erase'
> function on the 940, which is needed to make the tape file system work.
> Dave has implemented precise in-place erase for records, but we'll need
> a precise erase for file marks too. And then the whole thing has to be
> tested.
>
> I'll keep you posted on progress.
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] Fwd: Simh Digest, Vol 153, Issue 26

[Leo Broukhis]

Thank you, Nelson!

 It appears that, indeed, apart from theoretical research, there was not
much actual work attempting to perfect the accuracy of the conversions
until the 1990s.
Then I don't have to feel ashamed on behalf of the Soviet applied
mathematicians that they didn't do a job good enough by today's standards
in the mid-1970s.
That's a relief.

Regards,
Leo


On Mon, 17 Oct 2016 18:42:19 -0600, "Nelson H. F. Beebe" <
be...@math.utah.edu> wrote:

>
> The discussions on this thread began with a question about the
> accuracy of binary->decimal->binary conversions.  The key original
> references are recorded in
>
> http://www.math.utah.edu/pub/tex/bib/fparith.bib
> http://www.math.utah.edu/pub/tex/bib/fparith.html
>
> in entries Goldberg:1967:BED, Matula:1968:BCT, and Matula:1968:C.
> Those papers showed how many digits were needed for correct round-trip
> conversions, but did not exhibit code to do so.
>
> Some later papers had real source code, including Steele:1990:HPF,
> Clinger:1990:HRF, Clinger:2004:RHR, Burger:1996:PFP, Knuth:1990:SPW,
> and Abbott:1999:ASS.  The 20-year retrospectives in Clinger:2004:RHR
> and Steele:2004:RHP sum up that earlier work, and may be the best
> starting point to understand the problem.
>
> It is decidedly nontrivial: the Abbott paper in the section
> ``Difficult numbers'' starting on page 739 discusses hard cases [where
> the exact result in the output base is almost exactly halfway between
> two machine numbers], and on page 740, they write ``The decimal size
> may be unbounded, because there is a natural bound derived from the
> exponent range, as was mentioned earlier. This bound is 126 digits for
> single, 752 for double, and 11503 for extended precision.''
>
> Entry Knuth:1990:SPW has the provocative title ``A Simple Program
> Whose Proof Isn't'': it examines the conversions between fixed-binary
> and decimal needed in the TeX typesetting system, a much simpler
> problem whose proof eluded Knuth for several years until this paper.
> A companion paper Gries:1990:BDO supplies an alternative proof of
> Knuth's algorithm.
>
> As to the first actual system to provide correct round-trip
> conversions, the Abbott paper on the IBM mainframe (S/360 to zSeries
> machines) describes the pressure to get it right the first time,
> because of the longevity of that architecture, and the high cost of
> repairing hardware implementations.
>
> The 1990 Steele and Clinger references above supply software
> implementations in Common Lisp exploiting the multiple-precision
> arithmetic supported in that language.
>
> Some current compilers, such as releases of gcc for the last several
> years, use the GMP and MPFR multiple-precision arithmetic packages to
> supply correct compile-time conversions.  Presumably, the revision
> history of GNU glibc would reveal when similar actions were taken for
> the strtod(), printf(), and scanf() families of the C and C++
> programming languages. I have not personally investigated that point,
> but perhaps other list members have, and can report their findings.
>
> >From scans of executables of assorted gcc versions, it appears that
> GMP and MPFR came into use in gcc-family compilers about mid-2007.
> The oldest gcc snapshot (of hundreds that I have installed) that
> references both those libraries is gcc-4.3-20070720.  However, the
> ChangeLog file in that release has mention on MPFR from 18-Nov-2006,
> and an entry of 11-Jan-2007 that says "Add gmp and mpfr".
>
> David M. Gay (then at AT Bell Labs renamed as Lucent Technologies)
> released an accurate implementation of strtod() marked "Copyright (C)
> 1998-2001 by Lucent Technologies".  The oldest filedate in my personal
> archives of versions of that software is 22-Jun-1998, with changes up
> to 29-Nov-2007.
>
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Looking for a milestone

[Leo Broukhis]

On Mon, 17 Oct 2016 15:29:10 -0600, Kevin Handy 
wrote:

How close are the simh emulators to the real hardware's floating point? How
> exct is the emulation of FPU's?
> Does simh emulate the real hardware close enough that you can use it to
> analyze the original hardware floating point processors? (For those that
> actually had FPUs instead of doing it in software).
> Or does it do it using "modern" methods (IEEE style FPUs) that could
> calculate different results than the original hardware did?
>

I can tell that the engineering ALU test passes in the BESM-6 emulator.

Addition and multiplication produce 80 bit of mantissa and had to be
emulated with integers; division produces 40 bit, but using IEEE double and
truncating or rounding the result causes the test to fail; I had to
implement the non-restoring division algorithm exactly as described in the
docs to make it work.

It;s probably not a big deal for most users, but if the simh FPU hardware
>  might operate any different;y than the real hardware it should at least be
> documented somewhere.
>

If other machines emulated by SIMH use IEEE for speed, it would be
interesting to run their engineering tests, if available, to see if there
are any failures.

Leo
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Looking for a milestone

[Leo Broukhis]

Dijkstra is above reproach; I try to compare the averages.

Having eps^2 = eps is cute, but, given that the idea didn't spread to other
pre-IEEE f.p. implementations nor to IEEE (it is possible to iteratively
square a number x with 0 < abs(x) < 1 down to 0, given enough iterations,
denormals or not), it appears that the Electrologica floating point turned
out to be impractical.



On Mon, Oct 17, 2016 at 11:35 AM, Paul Koning <paulkon...@comcast.net>
wrote:

>
> > On Oct 17, 2016, at 2:26 PM, Leo Broukhis <l...@mailcom.com> wrote:
> >
> > > I think that the same answer applies to your narrower question, though
> I didn't see it mentioned specifically in the documents I've read.
> >
> > That's somewhat comforting; I'd hate to think that the BESM-6
> programmers were substantially sloppier than their Western colleagues. :)
>
> As you probably know, Dijkstra was a whole lot more disciplined than the
> vast majority of his colleagues.
>
> > > For example, the treatment of underflow and very small numbers in
> Electrologica was novel at the time; Knuth specifically refers to it in a
> > > footnote of Volume 2.  The EL-X8 would never turn a non-zero result
> into zero, for example.
> >
> > For most but not all values of "never", I presume. What was the result
> of squaring the number with the least representable absolute value?
>
> The least representable positive value.  See the paper by F. E. J.
> Kruseman Aretz that I mentioned.
>
> >
> > > I think IEEE ended up doing the same thing, but  that was almost 20
> years later.
> >
> > Are you're thinking about denormals?
>
> I think so, but I'll be the first to admit that I don't really know
> floating point.
>
> paul
>
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Looking for a milestone

[Leo Broukhis]

Paul,

My question is more narrow. It focuses specifically on the binary<->decimal
transformation. It appears that while the f.p. instructions and the
elementary functions were proved correct to the appropriate precision,
there was not much care taken to ensure, for example, that "FLOAT_MAX",
"FLOAT_MIN" and "FLOAT_EPS" can be converted in both directions without
exceptions and loss of precision, etc. It appears to me that people started
caring about these things in the late 80s at the earliest. I'd like to be
wrong.

Thanks,
Leo

On Mon, Oct 17, 2016 at 8:55 AM, Paul Koning <paulkon...@comcast.net> wrote:

>
> On Oct 14, 2016, at 7:22 PM, Leo Broukhis <l...@mailcom.com> wrote:
>
> I wonder what is the historically first programming environment with
> native binary floating point which had been proved/demonstrated to handle
> f.p. binary<->decimal I/O conversions 100% correctly?
> By 100% correctly I mean that all valid binary representations of floating
> point numbers could be, given a format with enough significant digits,
> converted to unique text strings, and these strings could be converted back
> to the corresponding unique binary representations.
>
> Of course, there is enquire.c which facilitated finding bugs in the
> Unix/Posix environments, but has anyone cared about this during the
> mainframe era?
>
>
> I believe so, yes.  For the design of the floating point feature of the
> Electrologica X8 (early 1960s) the design documents discuss correctness,
> including what the definition of "correct" should be.
>
> There is a very nice and very detailed correctness proof of that floating
> point design, documented in http://repository.tue.nl/674735 .  That paper
> was written long after the fact, but by one of the people originally
> involved in that machine.
>
> Apart from proofs of the correctness of each of the floating point
> instructions, that paper also describes the sqrt library function.
> Interestingly enough, the implementation of that function does not use
> floating point operations.  But the analysis, in appendix B of the paper,
> clearly shows the error terms of the approximation used and why the number
> of steps used is sufficient for correctness of the sqrt implementation.
>
> For a different machine, the CDC 6000 series, I remember reading
> complaints about its bizarre rounding behavior (rounding at 1/3 ?).  I
> forgot where that appeared; possibly a paper by prof. Niklaus Wirth of ETH
> Zürich.
>
> paul
>
>
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] Looking for a milestone

[Leo Broukhis]

I wonder what is the historically first programming environment with native
binary floating point which had been proved/demonstrated to handle f.p.
binary<->decimal I/O conversions 100% correctly?
By 100% correctly I mean that all valid binary representations of floating
point numbers could be, given a format with enough significant digits,
converted to unique text strings, and these strings could be converted back
to the corresponding unique binary representations.

Of course, there is enquire.c which facilitated finding bugs in the
Unix/Posix environments, but has anyone cared about this during the
mainframe era?

(I've been playing with the BESM-6 floating point conversions, and the
results are shameful.)

Thanks,
Leo
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Ferranti Pegasus Simulator

[Leo Broukhis]

Or, here is an implementation of 128-bit division:

Unsigned: https://llvm.org/svn/llvm-project/compiler-rt/trunk/lib/builtins/
*udivmodti4*.c
Signed: https://llvm.org/svn/llvm-project/compiler-rt/trunk/lib/builtins/
*divti3*.c
https://llvm.org/svn/llvm-project/compiler-rt/trunk/lib/builtins/*modti3*.c

Leo

On Fri, Jun 10, 2016 at 5:22 PM, Leo Broukhis <l...@mailcom.com> wrote:

> As a first step, you can try using https://gmplib.org/
>
> Leo
>
>
> On Sat, 11 Jun 2016 00:46:02 +0100, "Dave Wade" <dave.g4...@gmail.com>
> wrote:
>
>
>> Whilst its not a SIMH simulator, I hope you can help. I want to write an
>> emulator for the Pegasus. The Ferranti Pegasus was (there are none
>> operating
>> at present) a strange beast with two 18-bit instructions per 39-bit word.
>> Generally, it does 39-bit twos complement arithmetic. The multiply results
>> in a 77-bit result which I have no problems implementing.
>>
>> Where I am struggling is with the divide. I need to be able to divide a
>> 77-bit number by a 39-bit number and get a 39 bit quotient and a 39 bit
>> remainder. As the compiler I am using only does 64-bit numbers this is
>> proving challenging. Any one got a good article on how to do this?
>>
>> Dave Wade
>> G4UGM
>>
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Ferranti Pegasus Simulator

[Leo Broukhis]

As a first step, you can try using https://gmplib.org/

Leo


On Sat, 11 Jun 2016 00:46:02 +0100, "Dave Wade" 
wrote:


> Whilst its not a SIMH simulator, I hope you can help. I want to write an
> emulator for the Pegasus. The Ferranti Pegasus was (there are none
> operating
> at present) a strange beast with two 18-bit instructions per 39-bit word.
> Generally, it does 39-bit twos complement arithmetic. The multiply results
> in a 77-bit result which I have no problems implementing.
>
> Where I am struggling is with the divide. I need to be able to divide a
> 77-bit number by a 39-bit number and get a 39 bit quotient and a 39 bit
> remainder. As the compiler I am using only does 64-bit numbers this is
> proving challenging. Any one got a good article on how to do this?
>
> Dave Wade
> G4UGM
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simh Digest, Vol 138, Issue 37

[Leo Broukhis]

On Fri, 17 Jul 2015 11:18:34 +0200, Hans-Ulrich Hölscher
hoelscher-kirchb...@freenet.de wrote:

 That sounds like the really easy way to do it.   Does it copy track 0 of 
 RX01/02 floppies?  I had some experience with RX01/02 floppies when 
 reviving LSX using logical copies of the disks. Track 0 will be logically 
 at the very  end. The problem is with media size 256256: if the logical 
 block size is 512,  two physical 128-byte sectors (the boot sectors) will 
 be lost, and the logical copy will be 256000 bytes long.  Leo

 I must admit I used my VMS MOUNT/FOR  COPY method only with RX50 floppies 
 and RD and RZ disks.
 Leo, what method did you use?
 I was quite sure my method catches ALL sectors ...

On some Unix V6, od /dev/rx0 or similar was used, and the serial
console output was intercepted.
Disk devices are block devices (raw access to block devices not yet
invented, so no /dev/rrx0 :( ), and the block size is 512, thus only
256000 bytes were returned.

Leo
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DEC floppy disk interleave questions

[Leo Broukhis]

On Thu, 16 Jul 2015 07:53:44 -0700,  Alan Frisbie
fris...@flying-disk.com wrote:

 On 07/16/2015 05:40 AM, Hans-Ulrich Hölscher wrote:

   if you want to image your disks and floppies for use with simh,
   there's an easy way to do it.  All you need is a (Micro-)VAX
   having the appropriate drive(s) running VMS.
   MOUNT/FOREIGN device-name
   COPY/LOG device-name yourimagename.img
   DISMOUNT device-name
   Don't worry about the error message at the end of the COPY process
   - that's normal, just that copy discovers the end of media.
   You get an image containing all the blocks of your device in
   logical order - VMS will take care of the device details.

 That sounds like the really easy way to do it.   Does it copy
 track 0 of RX01/02 floppies?

I had some experience with RX01/02 floppies when reviving LSX using
logical copies of the disks. Track 0 will be logically at the very
end. The problem is with media size 256256: if the logical block size
is 512,  two physical 128-byte sectors (the boot sectors) will be
lost, and the logical copy will be 256000 bytes long.

Leo
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] A terminology question

[Leo Broukhis]

In this case the value is calculated from the other bits:
parity({upper half-word, parity bit 1}) = 0, parity({lower half-word,
parity bit 2}) = 1 indicates an instruction word

parity({upper half-word, parity bit 1}) = 1, parity({lower half-word,
parity bit 2}) = 0 indicates a data word

Leo

On Wed, Feb 11, 2015 at 10:48 AM, Phil Budne p...@ultimate.com wrote:

 Leo wrote:
  Parity makes the most sense. I was wondering if there is already a more
  specific term for such a scheme.

 To me, parity implies value calculated from the other bits.
 tag or attribute bits ring better in my ears.  If the tag bits
 can't be tweaked by user code, the term capability might be a
 choice.

 Phil

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] A terminology question

[Leo Broukhis]

Dear colleagues,

There is an implementation detail in the BESM-6 architecture the name of
which we've struggled to translate adequately.  There is a feature
preventing execution of arbitrary data as instructions implemented using
two parity bits per word, for the upper and the lower half-word. The
overall parity must be odd, and one of the valid parity bit configurations
denotes an instruction, and the other denotes data. In the original
documentation this mechanism was called
https://translate.google.com/#ru/en/%D1%81%D0%B2%D0%B5%D1%80%D1%82%D0%BA%D0%B0
(the two forms were called literally command convolution and number
convolution).

Unlike a tagged architecture, there isn't a fixed tag value to indicate
instructions or data.

Is there a standard term for this? Convolution sounds too mathematical.

Thanks,
Leo
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] Adding a BESM-6 simulator to the distribution?

[Leo Broukhis]

What would be the prerequisites for adding a BESM-6 simulator (namely,
http://sourceforge.net/projects/besm6/) to the official SIMH distribution,
to the beta kit, or for linking to it from the SIMH web page?

Thanks,
Leo
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An idea for graphics support in SIMH

[Leo Broukhis]

A great showcase for graphics support using VNC could be Terak
(http://en.wikipedia.org/wiki/Terak_8510/a) that had a smart frame
buffer with downloadable fonts, hardware-assisted scrolling, and
text/graphics overlay.

Leo
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh