Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.folklore.computers > #158899 > unrolled thread
| Started by | philo <philo@privacy.net> |
|---|---|
| First post | 2016-02-05 11:25 -0600 |
| Last post | 2016-02-13 11:33 +0000 |
| Articles | 20 on this page of 190 — 34 participants |
Back to article view | Back to alt.folklore.computers
Qbasic philo <philo@privacy.net> - 2016-02-05 11:25 -0600
Re: Qbasic Gene Wirchenko <genew@telus.net> - 2016-02-05 14:56 -0800
Re: Qbasic philo <philo@privacy.net> - 2016-02-05 18:13 -0600
Re: Qbasic Michael Black <et472@ncf.ca> - 2016-02-05 22:40 -0500
Re: Qbasic philo <philo@privacy.net> - 2016-02-05 22:32 -0600
Re: Qbasic "Gene Buckle" <gene.buckle@bbs.retroarchive.org.remove-3hg-this> - 2016-02-11 10:22 -0800
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-11 17:16 -0800
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-11 18:49 -0800
Re: Qbasic philo <philo@privacy.net> - 2016-02-12 05:25 -0600
Re: Qbasic "gareth" <no.spam@thank.you.invalid> - 2016-02-12 11:50 +0000
Re: Qbasic scott@slp53.sl.home (Scott Lurndal) - 2016-02-12 14:02 +0000
Re: Qbasic "gareth" <no.spam@thank.you.invalid> - 2016-02-12 23:24 +0000
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-12 09:50 -0800
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-12 06:53 -0500
Re: Qbasic jmfbahciv <See.above@aol.com> - 2016-02-12 13:40 +0000
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-12 09:53 -0800
Re: Qbasic jmfbahciv <See.above@aol.com> - 2016-02-13 14:37 +0000
Re: Qbasic scott@slp53.sl.home (Scott Lurndal) - 2016-02-12 14:04 +0000
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-12 09:55 -0800
Re: Qbasic Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-12 20:49 +0000
Re: Qbasic Bob Eager <news0006@eager.cx> - 2016-02-12 23:21 +0000
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-12 15:55 -0800
Re: Qbasic Bob Eager <news0006@eager.cx> - 2016-02-13 00:26 +0000
Re: Qbasic scott@slp53.sl.home (Scott Lurndal) - 2016-02-16 15:55 +0000
Re: Qbasic scott@slp53.sl.home (Scott Lurndal) - 2016-02-12 21:09 +0000
Re: Qbasic Stephen Sprunk <stephen@sprunk.org> - 2016-02-12 17:11 -0600
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-12 23:27 -0800
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-13 06:26 -0500
Re: Qbasic scott@slp53.sl.home (Scott Lurndal) - 2016-02-16 15:54 +0000
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-17 11:34 -0800
Re: Qbasic scott@slp53.sl.home (Scott Lurndal) - 2016-02-17 19:56 +0000
Re: Qbasic Anne & Lynn Wheeler <lynn@garlic.com> - 2016-02-17 12:48 -0800
Re: Qbasic Stephen Sprunk <stephen@sprunk.org> - 2016-02-17 18:52 -0600
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-17 19:23 -0800
Re: Qbasic "Charles Richmond" <numerist@aquaporin4.com> - 2016-02-18 12:00 -0600
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-18 15:02 -0800
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-18 20:36 -0500
Re: Qbasic Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-19 04:14 +0000
Re: Qbasic "Charles Richmond" <numerist@aquaporin4.com> - 2016-02-19 20:05 -0600
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-19 21:34 -0500
Re: Qbasic "Osmium" <r124c4u102@comcast.net> - 2016-02-20 08:03 -0600
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-20 11:09 -0500
Re: Qbasic JimP <solosam90@gmail.com> - 2016-02-20 10:39 -0600
Re: Qbasic "Osmium" <r124c4u102@comcast.net> - 2016-02-20 12:05 -0600
Re: Qbasic Dave Garland <dave.garland@wizinfo.com> - 2016-02-20 13:47 -0600
Re: Qbasic "Osmium" <r124c4u102@comcast.net> - 2016-02-20 14:21 -0600
Re: Qbasic Dave Garland <dave.garland@wizinfo.com> - 2016-02-20 18:06 -0600
Re: Qbasic Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-20 18:57 +0000
Re: Qbasic Dave Garland <dave.garland@wizinfo.com> - 2016-02-20 14:02 -0600
Re: Qbasic Mike Spencer <mds@bogus.nodomain.nowhere> - 2016-02-20 16:51 -0400
Re: Qbasic Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-18 21:34 +0000
Re: Qbasic Andrew Swallow <am.swallow@btinternet.com> - 2016-02-18 06:25 +0000
Re: Qbasic scott@slp53.sl.home (Scott Lurndal) - 2016-02-18 14:17 +0000
Re: Qbasic Stephen Sprunk <stephen@sprunk.org> - 2016-02-18 11:33 -0600
Re: Qbasic scott@slp53.sl.home (Scott Lurndal) - 2016-02-18 17:41 +0000
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-18 14:54 -0800
Re: Qbasic Peter Flass <peter_flass@yahoo.com> - 2016-02-17 18:41 -0700
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-18 20:14 -0500
Re: Qbasic Stephen Sprunk <stephen@sprunk.org> - 2016-02-18 20:54 -0600
Re: Qbasic "gareth" <no.spam@thank.you.invalid> - 2016-02-19 11:44 +0000
Re: Qbasic Stephen Sprunk <stephen@sprunk.org> - 2016-02-13 12:24 -0600
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-12 23:26 -0800
Re: Qbasic Peter Flass <peter_flass@yahoo.com> - 2016-02-13 07:43 -0700
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-13 10:29 -0500
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-13 08:20 -0800
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-13 09:21 -0800
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-13 12:44 -0500
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-13 11:31 -0800
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-13 15:52 -0500
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-13 13:02 -0800
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-13 16:58 -0500
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-13 20:24 -0800
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-13 21:39 -0800
Re: Qbasic Peter Flass <peter_flass@yahoo.com> - 2016-02-14 08:48 -0700
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-13 14:17 -0800
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-13 20:00 -0500
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-13 17:52 -0800
Re: Qbasic Anne & Lynn Wheeler <lynn@garlic.com> - 2016-02-13 19:28 -0800
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-13 21:32 -0800
Re: Qbasic David Wade <dave.g4ugm@gmail.com> - 2016-02-14 14:59 +0000
Re: Qbasic Peter Flass <peter_flass@yahoo.com> - 2016-02-14 08:48 -0700
Re: Qbasic Anne & Lynn Wheeler <lynn@garlic.com> - 2016-02-14 10:15 -0800
Re: Qbasic Anne & Lynn Wheeler <lynn@garlic.com> - 2016-02-14 09:48 -0800
Re: Qbasic Anne & Lynn Wheeler <lynn@garlic.com> - 2016-02-14 12:01 -0800
Re: Qbasic Peter Flass <peter_flass@yahoo.com> - 2016-02-14 08:48 -0700
Re: Qbasic Dan Espen <despen@verizon.net> - 2016-02-14 19:36 -0500
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-13 20:35 -0800
Re: Qbasic Dan Espen <despen@verizon.net> - 2016-02-14 10:15 -0500
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-14 08:20 -0800
Re: Qbasic Stephen Sprunk <stephen@sprunk.org> - 2016-02-14 14:31 -0600
Re: Qbasic Dan Espen <despen@verizon.net> - 2016-02-14 19:33 -0500
Re: Qbasic Peter Flass <peter_flass@yahoo.com> - 2016-02-16 18:52 -0700
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-13 14:04 -0800
Re: Qbasic Morten Reistad <first@last.name,invalid> - 2016-02-13 23:18 +0100
Re: Qbasic "Osmium" <r124c4u102@comcast.net> - 2016-02-13 17:25 -0600
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-13 19:42 -0500
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-13 20:30 -0800
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-13 21:49 -0800
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-14 06:36 -0800
Re: Qbasic Peter Flass <peter_flass@yahoo.com> - 2016-02-14 08:48 -0700
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-14 08:23 -0800
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-14 08:27 -0800
Re: Qbasic Peter Flass <peter_flass@yahoo.com> - 2016-02-16 18:52 -0700
Re: Qbasic Peter Flass <peter_flass@yahoo.com> - 2016-02-14 08:48 -0700
Re: Qbasic Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-15 21:27 +0000
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-15 14:30 -0800
Re: Qbasic Dan Espen <despen@verizon.net> - 2016-02-15 23:38 -0500
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-17 11:23 -0800
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-15 20:49 -0800
Re: Qbasic Andrew Swallow <am.swallow@btinternet.com> - 2016-02-16 07:07 +0000
Re: Qbasic Morten Reistad <first@last.name.invalid> - 2016-02-16 10:33 +0100
Re: Qbasic jmfbahciv <See.above@aol.com> - 2016-02-16 13:43 +0000
Re: Qbasic Morten Reistad <first@last.name.invalid> - 2016-02-16 15:21 +0100
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-17 11:30 -0800
Re: Qbasic scott@slp53.sl.home (Scott Lurndal) - 2016-02-17 19:49 +0000
Re: Qbasic jmfbahciv <See.above@aol.com> - 2016-02-18 13:58 +0000
Re: Qbasic Morten Reistad <first@last.name.invalid> - 2016-02-18 16:53 +0100
Re: Qbasic jmfbahciv <See.above@aol.com> - 2016-02-19 14:24 +0000
Re: Qbasic "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-02-20 05:09 +1100
Re: Qbasic jmfbahciv <See.above@aol.com> - 2016-02-20 15:18 +0000
Re: Qbasic "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-02-21 03:30 +1100
Re: Qbasic Morten Reistad <first@last.name.invalid> - 2016-02-20 19:06 +0100
Re: Qbasic "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-02-21 05:55 +1100
Re: Qbasic Morten Reistad <first@last.name.invalid> - 2016-02-20 21:42 +0100
Re: Qbasic "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-02-21 12:05 +1100
Re: Qbasic Stephen Sprunk <stephen@sprunk.org> - 2016-02-20 16:24 -0600
Re: Qbasic Anonymous <no_email@invalid.invalid> - 2016-02-21 00:26 +0000
Re: Qbasic Peter Flass <peter_flass@yahoo.com> - 2016-02-19 11:15 -0700
Re: Qbasic jmfbahciv <See.above@aol.com> - 2016-02-20 15:18 +0000
Re: Qbasic "hgww" <hgww@gmail.com> - 2016-02-21 03:43 +1100
Re: Qbasic scott@slp53.sl.home (Scott Lurndal) - 2016-02-19 18:36 +0000
Re: Qbasic jmfbahciv <See.above@aol.com> - 2016-02-20 15:18 +0000
Re: Qbasic "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-02-21 03:31 +1100
Re: Qbasic Morten Reistad <first@last.name.invalid> - 2016-02-20 19:13 +0100
Re: Qbasic "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-02-21 06:00 +1100
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-16 10:10 -0800
Re: Qbasic scott@slp53.sl.home (Scott Lurndal) - 2016-02-16 18:32 +0000
Re: Qbasic Andrew Swallow <am.swallow@btinternet.com> - 2016-02-16 21:08 +0000
Re: Qbasic Stan Barr <plan.b@bluesomatic.org> - 2016-02-16 08:20 +0000
Re: Qbasic Peter Flass <peter_flass@yahoo.com> - 2016-02-16 18:52 -0700
Re: Qbasic Lawrence Statton <lawrence@senguio.mx> - 2016-02-16 20:30 -0600
Re: Qbasic Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-17 04:17 +0000
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-17 11:25 -0800
Re: Qbasic Morten Reistad <first@last.name.invalid> - 2016-02-13 17:25 +0100
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-13 11:34 -0800
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-13 16:47 -0500
Re: Qbasic Andrew Swallow <am.swallow@btinternet.com> - 2016-02-14 04:09 +0000
Re: Qbasic Peter Flass <peter_flass@yahoo.com> - 2016-02-14 08:48 -0700
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-14 12:12 -0500
Re: Qbasic Dan Espen <despen@verizon.net> - 2016-02-14 19:39 -0500
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-14 19:55 -0500
Re: Qbasic Dan Espen <despen@verizon.net> - 2016-02-14 20:08 -0500
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-14 20:41 -0800
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-15 12:06 -0500
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-15 09:21 -0800
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-15 09:29 -0800
Re: Qbasic Andrew Swallow <am.swallow@btinternet.com> - 2016-02-15 21:22 +0000
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-15 13:39 -0500
Re: Qbasic Andrew Swallow <am.swallow@btinternet.com> - 2016-02-15 21:20 +0000
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-13 09:18 -0800
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-13 13:07 -0500
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-13 10:48 -0800
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-13 15:49 -0500
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-13 14:09 -0800
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-13 19:56 -0500
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-13 17:43 -0800
Re: Qbasic Andrew Swallow <am.swallow@btinternet.com> - 2016-02-14 04:16 +0000
Re: Qbasic Morten Reistad <first@last.name.invalid> - 2016-02-13 23:35 +0100
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-13 20:08 -0500
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-13 17:55 -0800
Re: Qbasic Andrew Swallow <am.swallow@btinternet.com> - 2016-02-14 04:14 +0000
Re: Qbasic Peter Flass <peter_flass@yahoo.com> - 2016-02-14 08:48 -0700
Re: Qbasic Morten Reistad <first@last.name.invalid> - 2016-02-13 16:13 +0100
Re: Qbasic "Blanco" <rko4410@gmail.com> - 2016-02-14 04:44 +1100
Re: Qbasic Morten Reistad <first@last.name.invalid> - 2016-02-13 23:30 +0100
Re: Qbasic "Blanco" <rko4410@gmail.com> - 2016-02-14 13:27 +1100
Re: Qbasic Stephen Sprunk <stephen@sprunk.org> - 2016-02-14 13:43 -0600
Re: Qbasic "hgww" <hgww@gmail.com> - 2016-02-15 07:31 +1100
Re: Qbasic pechter@pechter.dyndns.org (William Pechter) - 2016-02-12 17:38 +0000
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-12 19:33 -0500
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-12 09:51 -0800
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-12 19:24 -0500
Re: Qbasic jmfbahciv <See.above@aol.com> - 2016-02-13 14:37 +0000
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-13 10:24 -0500
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-12 23:20 -0800
Re: Qbasic "gareth" <no.spam@thank.you.invalid> - 2016-02-13 11:09 +0000
Re: Qbasic Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-14 00:53 +0000
Re: Qbasic Roberto Waltman <usenet@rwaltman.com> - 2016-02-15 23:30 -0500
Re: Qbasic scott@slp53.sl.home (Scott Lurndal) - 2016-02-16 15:56 +0000
Re: Qbasic Ahem A Rivet's Shot <steveo@eircom.net> - 2016-02-13 11:33 +0000
Page 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2016-02-14 08:23 -0800 |
| Message-ID | <c9e89297-11d0-41eb-b279-427e363a5955@googlegroups.com> |
| In reply to | #159357 |
On Sunday, February 14, 2016 at 8:48:12 AM UTC-7, Peter Flass wrote: > Many machines had software floating-point, such as the SDS940. I think > one model in the series had hardware FP, but that was an exception. Well, there was the 9300, which was related, but which wasn't really in the series. John Savard
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2016-02-14 08:27 -0800 |
| Message-ID | <5f4412af-652c-479c-8fbe-016b01bdd605@googlegroups.com> |
| In reply to | #159361 |
On Sunday, February 14, 2016 at 9:23:22 AM UTC-7, Quadibloc wrote: > On Sunday, February 14, 2016 at 8:48:12 AM UTC-7, Peter Flass wrote: > > > Many machines had software floating-point, such as the SDS940. I think > > one model in the series had hardware FP, but that was an exception. > > Well, there was the 9300, which was related, but which wasn't really in the > series. I just checked. Hardware floating-point was available for the 9300 as an option. The 930 (and thus the 940) didn't have such an option available. John Savard
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2016-02-16 18:52 -0700 |
| Message-ID | <571483095.477364727.183371.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #159364 |
Quadibloc <jsavard@ecn.ab.ca> wrote: > On Sunday, February 14, 2016 at 9:23:22 AM UTC-7, Quadibloc wrote: >> On Sunday, February 14, 2016 at 8:48:12 AM UTC-7, Peter Flass wrote: >> >>> Many machines had software floating-point, such as the SDS940. I think >>> one model in the series had hardware FP, but that was an exception. >> >> Well, there was the 9300, which was related, but which wasn't really in the >> series. > > I just checked. Hardware floating-point was available for the 9300 as an option. > > The 930 (and thus the 940) didn't have such an option available. The 9300 was the one I was thinking of, although the number escaped me at the time. Thanks. > > John Savard > -- Pete
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2016-02-14 08:48 -0700 |
| Message-ID | <812668888.477156619.586020.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #159321 |
Quadibloc <jsavard@ecn.ab.ca> wrote: > On Saturday, February 13, 2016 at 5:41:35 PM UTC-7, J. Clarke wrote: >> In article <beaadb0d-840d-4bc2-bf58-293c8510deab@googlegroups.com>, >> hancock4@bbs.cpcn.com says... > >>> *For example, the Z mainframe has a SQRT instruction now. Does the x86 >>> have one? > >> X86 has had SQRT since the '486. It had it before that but only in an >> add-on chip. > > Yes, pretty well _all_ microprocessor chips with hardware floating-point these > days even have instructions for LOG, SIN, and COS. In the case of SQRT, it's > almost mandated by the IEEE 784 spec, since an algorithm exists for SQRT that > produces the exact most accurate floating-point approximation to the result - > just as is the case for the four arithmetic operations. > > This seems strange to a fossil like myself, because no one particularly felt a > need to have hardware trig functions and the like even on big mainframe > computers back in the old days. But today it's practically _de rigeur_. I never did the scientific stuff, but no place I ever worked would have used them. Remember, floating-point was an option on the 360/30, and I saw few shops that had that. Hardware was expensive and constrained back then. > > Presumably it's because techniques such as the CORDIC algorithm allow hardware > to do a much better job than a polynomial approximation. > > John Savard > -- Pete
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2016-02-15 21:27 +0000 |
| Message-ID | <n9tfr911t66@news3.newsguy.com> |
| In reply to | #159355 |
On 2016-02-14, Peter Flass <peter_flass@yahoo.com> wrote: > Quadibloc <jsavard@ecn.ab.ca> wrote: > >> On Saturday, February 13, 2016 at 5:41:35 PM UTC-7, J. Clarke wrote: >> >>> In article <beaadb0d-840d-4bc2-bf58-293c8510deab@googlegroups.com>, >>> hancock4@bbs.cpcn.com says... >>> >>>> *For example, the Z mainframe has a SQRT instruction now. Does the x86 >>>> have one? >> >>> X86 has had SQRT since the '486. It had it before that but only in an >>> add-on chip. >> >> Yes, pretty well _all_ microprocessor chips with hardware floating-point >> these days even have instructions for LOG, SIN, and COS. In the case of >> SQRT, it's almost mandated by the IEEE 784 spec, since an algorithm exists >> for SQRT that produces the exact most accurate floating-point approximation >> to the result - just as is the case for the four arithmetic operations. >> >> This seems strange to a fossil like myself, because no one particularly felt >> a need to have hardware trig functions and the like even on big mainframe >> computers back in the old days. But today it's practically _de rigeur_. > > I never did the scientific stuff, but no place I ever worked would have > used them. Remember, floating-point was an option on the 360/30, and I > saw few shops that had that. Hardware was expensive and constrained back > then. I'm always somewhat perplexed by this fascination with floating point. Sure, there are applications where it's needed - but many commercial shops have little or no use for it. In my entire career I can count the number of times I've used floating point on the fingers of one hand - and this includes stuff I'm working on right now. YMMV. -- /~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs) \ / I'm really at ac.dekanfrus if you read it the right way. X Top-posted messages will probably be ignored. See RFC1855. / \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2016-02-15 14:30 -0800 |
| Message-ID | <c227bf22-3354-43e5-b84d-85dac4532ab6@googlegroups.com> |
| In reply to | #159446 |
On Monday, February 15, 2016 at 2:27:37 PM UTC-7, Charlie Gibbs wrote: > I'm always somewhat perplexed by this fascination with floating point. > Sure, there are applications where it's needed - but many commercial > shops have little or no use for it. In my entire career I can count > the number of times I've used floating point on the fingers of one hand - > and this includes stuff I'm working on right now. It's certainly true that Windows 3.1 worked just fine on 386 boxes which didn't have the 387 coprocessor installed. Ditto for the Macintosh, which was based on a 68000 without a 68881. So it's not as if a computer without hardware floating-point is a fossil stuck in the dark ages of the command prompt! However, floating-point is the fanciest and most demanding type of calculation handled by a computer. It requires many more transistors, and takes more cycles. So a computer that can do it well is bigger and more impressive than one which can "merely" do binary integer arithmetic well. Database machines should have good *decimal* arithmetic capabilities, and these also require extra hardware to get right. (Also an option on the 360.) Plus, there _are_ some popular applications... even if they're not _productivity_ applications... that do make heavy use of floating-point arithmetic. Just try playing Crysis without it! John Savard
[toc] | [prev] | [next] | [standalone]
| From | Dan Espen <despen@verizon.net> |
|---|---|
| Date | 2016-02-15 23:38 -0500 |
| Message-ID | <n9u8u5$gle$1@dont-email.me> |
| In reply to | #159446 |
Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes: > On 2016-02-14, Peter Flass <peter_flass@yahoo.com> wrote: > >> Quadibloc <jsavard@ecn.ab.ca> wrote: >> >>> On Saturday, February 13, 2016 at 5:41:35 PM UTC-7, J. Clarke wrote: >>> >>>> In article <beaadb0d-840d-4bc2-bf58-293c8510deab@googlegroups.com>, >>>> hancock4@bbs.cpcn.com says... >>>> >>>>> *For example, the Z mainframe has a SQRT instruction now. Does the x86 >>>>> have one? >>> >>>> X86 has had SQRT since the '486. It had it before that but only in an >>>> add-on chip. >>> >>> Yes, pretty well _all_ microprocessor chips with hardware floating-point >>> these days even have instructions for LOG, SIN, and COS. In the case of >>> SQRT, it's almost mandated by the IEEE 784 spec, since an algorithm exists >>> for SQRT that produces the exact most accurate floating-point approximation >>> to the result - just as is the case for the four arithmetic operations. >>> >>> This seems strange to a fossil like myself, because no one particularly felt >>> a need to have hardware trig functions and the like even on big mainframe >>> computers back in the old days. But today it's practically _de rigeur_. >> >> I never did the scientific stuff, but no place I ever worked would have >> used them. Remember, floating-point was an option on the 360/30, and I >> saw few shops that had that. Hardware was expensive and constrained back >> then. > > I'm always somewhat perplexed by this fascination with floating point. > Sure, there are applications where it's needed - but many commercial > shops have little or no use for it. In my entire career I can count > the number of times I've used floating point on the fingers of one hand - > and this includes stuff I'm working on right now. > > YMMV. 25 years in consulting as part of a 50 year career. The only floating point I remember was some tyro coding up some formulas in COBOL that convinced COBOL it needed floating point. One of things I fixed there was stopping COBOL from using floating point. Seems to me, any user facing machine needs to do decimal arithmetic quickly. -- Dan Espen
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2016-02-17 11:23 -0800 |
| Message-ID | <d157d32f-c8c8-4cab-b04b-f860a6758497@googlegroups.com> |
| In reply to | #159465 |
On Monday, February 15, 2016 at 9:38:15 PM UTC-7, D_J_E wrote: > Seems to me, any user facing machine needs to do decimal arithmetic > quickly. Define "quickly". A PDP-8/S, a rather slow machine with only the ability to do binary integer arithmetic, would be able to convert from binary to decimal in the blink of an eye, even if it would be slow enough to annoy users if it had a lot of *other* calculations to do first. So I'd think that doing decimal conversion in software on, say, a quad-core Core i7 running at over 2 GHz, wouldn't be neglectful of speed requirements for user-facing equipment. John Savard
[toc] | [prev] | [next] | [standalone]
| From | hancock4@bbs.cpcn.com |
|---|---|
| Date | 2016-02-15 20:49 -0800 |
| Message-ID | <468779aa-46a1-4b28-b6b0-bd03750b9089@googlegroups.com> |
| In reply to | #159446 |
On Monday, February 15, 2016 at 4:27:37 PM UTC-5, Charlie Gibbs wrote: > I'm always somewhat perplexed by this fascination with floating point. > Sure, there are applications where it's needed - but many commercial > shops have little or no use for it. In my entire career I can count > the number of times I've used floating point on the fingers of one hand - > and this includes stuff I'm working on right now. FWIW, our S/360-40 turned out to have floating point on it. We didn't even know until someone tried to run a job on it, and it worked. Anyway, likewise, I never had the need to use floating point once I got out of college. However, most of my employers had research or engineering groups who did use Fortran for their work, and I presume that means the computer had to have floating point to support the Fortran, unless everything was done as an Integer, which I doubt. (In Fortran, all 'real' variables are floating point, right?) However, admittedly I don't think the researchers where I worked were doing heavy-duty number crunching. Much of the time they were just doing Fortran because they knew it (almost everybody took it in college) and it suited their needs better than COBOL.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Swallow <am.swallow@btinternet.com> |
|---|---|
| Date | 2016-02-16 07:07 +0000 |
| Message-ID | <wKydnfc7-q4dV1_LnZ2dnUU78aWdnZ2d@giganews.com> |
| In reply to | #159469 |
On 16/02/2016 04:49, hancock4@bbs.cpcn.com wrote: > On Monday, February 15, 2016 at 4:27:37 PM UTC-5, Charlie Gibbs wrote: > >> I'm always somewhat perplexed by this fascination with floating point. >> Sure, there are applications where it's needed - but many commercial >> shops have little or no use for it. In my entire career I can count >> the number of times I've used floating point on the fingers of one hand - >> and this includes stuff I'm working on right now. > > FWIW, our S/360-40 turned out to have floating point on it. We didn't > even know until someone tried to run a job on it, and it worked. > > Anyway, likewise, I never had the need to use floating point once I > got out of college. However, most of my employers had research > or engineering groups who did use Fortran for their work, and I > presume that means the computer had to have floating point to support > the Fortran, unless everything was done as an Integer, which I doubt. > (In Fortran, all 'real' variables are floating point, right?) > > However, admittedly I don't think the researchers where I worked were > doing heavy-duty number crunching. Much of the time they were just > doing Fortran because they knew it (almost everybody took it in college) > and it suited their needs better than COBOL. > COBOL found calculating sin, cos, tan and fast Fourier transforms difficult.
[toc] | [prev] | [next] | [standalone]
| From | Morten Reistad <first@last.name.invalid> |
|---|---|
| Date | 2016-02-16 10:33 +0100 |
| Message-ID | <q07bpc-son.ln1@sambook.reistad.name> |
| In reply to | #159475 |
In article <wKydnfc7-q4dV1_LnZ2dnUU78aWdnZ2d@giganews.com>, Andrew Swallow <am.swallow@btinternet.com> wrote: >On 16/02/2016 04:49, hancock4@bbs.cpcn.com wrote: >> On Monday, February 15, 2016 at 4:27:37 PM UTC-5, Charlie Gibbs wrote: >> >>> I'm always somewhat perplexed by this fascination with floating point. >>> Sure, there are applications where it's needed - but many commercial >>> shops have little or no use for it. In my entire career I can count >>> the number of times I've used floating point on the fingers of one hand - >>> and this includes stuff I'm working on right now. >> >> FWIW, our S/360-40 turned out to have floating point on it. We didn't >> even know until someone tried to run a job on it, and it worked. >> >> Anyway, likewise, I never had the need to use floating point once I >> got out of college. However, most of my employers had research >> or engineering groups who did use Fortran for their work, and I >> presume that means the computer had to have floating point to support >> the Fortran, unless everything was done as an Integer, which I doubt. >> (In Fortran, all 'real' variables are floating point, right?) >> >> However, admittedly I don't think the researchers where I worked were >> doing heavy-duty number crunching. Much of the time they were just >> doing Fortran because they knew it (almost everybody took it in college) >> and it suited their needs better than COBOL. >> > >COBOL found calculating sin, cos, tan and fast Fourier transforms difficult. No, it is just cumbersome, not difficult. COMP-3 and COMPUTE should help a lot, plus some external libraries doing the trig functions and fft's (in some other language, e.g. C). -- mrr
[toc] | [prev] | [next] | [standalone]
| From | jmfbahciv <See.above@aol.com> |
|---|---|
| Date | 2016-02-16 13:43 +0000 |
| Message-ID | <PM00052BE32A447276@aca40675.ipt.aol.com> |
| In reply to | #159482 |
Morten Reistad wrote: > In article <wKydnfc7-q4dV1_LnZ2dnUU78aWdnZ2d@giganews.com>, > Andrew Swallow <am.swallow@btinternet.com> wrote: >>On 16/02/2016 04:49, hancock4@bbs.cpcn.com wrote: >>> On Monday, February 15, 2016 at 4:27:37 PM UTC-5, Charlie Gibbs wrote: >>> >>>> I'm always somewhat perplexed by this fascination with floating point. >>>> Sure, there are applications where it's needed - but many commercial >>>> shops have little or no use for it. In my entire career I can count >>>> the number of times I've used floating point on the fingers of one hand - >>>> and this includes stuff I'm working on right now. >>> >>> FWIW, our S/360-40 turned out to have floating point on it. We didn't >>> even know until someone tried to run a job on it, and it worked. >>> >>> Anyway, likewise, I never had the need to use floating point once I >>> got out of college. However, most of my employers had research >>> or engineering groups who did use Fortran for their work, and I >>> presume that means the computer had to have floating point to support >>> the Fortran, unless everything was done as an Integer, which I doubt. >>> (In Fortran, all 'real' variables are floating point, right?) >>> >>> However, admittedly I don't think the researchers where I worked were >>> doing heavy-duty number crunching. Much of the time they were just >>> doing Fortran because they knew it (almost everybody took it in college) >>> and it suited their needs better than COBOL. >>> >> >>COBOL found calculating sin, cos, tan and fast Fourier transforms difficult. > > No, it is just cumbersome, not difficult. COMP-3 and COMPUTE should > help a lot, plus some external libraries doing the trig functions > and fft's (in some other language, e.g. C). But it wasn't simple to call other languages' libraries with COBOL. The calling sequences were dissimilar; the OTS of each lanugage was a segment. It wasn't until much later that two OTS might be able to reside in one user's address sapce. Also languages usually were bought separately so the calls had to occur on systems which had both installed. /BAH
[toc] | [prev] | [next] | [standalone]
| From | Morten Reistad <first@last.name.invalid> |
|---|---|
| Date | 2016-02-16 15:21 +0100 |
| Message-ID | <ernbpc-f2q.ln1@sambook.reistad.name> |
| In reply to | #159486 |
In article <PM00052BE32A447276@aca40675.ipt.aol.com>, jmfbahciv <See.above@aol.com> wrote: >Morten Reistad wrote: >> In article <wKydnfc7-q4dV1_LnZ2dnUU78aWdnZ2d@giganews.com>, >> Andrew Swallow <am.swallow@btinternet.com> wrote: >>>On 16/02/2016 04:49, hancock4@bbs.cpcn.com wrote: >>>> On Monday, February 15, 2016 at 4:27:37 PM UTC-5, Charlie Gibbs wrote: >>>> >>>>> I'm always somewhat perplexed by this fascination with floating point. >>>>> Sure, there are applications where it's needed - but many commercial >>>>> shops have little or no use for it. In my entire career I can count >>>>> the number of times I've used floating point on the fingers of one hand - >>>>> and this includes stuff I'm working on right now. >>>> >>>> FWIW, our S/360-40 turned out to have floating point on it. We didn't >>>> even know until someone tried to run a job on it, and it worked. >>>> >>>> Anyway, likewise, I never had the need to use floating point once I >>>> got out of college. However, most of my employers had research >>>> or engineering groups who did use Fortran for their work, and I >>>> presume that means the computer had to have floating point to support >>>> the Fortran, unless everything was done as an Integer, which I doubt. >>>> (In Fortran, all 'real' variables are floating point, right?) >>>> >>>> However, admittedly I don't think the researchers where I worked were >>>> doing heavy-duty number crunching. Much of the time they were just >>>> doing Fortran because they knew it (almost everybody took it in college) >>>> and it suited their needs better than COBOL. >>>> >>> >>>COBOL found calculating sin, cos, tan and fast Fourier transforms difficult. >> >> No, it is just cumbersome, not difficult. COMP-3 and COMPUTE should >> help a lot, plus some external libraries doing the trig functions >> and fft's (in some other language, e.g. C). > >But it wasn't simple to call other languages' libraries with COBOL. >The calling sequences were dissimilar; the OTS of each lanugage >was a segment. It wasn't until much later that two OTS might >be able to reside in one user's address sapce. Also languages >usually were bought separately so the calls had to occur on systems >which had both installed. You would need to do some assembly hacking for Tops10, cics and other one-memory-map systems. The usual method was to write the subroutine as a dummy in cobol, and the contents in the other language; and build assembly instead of code, and then you got to integrate the code manually. It was about a weeks work, but it was definatly possible. I have done it on both CICS (1.7) and Tops20(4.2, with full pa1050 cobol and fortran; i.e. identical to tops10). For native tops20, primos, unix this was a lot more straightforward, the ots systems needed at most an init-call; normally done in the main of every program language. But cobol to fortran needed compiler support or special assembly integration. Still does. -- mrr
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2016-02-17 11:30 -0800 |
| Message-ID | <968ae2b3-3798-427a-831e-6259682eaa90@googlegroups.com> |
| In reply to | #159486 |
On Tuesday, February 16, 2016 at 6:42:06 AM UTC-7, jmfbahciv wrote: > But it wasn't simple to call other languages' libraries with COBOL. > The calling sequences were dissimilar; the OTS of each lanugage > was a segment. It wasn't until much later that two OTS might > be able to reside in one user's address sapce. Also languages > usually were bought separately so the calls had to occur on systems > which had both installed. This isn't a universal rule for all mainframe computers. With some, you don't need to own the language to run a binary program compiled from that language, because the only library calls are to standard libraries included in the operating system. As well, calling conventions do differ between languages, but some languages shared conventions - thus, PL/I had extra features that required a special calling convention, but FORTRAN and COBOL might use the old standard calling convention. And on some machines, the address space is linear, and the issue of segments does not arise. John Savard
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2016-02-17 19:49 +0000 |
| Message-ID | <a94xy.5307$FL.4403@fx20.iad> |
| In reply to | #159600 |
Quadibloc <jsavard@ecn.ab.ca> writes: >On Tuesday, February 16, 2016 at 6:42:06 AM UTC-7, jmfbahciv wrote: > >> But it wasn't simple to call other languages' libraries with COBOL. >> The calling sequences were dissimilar; the OTS of each lanugage >> was a segment. It wasn't until much later that two OTS might >> be able to reside in one user's address sapce. Also languages >> usually were bought separately so the calls had to occur on systems >> which had both installed. > >This isn't a universal rule for all mainframe computers. True. It was pretty straightforward to call fortran or BPL subroutines from COBOL in the burroughs medium systems. It was also straighforward to embed assembler (ENTER SYMBOLIC) in COBOL68 programs (that capability was removed from the COBOL85 compiler).
[toc] | [prev] | [next] | [standalone]
| From | jmfbahciv <See.above@aol.com> |
|---|---|
| Date | 2016-02-18 13:58 +0000 |
| Message-ID | <PM00052C0BC1B79E67@aca4282e.ipt.aol.com> |
| In reply to | #159600 |
Quadibloc wrote: > On Tuesday, February 16, 2016 at 6:42:06 AM UTC-7, jmfbahciv wrote: > >> But it wasn't simple to call other languages' libraries with COBOL. >> The calling sequences were dissimilar; the OTS of each lanugage >> was a segment. It wasn't until much later that two OTS might >> be able to reside in one user's address sapce. Also languages >> usually were bought separately so the calls had to occur on systems >> which had both installed. > > This isn't a universal rule for all mainframe computers. Sorry. I was talking about old DEC. > > With some, you don't need to own the language to run a binary program compiled > from that language, because the only library calls are to standard libraries > included in the operating system. Every one had their own revision of "standard libraries". Even the same OS would have updates or replacements. > > As well, calling conventions do differ between languages, but some languages > shared conventions - thus, PL/I had extra features that required a special > calling convention, but FORTRAN and COBOL might use the old standard calling > convention. Having the same calling conventions is a drip in the bit bucket. The problem is addressing and memory management which are not done similarly. > > And on some machines, the address space is linear, and the issue of segments > does not arise. WEll, that is one tactic but is so wastefully slow and a PITA to administer updates to the software. /BAH
[toc] | [prev] | [next] | [standalone]
| From | Morten Reistad <first@last.name.invalid> |
|---|---|
| Date | 2016-02-18 16:53 +0100 |
| Message-ID | <c06hpc-531.ln1@sambook.reistad.name> |
| In reply to | #159668 |
In article <PM00052C0BC1B79E67@aca4282e.ipt.aol.com>, jmfbahciv <See.above@aol.com> wrote: >Quadibloc wrote: >> On Tuesday, February 16, 2016 at 6:42:06 AM UTC-7, jmfbahciv wrote: >> >>> But it wasn't simple to call other languages' libraries with COBOL. >>> The calling sequences were dissimilar; the OTS of each lanugage >>> was a segment. It wasn't until much later that two OTS might >>> be able to reside in one user's address sapce. Also languages >>> usually were bought separately so the calls had to occur on systems >>> which had both installed. >> >> This isn't a universal rule for all mainframe computers. > >Sorry. I was talking about old DEC. This was why the VMS cusp developers used _all_ the languages to develop their stuff, so all the language runtimes had to be included bu default. Prime also had a policy of supplying all the standard language runtimes. >> With some, you don't need to own the language to run a binary program >compiled >> from that language, because the only library calls are to standard libraries >> included in the operating system. > >Every one had their own revision of "standard libraries". Even the same >OS would have updates or replacements. >> >> As well, calling conventions do differ between languages, but some languages >> shared conventions - thus, PL/I had extra features that required a special >> calling convention, but FORTRAN and COBOL might use the old standard calling >> convention. > >Having the same calling conventions is a drip in the bit bucket. The problem >is addressing and memory management which are not done similarly. A lot of this is supported by having some magic words in the declaration; procedure foo(int bar) external fortran; .. or something like this. >> And on some machines, the address space is linear, and the issue of segments >> does not arise. > >WEll, that is one tactic but is so wastefully slow and a PITA to administer >updates to the software. Or, plain dynamic linking. Like Multics, or the bowlderised version; Primos. And like Linux got in version 1.0.10, FreeBSD in version 2.4, and windows has halfway had (ex version control, they screwed up on that one) all the time. -- mrr
[toc] | [prev] | [next] | [standalone]
| From | jmfbahciv <See.above@aol.com> |
|---|---|
| Date | 2016-02-19 14:24 +0000 |
| Message-ID | <PM00052C2025C99257@aca432ec.ipt.aol.com> |
| In reply to | #159675 |
Morten Reistad wrote: > In article <PM00052C0BC1B79E67@aca4282e.ipt.aol.com>, > jmfbahciv <See.above@aol.com> wrote: >>Quadibloc wrote: >>> On Tuesday, February 16, 2016 at 6:42:06 AM UTC-7, jmfbahciv wrote: >>> >>>> But it wasn't simple to call other languages' libraries with COBOL. >>>> The calling sequences were dissimilar; the OTS of each lanugage >>>> was a segment. It wasn't until much later that two OTS might >>>> be able to reside in one user's address sapce. Also languages >>>> usually were bought separately so the calls had to occur on systems >>>> which had both installed. >>> >>> This isn't a universal rule for all mainframe computers. >> >>Sorry. I was talking about old DEC. > > > This was why the VMS cusp developers used _all_ the languages to > develop their stuff, so all the language runtimes had to be included > bu default. Prime also had a policy of supplying all the standard > language runtimes. A customer had to buy FORTRAN to get any of the FORTRAN library functions. The same was true for COBOL and any other language. BLISS was also a bitch. > >>> With some, you don't need to own the language to run a binary program >>compiled >>> from that language, because the only library calls are to standard libraries >>> included in the operating system. >> >>Every one had their own revision of "standard libraries". Even the same >>OS would have updates or replacements. >>> >>> As well, calling conventions do differ between languages, but some languages >>> shared conventions - thus, PL/I had extra features that required a special >>> calling convention, but FORTRAN and COBOL might use the old standard calling >>> convention. >> >>Having the same calling conventions is a drip in the bit bucket. The problem >>is addressing and memory management which are not done similarly. > > A lot of this is supported by having some magic words in the declaration; > procedure foo(int bar) external fortran; .. or something like this. > >>> And on some machines, the address space is linear, and the issue of segments >>> does not arise. >> >>WEll, that is one tactic but is so wastefully slow and a PITA to administer >>updates to the software. > > Or, plain dynamic linking. Like Multics, or the bowlderised version; Primos. There are problems with dynamic linking when library files on the disk change even if a customer has bought all of the products. Libraries back then were part of the final EXE. If they were not, then the code had to be GETSEGed during execution. We did finally implement a MERGE when the hardware supported extended sections. There wasn't enough physical nor virutal core to include all libraries at runtime. > > And like Linux got in version 1.0.10, FreeBSD in version 2.4, and windows > has halfway had (ex version control, they screwed up on that one) all > the time. Dynamic linking became possible when the software development was completely divorced from the hardware development. /BAH
[toc] | [prev] | [next] | [standalone]
| From | "Rod Speed" <rod.speed.aaa@gmail.com> |
|---|---|
| Date | 2016-02-20 05:09 +1100 |
| Message-ID | <dip43pFtr3bU1@mid.individual.net> |
| In reply to | #159793 |
"jmfbahciv" <See.above@aol.com> wrote in message news:PM00052C2025C99257@aca432ec.ipt.aol.com... > Morten Reistad wrote: >> In article <PM00052C0BC1B79E67@aca4282e.ipt.aol.com>, >> jmfbahciv <See.above@aol.com> wrote: >>>Quadibloc wrote: >>>> On Tuesday, February 16, 2016 at 6:42:06 AM UTC-7, jmfbahciv wrote: >>>> >>>>> But it wasn't simple to call other languages' libraries with COBOL. >>>>> The calling sequences were dissimilar; the OTS of each lanugage >>>>> was a segment. It wasn't until much later that two OTS might >>>>> be able to reside in one user's address sapce. Also languages >>>>> usually were bought separately so the calls had to occur on systems >>>>> which had both installed. >>>> >>>> This isn't a universal rule for all mainframe computers. >>> >>>Sorry. I was talking about old DEC. >> >> >> This was why the VMS cusp developers used _all_ the languages to >> develop their stuff, so all the language runtimes had to be included >> bu default. Prime also had a policy of supplying all the standard >> language runtimes. > > A customer had to buy FORTRAN to get any of the FORTRAN library > functions. The same was true for COBOL and any other language. > BLISS was also a bitch. > > >> >>>> With some, you don't need to own the language to run a binary program >>>compiled >>>> from that language, because the only library calls are to standard > libraries >>>> included in the operating system. >>> >>>Every one had their own revision of "standard libraries". Even the same >>>OS would have updates or replacements. >>>> >>>> As well, calling conventions do differ between languages, but some > languages >>>> shared conventions - thus, PL/I had extra features that required a >>>> special >>>> calling convention, but FORTRAN and COBOL might use the old standard > calling >>>> convention. >>> >>>Having the same calling conventions is a drip in the bit bucket. The > problem >>>is addressing and memory management which are not done similarly. >> >> A lot of this is supported by having some magic words in the declaration; >> procedure foo(int bar) external fortran; .. or something like this. >> >>>> And on some machines, the address space is linear, and the issue of > segments >>>> does not arise. >>> >>>WEll, that is one tactic but is so wastefully slow and a PITA to >>>administer >>>updates to the software. >> >> Or, plain dynamic linking. Like Multics, or the bowlderised version; >> Primos. > > There are problems with dynamic linking when library files on the disk > change even if a customer has bought all of the products. Libraries back > then were part of the final EXE. If they were not, then the code had > to be GETSEGed during execution. We did finally implement a MERGE when > the hardware supported extended sections. There wasn't enough physical > nor virutal core to include all libraries at runtime. > >> >> And like Linux got in version 1.0.10, FreeBSD in version 2.4, and windows >> has halfway had (ex version control, they screwed up on that one) all >> the time. > > Dynamic linking became possible when the software development was > completely divorced from the hardware development. Bullshit. It was always possible before that.
[toc] | [prev] | [next] | [standalone]
| From | jmfbahciv <See.above@aol.com> |
|---|---|
| Date | 2016-02-20 15:18 +0000 |
| Message-ID | <PM00052C3450DEF437@aca405fb.ipt.aol.com> |
| In reply to | #159825 |
Rod Speed wrote: > > > "jmfbahciv" <See.above@aol.com> wrote in message > news:PM00052C2025C99257@aca432ec.ipt.aol.com... >> Morten Reistad wrote: >>> In article <PM00052C0BC1B79E67@aca4282e.ipt.aol.com>, >>> jmfbahciv <See.above@aol.com> wrote: >>>>Quadibloc wrote: >>>>> On Tuesday, February 16, 2016 at 6:42:06 AM UTC-7, jmfbahciv wrote: >>>>> >>>>>> But it wasn't simple to call other languages' libraries with COBOL. >>>>>> The calling sequences were dissimilar; the OTS of each lanugage >>>>>> was a segment. It wasn't until much later that two OTS might >>>>>> be able to reside in one user's address sapce. Also languages >>>>>> usually were bought separately so the calls had to occur on systems >>>>>> which had both installed. >>>>> >>>>> This isn't a universal rule for all mainframe computers. >>>> >>>>Sorry. I was talking about old DEC. >>> >>> >>> This was why the VMS cusp developers used _all_ the languages to >>> develop their stuff, so all the language runtimes had to be included >>> bu default. Prime also had a policy of supplying all the standard >>> language runtimes. >> >> A customer had to buy FORTRAN to get any of the FORTRAN library >> functions. The same was true for COBOL and any other language. >> BLISS was also a bitch. >> >> >>> >>>>> With some, you don't need to own the language to run a binary program >>>>compiled >>>>> from that language, because the only library calls are to standard >> libraries >>>>> included in the operating system. >>>> >>>>Every one had their own revision of "standard libraries". Even the same >>>>OS would have updates or replacements. >>>>> >>>>> As well, calling conventions do differ between languages, but some >> languages >>>>> shared conventions - thus, PL/I had extra features that required a >>>>> special >>>>> calling convention, but FORTRAN and COBOL might use the old standard >> calling >>>>> convention. >>>> >>>>Having the same calling conventions is a drip in the bit bucket. The >> problem >>>>is addressing and memory management which are not done similarly. >>> >>> A lot of this is supported by having some magic words in the declaration; >>> procedure foo(int bar) external fortran; .. or something like this. >>> >>>>> And on some machines, the address space is linear, and the issue of >> segments >>>>> does not arise. >>>> >>>>WEll, that is one tactic but is so wastefully slow and a PITA to >>>>administer >>>>updates to the software. >>> >>> Or, plain dynamic linking. Like Multics, or the bowlderised version; >>> Primos. >> >> There are problems with dynamic linking when library files on the disk >> change even if a customer has bought all of the products. Libraries back >> then were part of the final EXE. If they were not, then the code had >> to be GETSEGed during execution. We did finally implement a MERGE when >> the hardware supported extended sections. There wasn't enough physical >> nor virutal core to include all libraries at runtime. >> >>> >>> And like Linux got in version 1.0.10, FreeBSD in version 2.4, and windows >>> has halfway had (ex version control, they screwed up on that one) all >>> the time. >> >> Dynamic linking became possible when the software development was >> completely divorced from the hardware development. > > Bullshit. It was always possible before that. What memory mangement was used? /BAH
[toc] | [prev] | [next] | [standalone]
Page 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
Back to top | Article view | alt.folklore.computers
csiph-web