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 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2016-02-14 08:48 -0700 |
| Message-ID | <1385597732.477157142.786322.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #159344 |
David Wade <dave.g4ugm@gmail.com> wrote: > On 14/02/2016 01:52, hancock4@bbs.cpcn.com wrote: >> On Saturday, February 13, 2016 at 7:59:22 PM UTC-5, J. Clarke wrote: >> >> >>> I have wondered what a building full of Z cores could do and wondered >>> why IBM has never done it, but then I wondered why the PC wasn't based >>> on the single-chip 360 that IBM demonstrated some time before. On the >>> other hand, nobody ever accused MVS of being user-friendly and IBM would >>> have never second-sourced the architecture. >> >> As for the PC chip, my understanding is that back in the 8088 days, >> low powered chips were still quite expensive. Also, the 8088 architecture >> initially was far simpler than S/360, and the original PC DOS was far >> simpler than S/360-DOS. That is, to build a chip and supporting hardware >> that could do everything S/360 could do would've added too much to the >> original cost. Remember, floating point required an extra chip, and >> initially, PC's maxed at 640K memory. It was later on that they added >> all sorts of features. >> >> In addition, while I am weak on the internals, I _suspect_ the PC chip >> was a better design for its application. Certainly, running a program >> under PC-DOS and the C:> prompt was easier than coding a series of // EXEC >> cards. >> >> I don't know the internals of the "Big Blue" machines vs. Z architecture. >> My _guess_ is that Z is more intended to serve many users--thousands of >> CICS terminals--while Big Blue is intended to focus on heavy number >> crunching. I also guess that Big Blue can do math problems faster than Z. >> > > IBM already had CMS which uses human understandable commands like > "COPYFILE" "ERASE" and is pretty similar to MS-DOS in many ways. However > don't think even that doesn't well in 256K memory. > > Dave > VM needs a LOT less memory than MVS. My guess is that you could run a reasonable system in 64K (Lynn?) I know that on the same size machine VM ran much better than MVS/TSO. -- Pete
[toc] | [prev] | [next] | [standalone]
| From | Anne & Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2016-02-14 10:15 -0800 |
| Message-ID | <87twlbw43x.fsf@garlic.com> |
| In reply to | #159358 |
Peter Flass <peter_flass@yahoo.com> writes: > VM needs a LOT less memory than MVS. My guess is that you could run a > reasonable system in 64K (Lynn?) I know that on the same size machine VM > ran much better than MVS/TSO. Part of CMS issue was that it got increasingly bloated over the years ... and was also dependent on mainstream OS/360(MVS) applications ported to CMS. Endicott did XT/370 ... a couple 68k processors emulating some part of 370 running modified vm370 (with CMS) ... I/O was done by interprocessor messages with cp88 running on the 8088 processor ... it initially only had 384k "real memory". I did some number of "benchmarks" show extreme page thrashing ... because of the bloated memory requirements for compilers and assemblers. As a result they kludged an extra 128k on the memory card ... giving 512kbytes ... which helped to reduce the worst of the page thrashing. However, the 370 applications still tended to be relatively disk instensive (even w/o page thrashing) ... running on xt/370 compared poorly with applications implemented for the pc/xt environment. A CMS disk i/o required interprocessor message to cp88 which then did the i/o on the native XT 100ms/access hard drive. Applications native for PC/XT optimized for much less disk i/o per operation. MVS/TSO was significantly more bloated than VM370/CMS, much longer pathlengths, much less efficient system algorithms. CMS had some number of much more efficient native applications like editor ... but the compilers and assemblers were just ported to CMS from os360/MVS. CMS (& CP67 & vm370) I/O was much more efficient than OS360/MVS (but applications mainframe disks were much faster than PC disks ... so applications weren't as sensitive to optimization). Late 70s, IBM San Jose Research had environment with MVS 370/168 and VM370 370/158 with all 3330 disk strings connected to both machines ... but strict rules that MVS 3330 disks would never be mounted on vm370 "strings". One day they accidentally violated the rule and the datacenter almost got phone calls from users complaining about CMS response horribly degraded. The issue is os360/MVS environment makes heavy use of multi-track search ... which can tie-up channel, controller and disks for up to 1/3sec at a time. MVS multi-track search on VM370 string will lockout the vm370 "dedicated" controller ... having disastrous effects on CMS response. We immediately demanded that the MVS 3330 disk be moved to MVS string ... and MVS operations said they would do it 2nd shift (this was around 10am). We had enormously optimized VS1 for running under vm370 ... that ran faster under loaded vm370 on 370/158 than MVS ran on 370/168. We put its 3330 up on MVS string and were able to bring the MVS system to its knees with multi-track searches (and CMS response almost returns to normal). MVS operations then agreed to immediately move the MVS 3330, if we moved the VS1 3330. Besides all the significant performance issues with MVS/TSO ... a significant part of TSO response is significantly hurt by the underlying MVS use of multi-track search. Some past posts http://www.garlic.com/~lynn/submain.html#dasd -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | Anne & Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2016-02-14 09:48 -0800 |
| Message-ID | <87y4anw5d6.fsf@garlic.com> |
| In reply to | #159344 |
David Wade <dave.g4ugm@gmail.com> writes: > IBM already had CMS which uses human understandable commands like > "COPYFILE" "ERASE" and is pretty similar to MS-DOS in many > ways. However don't think even that doesn't well in 256K memory. some of the CTSS people https://en.wikipedia.org/wiki/Compatible_Time-Sharing_System went to the 5th flr and did Multics (some bell labs people were also involved, but then went back home a did unix ... billed as a simplified multics), others went to the science center on the 4th flr and did cp40/cms (on modified 256kbyte 360/40 with virtual memory hardware added), and then cp67/cms (when standard virtual memory 360/67 became available), GML, and bunch of other stuff. past posts http://www.garlic.com/~lynn/subtopic.html#545tech CP67/cms eventually morphs into vm370/cms (changing name of cambridge monitor system to conversational monitor system). for quite some time, default virtual memory size for cms was 256kbyte ... and originally cms would run on 256kbyte real 360 (w/o cp40 or cp67). before ms/dos http://en.wikipedia.org/wiki/MS-DOS there was seattle computer http://en.wikipedia.org/wiki/Seattle_Computer_Products before seattle computer there was cp/m, http://en.wikipedia.org/wiki/CP/M before doing cp/m, kildall worked with cp67/cms (precursor to vm370) at npg http://en.wikipedia.org/wiki/Naval_Postgraduate_School some cp67/cms ran on 256kbyte 360/67, but more typically 512kbyte or 768kbyte. cp67 kernel was getting a little bloated ... and i did modifications the summer of 1969 to make part of the cp67 kernel pageable ... reducing fixed real storage requirements, making it more efficient on smaller real memory machines (but never shipped in the standard cp67/cms to customers). Morph to vm370/cms simplified a bunch of cp67/cms and dropped many of the things I had done in the 60s ... but did pick up the pageable kernel changes ... however, other things bloated, so that it was only officially approved for minimum 512kbyte machines. For some 370/125 customers, I did do some of the additional cp67/cms pageable kernel changes that made it run better in 256kbyte machine. Les sent me paper copy of his cp40 presentation at 1982 SEAS that I scanned and converted to text http://www.garlic.com/~lynn/cp40seas1982.txt some wiki history with lots of refs: https://en.wikipedia.org/wiki/History_of_CP/CMS This is a little confused since IDC formed after NCSS by several people from MIT Lincoln Labs (which had been the 2nd cp67/cms installation after the science center, univ. I was at in the 60s was the 3rd) https://en.wikipedia.org/wiki/History_of_CP/CMS#1964.3F.E2.80.9372.3F:_IDC.27s_use_of_CP.2FCMS this references that I continued working on CP67 and then VM370 all during the Future System period (even ridiculing FS activity) and had two co-op students from BU helping. http://www.garlic.com/~lynn/2006v.html#email731212 http://www.garlic.com/~lynn/2006w.html#email750102 http://www.garlic.com/~lynn/2006w.html#email750430 After FS imploded http://www.garlic.com/~lynn/submain.html#futuresys and mad rush to get stuff back into 370 product pipeline contributed to decision to pick up a lot of the stuff that I had been doing and release in standard product ... except for CMS paged mapped filesystem some of the more complex stuff moving managing virtual memory, including moving additions vm370 data structures structures to paging store. One of the BU students graduates and joins IDC where he re-implements the page mapped filesystem, virtual memory management and moving VM370 kernel data structures to paging store. He also did added single system image cluster support and the ability to migrate running CMS users between loosely-coupled systems in cluster complex. This was in the days when IBM scheduled maintenance required taking systems offline ... migrating running users made it possibly to have 7x24 operations and non-disruptive take systems offline for maintenance. http://www.garlic.com/~lynn/submain.html#online both NCSS and IDC had quickly moved up value chain offering financial services. I've commented that IDC was briefly mentioned in Jan2009 when there was still the fiction that TARP funds were to buy "too big to fail" off-book toxic assets and IDC would help value those assets ... however, only $700B had been appropriated for TARP and just the four largest "too big to fail" were still carrying $5.2T at the end of 2008 (wasn't enough to buy at face value, almost enough to buy at the going rate of 22cents on the dollar, but then all those institutions would have to be declared insolvent and be liquidated). http://www.garlic.com/~lynn/submisc.html#too-big-to-fail http://www.garlic.com/~lynn/submisc.html#toxic.cdo some of the stuff mentioned done by NCSS for VP/CSS, I had already done for CP67/CMS as undergraduate at the univ. https://en.wikipedia.org/wiki/History_of_CP/CMS#1968.E2.80.9386.3F:_VP.2FCSS Summer of 1968, the science center gives a week cp67/cms class in Century City (california) which the univ. sends me to. Primary person to give CP67 classes gave notice the friday before that he was leaving to join NCSS. When I arrive on Sunday, science center asks me to give part of the cp67 class. another early virtual machine based online commercial service was Tymshare https://en.wikipedia.org/wiki/Tymshare in Aug1976, they make their CMS-based online computer conferencing systems free to (ibm user group) SHARE as VMSHARE ... archives http://vm.marist.edu/~vmshare -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | Anne & Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2016-02-14 12:01 -0800 |
| Message-ID | <87povzvz6i.fsf@garlic.com> |
| In reply to | #159368 |
from http://www.garlic.com/~lynn/2007u.html#18 Folklore references to CP67 at Lincoln Labs from Melinda's vm370 history http://www.leeandmelindavarian.com/Melinda/ footnote on 360/67 SLT instruction "The 360/67 SLT instruction RPQ was designed at Lincoln by Jack Nolan. He was interested in using it for database list processing. Once it was implemented, IBM found use for it to process lists in the CP nucleus. I don't know if it was ever used by TSS or for any applications program." (J.M. Winett, private communication, 1990.) ... snip ... footnotes on two cp67 commercial timesharing companies (Arnow was director of computing at Lincoln): Almost immediately after that, two "spinoff" companies were formed by former employees of Lincoln Lab, Union Carbide, and the IBM Cambridge Scientific Center, to provide commercial services based on CP/CMS. Dick Bayles, Mike Field, Hal Feinleib, and Bob Jay went to the company that became National CSS. Harit Nanavati, Bob Seawright, Jack Arnow, Frank Belvin, and Jim March went to IDC (Interactive Data Corporation). Although the loss of so many talented people was a blow, the CSC people felt that the success of the two new companies greatly increased the credibility of CP-67 ... snip ... Bob Seawright was from Union Carbide and his wife was IBM SE on the account, they both are assigned to Cambridge Science Center for CP67/CMS. Bob does a customized version os/360 for running in cp67 virtual machine ... somewhat CMS'ized with some cms-style commands and interactions at the os/360 "operetor's console". Disk Balyes, Mike Field, and Harit Nanavati were at science center. science center posts http://www.garlic.com/~lynn/subtopic.html#545tech cms originally could run on real 256kbyte 360/40 machine w/o cp/40 or cp/67. -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2016-02-14 08:48 -0700 |
| Message-ID | <2126338619.477155862.441446.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #159298 |
<hancock4@bbs.cpcn.com> wrote: > On Saturday, February 13, 2016 at 7:59:22 PM UTC-5, J. Clarke wrote: > > >> I have wondered what a building full of Z cores could do and wondered >> why IBM has never done it, but then I wondered why the PC wasn't based >> on the single-chip 360 that IBM demonstrated some time before. On the >> other hand, nobody ever accused MVS of being user-friendly and IBM would >> have never second-sourced the architecture. > > As for the PC chip, my understanding is that back in the 8088 days, > low powered chips were still quite expensive. Also, the 8088 architecture > initially was far simpler than S/360, and the original PC DOS was far > simpler than S/360-DOS. That is, to build a chip and supporting hardware > that could do everything S/360 could do would've added too much to the > original cost. Remember, floating point required an extra chip, and > initially, PC's maxed at 640K memory. It was later on that they added > all sorts of features. Microvax was two chips, and the Inter 432 was three. > > In addition, while I am weak on the internals, I _suspect_ the PC chip > was a better design for its application. Certainly, running a program > under PC-DOS and the C:> prompt was easier than coding a series of // EXEC > cards. This is confusing the hardware and the software. Even IBM never tried to run MVS on the XT/370. I still think VM wasn't the right OS for the general market, but IBM was aiming at developers. There were other OSs for 360/370. I've never used MTS, but I believe it was a simpler system to use, or something could have been hacked up cheaply on the base if VM with a better UI. That being said I think 360/370 architecture was probably more complex than the market was looking for, although Intel was too simple until the 486. > > I don't know the internals of the "Big Blue" machines vs. Z architecture. > My _guess_ is that Z is more intended to serve many users--thousands of > CICS terminals--while Big Blue is intended to focus on heavy number > crunching. I also guess that Big Blue can do math problems faster than Z. > -- Pete
[toc] | [prev] | [next] | [standalone]
| From | Dan Espen <despen@verizon.net> |
|---|---|
| Date | 2016-02-14 19:36 -0500 |
| Message-ID | <n9r6cc$avv$2@dont-email.me> |
| In reply to | #159352 |
Peter Flass <peter_flass@yahoo.com> writes: > <hancock4@bbs.cpcn.com> wrote: >> On Saturday, February 13, 2016 at 7:59:22 PM UTC-5, J. Clarke wrote: >> >> >>> I have wondered what a building full of Z cores could do and wondered >>> why IBM has never done it, but then I wondered why the PC wasn't based >>> on the single-chip 360 that IBM demonstrated some time before. On the >>> other hand, nobody ever accused MVS of being user-friendly and IBM would >>> have never second-sourced the architecture. >> >> As for the PC chip, my understanding is that back in the 8088 days, >> low powered chips were still quite expensive. Also, the 8088 architecture >> initially was far simpler than S/360, and the original PC DOS was far >> simpler than S/360-DOS. That is, to build a chip and supporting hardware >> that could do everything S/360 could do would've added too much to the >> original cost. Remember, floating point required an extra chip, and >> initially, PC's maxed at 640K memory. It was later on that they added >> all sorts of features. > > Microvax was two chips, and the Inter 432 was three. > >> >> In addition, while I am weak on the internals, I _suspect_ the PC chip >> was a better design for its application. Certainly, running a program >> under PC-DOS and the C:> prompt was easier than coding a series of // EXEC >> cards. > > This is confusing the hardware and the software. Even IBM never tried to > run MVS on the XT/370. I still think VM wasn't the right OS for the > general market, but IBM was aiming at developers. There were other OSs for > 360/370. I've never used MTS, but I believe it was a simpler system to > use, or something could have been hacked up cheaply on the base if VM with > a better UI. That being said I think 360/370 architecture was probably > more complex than the market was looking for, although Intel was too simple > until the 486. I've always regarded S/3x0 as simpler than Intel. I came to that conclusion looking at how Intel does screen I/O. A 3270 is seriously complicated but the dozens (or hundreds) of VGA modes are worse. IMO. -- Dan Espen
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2016-02-13 20:35 -0800 |
| Message-ID | <0575cfc6-c0ec-4050-92ce-12bdf969b481@googlegroups.com> |
| In reply to | #159272 |
On Saturday, February 13, 2016 at 3:17:31 PM UTC-7, hanc...@bbs.cpcn.com wrote:
> However, for "supercomputer" applications, I _guess_ that IBM no longer
> markets the Z series, but rather other products, like "Blue Blue". I find
> this curious since the Z series has enhanced instructions for doing number
> crunching, like several ways of floating point, 128 bit words, etc.
Well, its pricing - aimed at database users who are willing to pay the premium
- makes it unreasonable.
Decimal floating point of the type the System z has is also provided by the
POWER 8, if I remember correctly, and even x86 will let you do 128-bit floating-
point. The only thing System z has to itself is HFP, the traditional 360
format, and it's basically what *not* to use for number-crunching.
Of course, that makes it ideal for taking the same program, running it with HFP
instead of IEEE 478 ("BFP" in System z documentation), and if it gives a wildly
different answer, one might suspect the IEEE 478 answer is wrong too. I mean,
it would be nice if people knew how to do numerical analysis, but I don't think
I dare hold my breath.
John Savard
[toc] | [prev] | [next] | [standalone]
| From | Dan Espen <despen@verizon.net> |
|---|---|
| Date | 2016-02-14 10:15 -0500 |
| Message-ID | <n9q5ho$b4c$1@dont-email.me> |
| In reply to | #159265 |
Quadibloc <jsavard@ecn.ab.ca> writes: > I guess I wasn't clear what my point was. I meant that it also seemed > odd to me that they would neglect Fortran when they are updating C, > because I, at least, didn't view C as well suited to IBM mainframes > and their operating systems. > > John Savard Having worked on mainframe projects with tons of C code, I don't see much of a problem with C on a mainframe. You can even deal with packed decimal, but it doesn't seem worth the effort. -- Dan Espen
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2016-02-14 08:20 -0800 |
| Message-ID | <6c4fa351-95f0-4670-8eb8-7cb8e7e279d9@googlegroups.com> |
| In reply to | #159346 |
On Sunday, February 14, 2016 at 8:15:53 AM UTC-7, D_J_E wrote: > Having worked on mainframe projects with tons of C code, > I don't see much of a problem with C on a mainframe. > > You can even deal with packed decimal, but it doesn't seem > worth the effort. What I'm thinking of is that C's normal I/O library doesn't mesh well with the way IBM mainframes normally handle disk files - records aren't delimited, they have length indication instead. It's nothing that can't be easily taken care of - but then code for the IBM is not compatible with code for other machines. John Savard
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2016-02-14 14:31 -0600 |
| Message-ID | <n9qo1f$mna$1@dont-email.me> |
| In reply to | #159360 |
On 14-Feb-16 10:20, Quadibloc wrote: > On Sunday, February 14, 2016 at 8:15:53 AM UTC-7, D_J_E wrote: >> Having worked on mainframe projects with tons of C code, I don't >> see much of a problem with C on a mainframe. > > What I'm thinking of is that C's normal I/O library doesn't mesh well > with the way IBM mainframes normally handle disk files - records > aren't delimited, they have length indication instead. > > It's nothing that can't be easily taken care of - but then code for > the IBM is not compatible with code for other machines. The C Standard is careful to allow for such variations, and an equally careful programmer can write code that works on both. However, since virtually all other platforms these days are Unixish in that respect, few bother anymore. I occasionally see patches to OSS projects by folks tweaking IO calls and such so they'll work better on mainframes with no effect to how they work for other systems. Ditto for other "unusual" features, e.g. AS/400 and its segmented pointers. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Dan Espen <despen@verizon.net> |
|---|---|
| Date | 2016-02-14 19:33 -0500 |
| Message-ID | <n9r66h$avv$1@dont-email.me> |
| In reply to | #159360 |
Quadibloc <jsavard@ecn.ab.ca> writes: > On Sunday, February 14, 2016 at 8:15:53 AM UTC-7, D_J_E wrote: > >> Having worked on mainframe projects with tons of C code, >> I don't see much of a problem with C on a mainframe. >> >> You can even deal with packed decimal, but it doesn't seem >> worth the effort. > > What I'm thinking of is that C's normal I/O library doesn't mesh well with the > way IBM mainframes normally handle disk files - records aren't delimited, they > have length indication instead. > > It's nothing that can't be easily taken care of - but then code for the IBM is > not compatible with code for other machines. I/O has proven to be less of an issue than you might think. FB and VB files present a virtual new line at record boundaries. This works on input and output. But mainframes deal a lot with databases. C is fine with that. The hardest thing you might deal with is blank padding fixed length fields, and that's really nothing. -- Dan Espen
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2016-02-16 18:52 -0700 |
| Message-ID | <1035528687.477364983.729044.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #159395 |
Dan Espen <despen@verizon.net> wrote: > Quadibloc <jsavard@ecn.ab.ca> writes: > >> On Sunday, February 14, 2016 at 8:15:53 AM UTC-7, D_J_E wrote: >> >>> Having worked on mainframe projects with tons of C code, >>> I don't see much of a problem with C on a mainframe. >>> >>> You can even deal with packed decimal, but it doesn't seem >>> worth the effort. >> >> What I'm thinking of is that C's normal I/O library doesn't mesh well with the >> way IBM mainframes normally handle disk files - records aren't delimited, they >> have length indication instead. >> >> It's nothing that can't be easily taken care of - but then code for the IBM is >> not compatible with code for other machines. > > I/O has proven to be less of an issue than you might think. > FB and VB files present a virtual new line at record boundaries. > This works on input and output. > > But mainframes deal a lot with databases. > C is fine with that. The hardest thing you might deal with > is blank padding fixed length fields, and that's really nothing. > > But it's a very annoying nothing. -- Pete
[toc] | [prev] | [next] | [standalone]
| From | hancock4@bbs.cpcn.com |
|---|---|
| Date | 2016-02-13 14:04 -0800 |
| Message-ID | <beaadb0d-840d-4bc2-bf58-293c8510deab@googlegroups.com> |
| In reply to | #159257 |
On Saturday, February 13, 2016 at 2:31:57 PM UTC-5, Quadibloc wrote: > However, even IBM cannot escape the dominance of the C/C++ juggernaut, even > though that language is spectacularly ill-suited to the general programming it > is most often used for - as opposed to serving as a substitute for assembler, > which K&R C did admirably well. I don't know C. If it used as an assembler language, how does it handle machine specific situations such as word vs. character architectures, and different instruction sets*? Or is a C program still 'compiled' into a native low level language for the machine it is to run on. (I _think_ some folks here said C has replaced assembler in mainframe airline reservation systems.) *For example, the Z mainframe has a SQRT instruction now. Does the x86 have one?
[toc] | [prev] | [next] | [standalone]
| From | Morten Reistad <first@last.name,invalid> |
|---|---|
| Date | 2016-02-13 23:18 +0100 |
| Message-ID | <nmm4pc-iu4.ln1@sambook.reistad.name> |
| In reply to | #159270 |
In article <beaadb0d-840d-4bc2-bf58-293c8510deab@googlegroups.com>, <hancock4@bbs.cpcn.com> wrote: >On Saturday, February 13, 2016 at 2:31:57 PM UTC-5, Quadibloc wrote: > >> However, even IBM cannot escape the dominance of the C/C++ juggernaut, even >> though that language is spectacularly ill-suited to the general programming it >> is most often used for - as opposed to serving as a substitute for assembler, >> which K&R C did admirably well. > >I don't know C. If it used as an assembler language, how does it handle >machine specific situations such as word vs. character architectures, and >different instruction sets*? Or is a C program still 'compiled' into a >native low level language for the machine it is to run on. C is a reasonably standard procedural language; but it has all the trimmings needed to generate all the arithmetic and logical operations easily, and is pretty "close to the metal" in the logic. A loop could be for (i=0;i<100;i++) foo[i] = i*i; to make an array foo contain the square of the index in each element. This would be compiled to some pretty easily mapped intermediate representation, and then the ~100 optimisation techniques in the normal compiler would be applied to this code, sometimes resulting in the eventually emitted assembler would be pretty far removed from the original code. And sometimes not. -O0 -g3 -ggdb is the incarnation if you would like to turn the optimisation off, emit all the debug information and hooks to the debugger, -O6 -g0 or -Os -g0 would be max optimised for speed or size and no debug output. >(I _think_ some folks here said C has replaced assembler in mainframe >airline reservation systems.) > > >*For example, the Z mainframe has a SQRT instruction now. Does the x86 >have one? Not that I know of, nor that I care much. This is where C isolate you from the metal. I invoke result = sqrt(argument) ; and let the compiler, linker, loader and libraries sort it out. -- mrr Who use arm a lot more than x86, but who is sometimes confused about what architecture i am actually running on, even when compiling.
[toc] | [prev] | [next] | [standalone]
| From | "Osmium" <r124c4u102@comcast.net> |
|---|---|
| Date | 2016-02-13 17:25 -0600 |
| Message-ID | <di9sb4F1fk5U1@mid.individual.net> |
| In reply to | #159270 |
<hancock4@bbs.cpcn.com> wrote: > On Saturday, February 13, 2016 at 2:31:57 PM UTC-5, Quadibloc wrote: > >> However, even IBM cannot escape the dominance of the C/C++ juggernaut, >> even >> though that language is spectacularly ill-suited to the general >> programming it >> is most often used for - as opposed to serving as a substitute for >> assembler, >> which K&R C did admirably well. > > I don't know C. If it used as an assembler language, how does it handle > machine specific situations such as word vs. character architectures, and > different instruction sets*? Or is a C program still 'compiled' into a > native low level language for the machine it is to run on. > > (I _think_ some folks here said C has replaced assembler in mainframe > airline reservation systems.) You are being too literal. The mention of assembly language is used to indicate C is "close to the metal". It has bit fiddling and shifts. But it doesn't have arithmetic flags, such as overflow. Addressing assumes the world is made up of characters which have at least 8 bits. Any other data entity is created by compiler magic. Speaking of literal. The Attorney General of the US said, a couple days ago, that the powers that be in Ferguson, MO were literally breaking the backs of their black citizens with the usage of fines. I suppose she has some college so it must be OK to talk like that.
[toc] | [prev] | [next] | [standalone]
| From | "J. Clarke" <j.clarke.873638@gmail.com> |
|---|---|
| Date | 2016-02-13 19:42 -0500 |
| Message-ID | <MPG.3129977b37fcd5c0989f76@news.eternal-september.org> |
| In reply to | #159270 |
In article <beaadb0d-840d-4bc2-bf58-293c8510deab@googlegroups.com>, hancock4@bbs.cpcn.com says... > > On Saturday, February 13, 2016 at 2:31:57 PM UTC-5, Quadibloc wrote: > > > However, even IBM cannot escape the dominance of the C/C++ juggernaut, even > > though that language is spectacularly ill-suited to the general programming it > > is most often used for - as opposed to serving as a substitute for assembler, > > which K&R C did admirably well. > > I don't know C. If it used as an assembler language, how does it handle > machine specific situations such as word vs. character architectures, and > different instruction sets*? Or is a C program still 'compiled' into a > native low level language for the machine it is to run on. > > (I _think_ some folks here said C has replaced assembler in mainframe > airline reservation systems.) > > > *For example, the Z mainframe has a SQRT instruction now. Does the x86 > have one? C compiles to assembler or machine code. X86 has had SQRT since the '486. It had it before that but only in an add-on chip.
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2016-02-13 20:30 -0800 |
| Message-ID | <38c32ddf-336d-4e35-bace-74dae433bbd5@googlegroups.com> |
| In reply to | #159288 |
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_. Presumably it's because techniques such as the CORDIC algorithm allow hardware to do a much better job than a polynomial approximation. John Savard
[toc] | [prev] | [next] | [standalone]
| From | hancock4@bbs.cpcn.com |
|---|---|
| Date | 2016-02-13 21:49 -0800 |
| Message-ID | <041a7736-29e1-4e14-bf39-bec744cb3dcb@googlegroups.com> |
| In reply to | #159321 |
On Saturday, February 13, 2016 at 11:30:22 PM UTC-5, Quadibloc wrote: > 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_. In reading the IBM history, every new design was subject to debate and eventual tradeoffs for features/speed vs. cost. I suspect that adding the hardware to do trig functions on the 709x series simply would've cost too much to justify the higher selling price and computing time saved. As a reminder, some low-end machines back then didn't even have divide hardware, division was by in software. I was surprised when I learned that, but again, the cost of extra circuits likely didn't warrant the hardware. I do think some of the features in COBOL-for-MVS should've been offered about ten years earlier than it was. It would've helped speed development. As an aside, on bitsavers, I think in the 1401 section, is a detailed logic layout for the CPU--all the little AND, OR, and NOT gates. It is absolutely amazing that people could design this incredible complex stuff that would work accurately all the time; then translate all the logic plans into actual physical circuit cards. They made 10,000 of them.
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2016-02-14 06:36 -0800 |
| Message-ID | <2c27d589-0d96-49db-bc2c-7c4faccd41d9@googlegroups.com> |
| In reply to | #159329 |
On Saturday, February 13, 2016 at 10:49:42 PM UTC-7, hanc...@bbs.cpcn.com wrote: > As a reminder, some low-end machines back then didn't even have divide > hardware, division was by in software. Well, on many low-end machines, multiplication was done by software, although in many such cases one could get an optional add-on to do both multiplication and division in hardware. The Extended Arithmetic Element of the PDP-8 is a typical example. John Savard
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2016-02-14 08:48 -0700 |
| Message-ID | <974206744.477157047.323747.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #159341 |
Quadibloc <jsavard@ecn.ab.ca> wrote: > On Saturday, February 13, 2016 at 10:49:42 PM UTC-7, hanc...@bbs.cpcn.com wrote: > >> As a reminder, some low-end machines back then didn't even have divide >> hardware, division was by in software. > > Well, on many low-end machines, multiplication was done by software, although in > many such cases one could get an optional add-on to do both multiplication and > division in hardware. > > The Extended Arithmetic Element of the PDP-8 is a typical example. 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. > > John Savard > -- Pete
[toc] | [prev] | [next] | [standalone]
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
Back to top | Article view | alt.folklore.computers
csiph-web