Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #3564 > unrolled thread
| Started by | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| First post | 2011-06-26 15:13 -0500 |
| Last post | 2011-07-02 17:52 +0000 |
| Articles | 20 on this page of 328 — 44 participants |
Back to article view | Back to comp.lang.forth
The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-06-26 15:13 -0500
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-06-27 16:13 +0100
Re: The Lisp Curse vandys@vsta.org - 2011-06-27 15:50 +0000
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-06-27 16:55 +0100
Re: The Lisp Curse vandys@vsta.org - 2011-06-27 17:23 +0000
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-06-27 20:09 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-06-29 18:59 -0700
Re: The Lisp Curse Mark Wills <markrobertwills@yahoo.co.uk> - 2011-06-30 12:49 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-02 16:38 -0700
Re: The Lisp Curse Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-07-03 11:27 +0000
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-03 17:40 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-04 18:38 -0700
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-06-30 12:25 -0700
Forth OO ( was: Re: The Lisp Curse ) Doug Hoffman <glidedog@gmail.com> - 2011-07-12 09:43 -0400
Re: Forth OO ( was: Re: The Lisp Curse ) Doug Hoffman <glidedog@gmail.com> - 2011-07-12 12:35 -0400
Re: Forth OO ( was: Re: The Lisp Curse ) John Passaniti <john.passaniti@gmail.com> - 2011-07-13 10:02 -0700
Re: Forth OO ( was: Re: The Lisp Curse ) Doug Hoffman <glidedog@gmail.com> - 2011-07-14 08:32 -0400
Re: Forth OO ( was: Re: The Lisp Curse ) Alex McDonald <blog@rivadpm.com> - 2011-07-14 07:10 -0700
Re: Forth OO ( was: Re: The Lisp Curse ) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-14 09:31 -0500
Re: The Lisp Curse arc@vorsicht-bissig.de - 2011-07-12 22:20 -0700
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-13 10:01 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-28 03:02 -0400
Re: The Lisp Curse Elizabeth D Rather <erather@forth.com> - 2011-06-27 21:29 -1000
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-28 06:55 -0400
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-06-28 06:17 -0500
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-06-28 14:14 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-06-30 16:08 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-01 16:01 -0400
Re: The Lisp Curse Elizabeth D Rather <erather@forth.com> - 2011-07-01 13:41 -1000
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-04 21:18 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-05 02:26 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-02 16:56 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-02 08:28 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-02 17:00 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-03 10:20 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-04 20:57 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-06 15:45 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-06 16:19 -0700
Re: The Lisp Curse Josh Grams <josh@qualdan.com> - 2011-07-07 01:23 +0000
Re: The Lisp Curse "David N. Williams" <williams@umich.edu> - 2011-07-06 21:44 -0400
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-06 19:01 -0700
Re: The Lisp Curse Josh Grams <josh@qualdan.com> - 2011-07-07 10:39 +0000
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-07 13:07 -0700
Re: The Lisp Curse "David N. Williams" <williams@umich.edu> - 2011-07-06 21:42 -0400
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-07 10:32 +0100
Re: The Lisp Curse marko <marko@marko.marko.marko> - 2011-07-07 22:09 +1000
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-07 09:19 -0500
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-07 14:08 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-08 10:33 +0100
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-08 05:31 -0500
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-08 17:47 +0100
Re: The Lisp Curse vandys@vsta.org - 2011-07-08 17:23 +0000
Re: The Lisp Curse Spam@ControlQ.com - 2011-07-08 15:34 -0400
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-08 21:04 +0100
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-08 10:34 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-08 21:28 +0100
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-09 15:25 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-10 10:14 +0100
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-10 22:02 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-11 03:18 -0700
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-11 12:42 -0700
Re: The Lisp Curse Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-07-12 19:42 +0000
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-12 14:42 -0700
Re: The Lisp Curse Mark Wills <markrobertwills@yahoo.co.uk> - 2011-07-11 07:01 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-11 07:24 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-11 20:40 -0700
Re: The Lisp Curse Ron Aaron <rambamist@gmail.com> - 2011-07-11 21:24 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-12 18:54 -0700
Re: The Lisp Curse Ron Aaron <rambamist@gmail.com> - 2011-07-12 20:45 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-13 00:28 -0700
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-13 10:25 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-11 19:55 +0100
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-11 13:41 -0700
Re: The Lisp Curse Mark Wills <forthfreak@forthfiles.net> - 2011-07-11 13:45 -0700
Re: The Lisp Curse Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2011-07-12 21:51 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-09 16:49 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-11 04:27 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-07 14:53 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-28 11:57 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-29 21:54 -0700
Re: The Lisp Curse Julian Fondren <ayrnieu@gmail.com> - 2011-07-30 18:22 -0500
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-01 12:59 +0000
Re: The Lisp Curse Julian Fondren <ayrnieu@gmail.com> - 2011-08-02 00:07 -0500
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-01 22:58 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-08 20:44 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-31 10:25 +0100
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-08 16:00 -0700
Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-08-10 07:08 -1000
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-10 18:01 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-11 03:05 -0700
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-11 07:37 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-11 10:07 -0500
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-11 08:32 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-11 08:37 -0700
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-11 18:25 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-12 01:37 -0700
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-12 07:15 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-12 08:02 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-11 08:13 -0700
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-11 18:50 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-12 01:39 -0700
Re: The Lisp Curse arc <arc@vorsicht-bissig.de> - 2011-08-11 10:06 +0000
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-11 08:02 -0700
Re: The Lisp Curse arc <arc@vorsicht-bissig.de> - 2011-08-12 11:49 +0000
Re: The Lisp Curse arc <arc@vorsicht-bissig.de> - 2011-08-12 13:18 +0000
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-08-12 18:49 +0200
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-08-12 12:52 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-14 09:54 -0400
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-08-14 12:53 -0700
Re: The Lisp Curse Mark Wills <markrobertwills@yahoo.co.uk> - 2011-08-14 13:21 -0700
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-08-14 15:09 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-15 04:52 -0400
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-15 03:46 -0400
Re: The Lisp Curse Josh Grams <josh@qualdan.com> - 2011-08-15 12:15 +0000
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-08-15 20:51 +0200
Re: The Lisp Curse Josh Grams <josh@qualdan.com> - 2011-08-15 21:56 +0000
Re: The Lisp Curse "Jeff M." <massung@gmail.com> - 2011-08-15 19:50 -0700
Re: The Lisp Curse Mark Wills <markrobertwills@yahoo.co.uk> - 2011-08-16 03:07 -0700
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-08-18 23:45 -0700
Re: The Lisp Curse arc <arc@vorsicht-bissig.de> - 2011-08-18 11:38 +0000
Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-08-18 07:57 -1000
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-08-15 06:01 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-16 05:10 -0400
Re: The Lisp Curse Mark Wills <markrobertwills@yahoo.co.uk> - 2011-08-16 03:13 -0700
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-08-18 23:31 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-19 06:09 -0400
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-20 17:14 -0700
Re: The Lisp Curse "Jeff M." <massung@gmail.com> - 2011-08-20 20:38 -0700
Re: The Lisp Curse "Jeff M." <massung@gmail.com> - 2011-08-20 20:49 -0700
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-20 23:39 -0700
Re: The Lisp Curse "Jeff M." <massung@gmail.com> - 2011-08-21 00:29 -0700
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-21 00:57 -0700
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-21 01:04 -0700
Hamming numbers (was: The Lisp Curse) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-22 16:12 +0000
Re: The Lisp Curse Fritz Wuehler <fritz@spamexpire-201108.rodent.frell.theremailer.net> - 2011-08-21 13:21 +0200
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-21 10:40 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-21 13:56 -0400
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-21 12:33 -0700
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-21 12:42 -0700
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-21 13:30 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-22 12:49 -0400
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-23 10:20 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-23 20:15 -0400
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-24 00:13 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-21 13:41 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-22 11:48 -0400
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-22 10:36 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-22 22:57 -0400
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-22 23:28 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-23 04:16 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-23 08:29 -0500
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-23 14:59 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-23 20:12 -0400
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-23 20:09 -0400
Re: The Lisp Curse vandys@vsta.org - 2011-08-22 16:54 +0000
Re: The Lisp Curse Doug Hoffman <glidedog@gmail.com> - 2011-08-23 10:48 -0400
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-23 11:41 -0500
Re: The Lisp Curse vandys@vsta.org - 2011-08-23 17:11 +0000
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-23 12:27 -0500
Re: The Lisp Curse Brad <hwfwguy@gmail.com> - 2011-08-23 10:07 -0700
Re: The Lisp Curse Pablo Hugo Reda <pabloreda@gmail.com> - 2011-08-23 13:02 -0700
Re: The Lisp Curse vandys@vsta.org - 2011-08-23 20:30 +0000
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-21 13:49 -0400
Re: The Lisp Curse George Hubert <georgeahubert@yahoo.co.uk> - 2011-08-22 01:49 -0700
Re: The Lisp Curse vandys@vsta.org - 2011-08-22 17:02 +0000
Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-08-22 07:50 -1000
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-23 01:03 -0700
Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-08-22 22:38 -1000
Hamming numbers (was: The Lisp Curse) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-22 15:10 +0000
Re: Hamming numbers Paul Rubin <no.email@nospam.invalid> - 2011-08-23 00:09 -0700
Re: Hamming numbers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-23 13:09 +0000
Re: Hamming numbers Paul Rubin <no.email@nospam.invalid> - 2011-08-23 10:41 -0700
Re: Hamming numbers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-23 17:58 +0000
Re: Hamming numbers Paul Rubin <no.email@nospam.invalid> - 2011-08-24 00:25 -0700
Re: Hamming numbers Fritz Wuehler <fritz@spamexpire-201108.rodent.frell.theremailer.net> - 2011-08-24 07:17 +0200
Re: The Lisp Curse vandys@vsta.org - 2011-08-19 17:41 +0000
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-19 18:05 +0000
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-19 13:53 -0500
Re: The Lisp Curse Pablo Hugo Reda <pabloreda@gmail.com> - 2011-08-19 13:15 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-19 15:39 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-19 19:49 -0400
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-19 17:41 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-20 03:54 -0400
Re: The Lisp Curse Josh Grams <josh@qualdan.com> - 2011-08-20 15:20 +0000
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-21 14:41 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-22 11:47 -0400
Re: The Lisp Curse coos haak <chforth@hccnet.nl> - 2011-08-22 20:30 +0200
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-22 15:22 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-22 23:34 -0400
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-22 22:48 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-23 20:07 -0400
Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-08-23 15:44 -1000
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-23 21:43 -0700
Re: The Lisp Curse Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-08-20 08:55 +0000
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-12 10:49 -0700
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-13 14:03 +0000
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-14 07:57 -0700
Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-08-12 09:51 -1000
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-13 13:45 +0000
Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-08-13 08:08 -1000
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-08-14 02:56 +0200
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-13 04:35 -0500
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-12 07:53 -0700
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-13 14:13 +0000
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-13 13:59 -0700
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-14 14:46 +0000
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-17 01:31 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-06-28 03:24 -0500
Re: The Lisp Curse Fritz Wuehler <fritz@spamexpire-201106.rodent.frell.theremailer.net> - 2011-06-28 19:55 +0200
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-29 06:30 -0400
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-06-29 13:49 +0100
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-06-29 14:02 +0100
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-29 18:16 -0400
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-06-29 15:45 +0200
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-29 19:45 -0400
Re: The Lisp Curse Elko T <nono.black.elko@gmail.com> - 2011-06-29 22:08 -0400
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-30 10:07 -0400
Re: The Lisp Curse coos haak <chforth@hccnet.nl> - 2011-06-30 20:44 +0200
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-30 18:08 -0400
Counted vs. terminated strings (Re: The Lisp Curse) Elko T <nono.black.elko@gmail.com> - 2011-06-30 20:07 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) Elko T <nono.black.elko@gmail.com> - 2011-06-30 22:12 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-01 16:01 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) Elko T <nono.black.elko@gmail.com> - 2011-07-01 17:59 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) The Beez <the.beez.speaks@gmail.com> - 2011-07-01 16:33 -0700
Re: Counted vs. terminated strings (Re: The Lisp Curse) "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-02 18:37 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) kenney@cix.compulink.co.uk - 2011-07-01 06:07 -0500
Re: Counted vs. terminated strings (Re: The Lisp Curse) "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-01 16:00 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-01 14:06 +0000
Re: Counted vs. terminated strings (Re: The Lisp Curse) Elko T <nono.black.elko@gmail.com> - 2011-07-01 14:57 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-02 16:55 +0000
Re: Counted vs. terminated strings (Re: The Lisp Curse) "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-01 16:04 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) Alex McDonald <blog@rivadpm.com> - 2011-07-02 11:26 -0700
Re: Counted vs. terminated strings (Re: The Lisp Curse) coos haak <chforth@hccnet.nl> - 2011-07-02 22:10 +0200
Re: Counted vs. terminated strings (Re: The Lisp Curse) Alex McDonald <blog@rivadpm.com> - 2011-07-02 14:36 -0700
Re: Counted vs. terminated strings (Re: The Lisp Curse) Elko T <nono.black.elko@gmail.com> - 2011-07-02 21:36 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-02 18:25 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) Alex McDonald <blog@rivadpm.com> - 2011-07-03 10:53 -0700
Re: Counted vs. terminated strings (Re: The Lisp Curse) Elko T <nono.black.elko@gmail.com> - 2011-07-04 23:41 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) Alex McDonald <blog@rivadpm.com> - 2011-07-05 01:02 -0700
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-07-02 22:46 +0200
Re: The Lisp Curse David Thompson <dave.thompson2@verizon.net> - 2011-07-18 01:25 -0400
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-06-30 14:44 +0100
Re: The Lisp Curse Mark Wills <markrobertwills@yahoo.co.uk> - 2011-06-30 23:24 +0100
Re: The Lisp Curse Fritz Wuehler <fritz@spamexpire-201107.rodent.frell.theremailer.net> - 2011-07-03 12:04 +0200
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-03 20:24 -0400
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-04 02:21 -0700
Re: The Lisp Curse Fritz Wuehler <fritz@spamexpire-201107.rodent.frell.theremailer.net> - 2011-07-04 16:02 +0200
Re: The Lisp Curse Tarkin <tarkin000@gmail.com> - 2011-07-04 10:21 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-04 11:13 -0700
Re: The Lisp Curse Tarkin <tarkin000@gmail.com> - 2011-07-04 12:31 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-04 15:01 -0700
Re: The Lisp Curse Elizabeth D Rather <erather@forth.com> - 2011-07-04 13:23 -1000
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-05 01:45 -0700
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-05 11:34 +0000
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-05 05:34 -0700
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-05 14:28 +0000
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-05 09:39 -0700
OT: full virtualization (was: The Lisp Curse) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-07 15:36 +0000
Re: OT: full virtualization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-07 13:17 -0500
Re: OT: full virtualization Alex McDonald <blog@rivadpm.com> - 2011-07-08 04:53 -0700
Re: OT: full virtualization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-08 17:11 +0000
Re: OT: full virtualization Alex McDonald <blog@rivadpm.com> - 2011-07-08 12:41 -0700
Re: OT: full virtualization (was: The Lisp Curse) Alex McDonald <blog@rivadpm.com> - 2011-07-08 04:34 -0700
Re: OT: full virtualization (was: The Lisp Curse) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-10 16:03 +0000
Re: OT: full virtualization (was: The Lisp Curse) Alex McDonald <blog@rivadpm.com> - 2011-07-10 13:06 -0700
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-07-07 00:11 +0200
Re: The Lisp Curse Elizabeth D Rather <erather@forth.com> - 2011-07-06 12:47 -1000
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-07 10:07 +0000
Re: The Lisp Curse Tarkin <tarkin000@gmail.com> - 2011-07-07 13:00 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-04 12:40 -0500
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-04 11:15 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-04 15:53 -0500
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-07-05 10:16 +0200
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-05 02:23 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-05 09:54 -0500
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-07-05 22:33 +0200
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-05 16:28 -0500
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-05 16:18 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-04 15:03 -0400
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-07-05 00:20 +0200
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-05 11:35 -0400
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-05 09:46 -0700
Re: The Lisp Curse Fritz Wuehler <fritz@spamexpire-201107.rodent.frell.theremailer.net> - 2011-07-05 23:13 +0200
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-05 15:31 -0700
Re: The Lisp Curse kenney@cix.compulink.co.uk - 2011-07-07 04:38 -0500
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-05 19:21 -0500
Re: The Lisp Curse Elizabeth D Rather <erather@forth.com> - 2011-07-05 14:57 -1000
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-05 20:48 -0700
Re: The Lisp Curse BruceMcF <agila61@netscape.net> - 2011-07-06 07:38 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-06 09:46 -0500
Re: The Lisp Curse kenney@cix.compulink.co.uk - 2011-07-07 04:38 -0500
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-07 10:41 -0500
Re: The Lisp Curse BruceMcF <agila61@netscape.net> - 2011-07-07 09:12 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-06 09:53 -0500
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-07-06 21:45 +0200
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-07 14:48 -0400
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-07-07 20:20 +0100
Re: The Lisp Curse coos haak <chforth@hccnet.nl> - 2011-07-08 04:39 +0200
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-07-12 23:22 +0100
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-12 19:35 -0400
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-07-13 23:37 +0100
Re: The Lisp Curse Fritz Wuehler <fritz@spamexpire-201107.rodent.frell.theremailer.net> - 2011-07-12 05:10 +0200
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-12 03:44 -0500
Re: The Lisp Curse Fritz Wuehler <fritz@spamexpire-201107.rodent.frell.theremailer.net> - 2011-07-13 22:06 +0200
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-14 04:01 -0500
Re: The Lisp Curse kenney@cix.compulink.co.uk - 2011-07-07 04:38 -0500
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-03 07:34 -0500
Re: The Lisp Curse Spam@ControlQ.com - 2011-06-29 13:25 -0400
Forth as implementation language vandys@vsta.org - 2011-06-29 18:27 +0000
Re: Forth as implementation language Spam@ControlQ.com - 2011-06-29 17:50 -0400
Re: Forth as implementation language vandys@vsta.org - 2011-06-29 22:45 +0000
Re: Forth as implementation language Mark Wills <markrobertwills@yahoo.co.uk> - 2011-06-30 13:04 +0100
Re: Forth as implementation language Spam@ControlQ.com - 2011-06-30 11:42 -0400
Re: Forth as implementation language "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-30 13:12 -0400
Re: The Lisp Curse Elizabeth D Rather <erather@forth.com> - 2011-06-29 08:38 -1000
Re: The Lisp Curse Spam@ControlQ.com - 2011-06-29 18:01 -0400
Re: The Lisp Curse Elizabeth D Rather <erather@forth.com> - 2011-06-29 12:50 -1000
Re: The Lisp Curse stephenXXX@mpeforth.com (Stephen Pelc) - 2011-06-30 08:15 +0000
Re: The Lisp Curse Spam@ControlQ.com - 2011-07-03 15:22 -0400
Re: The Lisp Curse Mark Wills <markrobertwills@yahoo.co.uk> - 2011-06-30 13:09 +0100
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-29 18:31 -0400
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-06-29 23:01 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-01 09:42 -0500
Re: The Lisp Curse Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-07-01 18:49 +0000
Re: The Lisp Curse Mentifex <mentifex@myuw.net> - 2011-06-29 15:41 -0700
Re: The Lisp Curse "Fuschia, President-Elect of the Bright Purplish-Green Council" <fp-eotbp-gc@ibm.com> - 2011-06-29 19:16 -0400
Re: The Lisp Curse Mark Wills <forthfreak@forthfiles.net> - 2011-06-30 00:34 -0700
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-02 17:52 +0000
Page 13 of 17 — ← Prev page 1 … 11 12 [13] 14 15 … 17 Next page →
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2011-07-18 01:25 -0400 |
| Message-ID | <jng727di48hb1h89v0dup89oknjlo94tac@4ax.com> |
| In reply to | #3670 |
On Thu, 30 Jun 2011 10:07:29 -0400, "Rod Pemberton" <do_not_have@noavailemail.cmm> wrote: <snip: counted versus (null)terminated> > Actually, it seems, NN said "null terminated strings". I mistook that for > NUL-terminated strings. "Null terminated strings" are something else > entirely in the C context, nowadays. Null in C is not a character value > anymore. It was prior to ANSI standards. Modern C's null is a pointer. > So, no I don't like null terminated strings. > That's not a change. C since its beginning had null pointers (although only with porting and then standardization was it clear that null pointers must be typed, because the representation of different pointer types can vary) and also a null character. There is a standard macro NULL which provides a null pointer, but so does a literal 0 or (type*)0 or with C89 (void*)0. The character literal '\0' provides a null character, but so does a literal 0. The fact that null pointers and null characters can both be expressed as 0 does not and never did make them identical. > > Zero-terminated strings are the biggest drawback > > Zero-terminated might be perfectly valid description for NUL-terminated > strings for some languages. FYI, that's not so for C. > > In C, strings are not zero terminated. In C, zero is a value for an integer > or character. In C, strings are "all bits zero" terminated. This is a > "byte" in C, or multiple bytes, and not a character. Simply put, a C "byte" > is an address unit(s) as large, or larger, than a character's size in bits. A C 'byte' must be addressable (yes) and at least 8 bits and large enough to contain a character (yes) from a set whose minimum is defined by the standard and effectively requires at least 7 bits. A (normal/classic) string, that is a string of 'char' elements, each of which is exactly one byte, is terminated by exactly one byte of zero. Even if the implementation uses multibyte encodings for some characters, with UTF-8 as a prominent example, a single byte=char of 0 must always be a terminator. A 'wide' string, whose elements are wchar_t, is terminated by exactly one wchar_t of 0. wchar_t typically is 16 bits, which is 2 bytes on machines with 8-bit bytes -- which is nearly all, but the standard doesn't require (either of) these. A zero value of type char=byte or wchar_t is a zero. Perhaps in some sense this isn't a NUL character, although it converts to or from and compares equal to NUL, but it is definitely a zero, just like an int 0 is a zero and a float 0.0f is a zero. It is sometimes quite reasonable to have a sequence of int's terminated by an int 0, which _is_ a zero-terminated sequence or zero-delimited array, although not one built into the compiler like strings of char terminated by char 0. > If strings were zero terminated in C, an ASCII or EBCDIC NUL would suffice > to terminate the string. Syntactically, that's how you terminate strings in > C, you use a NUL character: '\0'. However, to comply with the C > specifications, C must clear the bits for the entire string terminator > "byte" with '\0', not just the bits used for the character. This is an > issue if C bytes and characters are of different sizes in bits. > True for '\0' because *every* character in C fills a byte. In char c; c = 'X'; 'X' is actually a value of at least a 16-bits (character literals have type int in C, and int must be at least 16-bits) and the store to c always stores all bits of that byte, even if 'X' would fit in 7 bits. memcpy memcmp etc. could not have worked otherwise, and from very early K&R1 until C89 those routines were defined in terms of char. (C89 made the _pointers_ void* for convenience, but continued to define the targets as char, specifically unsigned char.) For larger types like 'short' and 'int' C>=89 confirms storage can include padding bits, but not 'unsigned char', and practice has never allowed it for any 'char' type because many C programs have always assumed that accesses through any 'flavor' of char pointer can read and write all bits of memory (that can be read/written at all). <snip substantive points about counted versus terminated>
[toc] | [prev] | [next] | [standalone]
| From | Chris Hinsley <chris.hinsley@gmail.com> |
|---|---|
| Date | 2011-06-30 14:44 +0100 |
| Message-ID | <2011063014441245149-chrishinsley@gmailcom> |
| In reply to | #3657 |
> Has any operating system written in assembly been ported to > another platform? (No, or very few...) Taos/Intent. Ran on around 30 different CPU's, numorous hosted enviroments, and 10's of different customer platforms. But yes, it's not a common thing. And no doubt, people would argue that VP wasn't assembler, it was a compiled intermediate code you could hand code at the source level like an assembler. But I couldn't let your comment just go by. :) Chris
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markrobertwills@yahoo.co.uk> |
|---|---|
| Date | 2011-06-30 23:24 +0100 |
| Message-ID | <BYCdnW8bwO0papHTnZ2dnUVZ8tqdnZ2d@bt.com> |
| In reply to | #3669 |
On 30/06/2011 14:44, Chris Hinsley wrote: >> Has any operating system written in assembly been ported to >> another platform? (No, or very few...) > > Taos/Intent. Ran on around 30 different CPU's, numorous hosted > enviroments, and 10's of different customer platforms. > > But yes, it's not a common thing. And no doubt, people would argue that > VP wasn't assembler, it was a compiled intermediate code you could hand > code at the source level like an assembler. But I couldn't let your > comment just go by. :) > > Chris > Hmmmm.... Taos.... Swoon... ;-)
[toc] | [prev] | [next] | [standalone]
| From | Fritz Wuehler <fritz@spamexpire-201107.rodent.frell.theremailer.net> |
|---|---|
| Date | 2011-07-03 12:04 +0200 |
| Message-ID | <2746c0939d1a238ee58384acafc1b122@msgid.frell.theremailer.net> |
| In reply to | #3657 |
> > If you look at the IBM mainframe the operating system is written in > > assembler. > > Has any operating system written in assembly been ported to > another platform? (No, or very few...) Not important, especially in the case I am talking about, since the hardware and software were designed for each other. It doesn't make sense to port the OS and they have never needed to because the company that puts out the OS also designs and builds the hardware. You can be portable or optimized, but not both. IBM chose to optimize as much as possible and they did it by controlling the hardware and software as a unified package instead of making it run everywhere badly. > Has any operating system written in C been ported to > another platform? (Yes, many...) Many bad ones. Again, so what? > Assembly code "dies". It's affixed to the specific processor in use. I > learned that decades ago. Well I learned decades ago that the same assembler code that worked in 1964 still works today. That's almost 50 years. How much longer should the code live before your concern becomes invalid? > HLL code survives. Really? What about the guy who posted recently about his production Modula 2 code breaking and having no way to fix it? What about all the incompatbilities introduced by Intel and MS so that old code doesn't work anymore on those platforms? DOS code won't run on anything from NT and on...etc. Bottom line is more HLL code has been thrown away than assembler! > > All the header files and system calls are in assembler. If you > > want to use C on a mainframe you cannot physically write system > > code. At all > > "At all" is a bit of an extreme claim. No, it's simple fact. You cannot write system code in MVS in any language but assembler. Even if you could get mappings for system control blocks in other languages the code would quickly fall over because it doesn't have control over facilities that system code needs. > The GCCMVS project (Paul Edwards) ported GCC to MVS. I don't know much > about MVS, but I assume it was written in assembly. Before you said assembly was bad because it doesn't go cross platform but here you're giving an example of the most highly ported product out there, probably, and it's written in assembly at least enough of it to be able to be self bootstrapping or they would have needed to use an IBM licensed compiler to compile gcc which I'm sure Stallman and his groupies would never tolerate since IBM is evil and charges money and does so much closed source code. I looked into this the last time we talked about it. You don't understand what gccmvs is and what it's good for (not much) because you don't work in that environment. If you did you would realize how limited it is. First of all there is a much more capable C compiler out there from IBM with real libraries that give an MVS programmer the tools he needs to write useful application code and access a reasonable range of application facilities. Not nearly as much as COBOL or PL/I, but about as good as Java on MVS. gccmvs is missing basic things required for applications and doesn't have access to virtually anything a programmer needs in that environment, it's a special purpose tool, not a general purpose one. MVS is not POSIX. In Linux on MVS hardware gccmvs could be worthwhile, but I think regular gcc is already ported there. That brings us to the reason for gccmvs. The mainframe is not used by hobbyists because they're too expensive and the OS and software are expensive and no production shop uses GCCMVS, it's basically something Paul needed to do his updates to the public domain OS IBM from 1974. gccmvs has no system interface (it has very limited support for application interface) and it is not system code. They had to write wrappers to make it appear POSIX-like but it doesn't use IBM's POSIX facilities, because they were not available in 1974 and he needs his code to work backwards. The OS he is patching also doesn't have the underlying OS that does have POSIX support. It's basically a way to make a mainframe run C like on a PC, with some minor local modifications. If you are happy with printf etc. it might be enough for you. You cannot write system code in it, you can't do basic file system operations that the IBM C compiler supports, etc. It's a special purpose tool for hobbyists and that's it. Even IBM's C compiler has no support for writing systems software, and not their Metal C either. > So, it probably did what you claim cannot be done "at all". No, it didn't. Not even close. It just provides application wrappers to application level services. It does not go anywhere near systems services. Paul himself clearly says that in various yahoo groups posts I found. Windows and UNIX are so different from MVS and magnitudes less capable, so I'm not surprised there is no reference frame here for discussion. However most of the doc is online, if you have a couple free decades and want to see how it should be done, you can look! > DOS is also written in assembly. DJGPP (GCC port) for DOS does just what > you claim cannot be done. What does DOS do that I claim cannot be done? I have no idea what you are talking about. > Line-oriented BASIC was the only place GOTOs are needed. No. FORTRAN and COBOL also need them to have the code generated in an efficient way and used properly they increase readability dramatically. > As for C, there is no need for them whatsoever. http://www.kernel.org/pub/linux/docs/lkml/#s15-5 What you said is not true and goes against the original K&R where they explained when goto is appropriate in C. The Linux kernel developers use gotos heavily in the kernel, see above link. Now I realize goto's are almost never appropriate in C but you don't realize they are almost always appropriate in FORTRAN and COBOL. You have to know the language and use it idiomatically instead of trying to make everything a C program because if you do that with other languages the code doesn't look right and performance suffers alot. > There are problems with assembler: the code "dies", Not on the platform and OS I work on. > it's not as easily maintained Depends who you are and what code. I can maintain bad assembler alot better than I can maintain good C. YMMV. > and it's harder to use variables, struct's, etc. Maybe in your assembler(s) but not in ours. The assembler we use was designed for heavy duty use and has tons of features that make it as capable as any HLL including a native macro language that is almost an HLL itself. > Ada is a US Gov't requirement for some projects. Not for more than a decade. And what does that have to do with what we were discussing? > It's got assembly. It's got a half-dozen assemblers for it. NASM is a > decent assembler for it. yeah but then you still have to deal with Intel's abominable "architecture". The reason MVS is so nice for assembler developers is the OS is written in assembler and all the system interface is in assembler. We don't have to figure out idiotic C calling conventions designed for compiler back ends or look at header files in a foreign language, everything is designed around supporting the assembler programmer. The architecture is elegant, powerful and efficient. No horseshit libraries needed to do things like storage management (can you spell libc boys and girls?), everything is a documented application or system service. It comes with real manuals and real error messages, not stuff like ooops, sorry, etc. > > PL/I avoids the whole issue of buffer overruns on string operations > > since it knows the length of the source and target and will positively > > not blow off the end of a string. > > > > One disadvantage versus many ... Maybe but PL/I application code doesn't crash the system or cause integrity exposures and C code does. Every day of the week. > "... everything has a purpose or place ..." Psychologically, I'd guess your > MBTI type indicates you seek: harmony (NF) ... Ha, no. You missed that one. Assembler, FTW!
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@noavailemail.cmm> |
|---|---|
| Date | 2011-07-03 20:24 -0400 |
| Message-ID | <iur1a7$gad$1@speranza.aioe.org> |
| In reply to | #3737 |
"Fritz Wuehler" <fritz@spamexpire-201107.rodent.frell.theremailer.net> wrote in message news:2746c0939d1a238ee58384acafc1b122@msgid.frell.theremailer.net... Keep the headers please! I can't figure out which post(s) you were replying too. I wasn't sure it was me either... > > Assembly code "dies". It's affixed to the specific processor in use. I > > learned that decades ago. > > Well I learned decades ago that the same assembler code that worked in > 1964 still works today. That's almost 50 years. How much longer should > the code live before your concern becomes invalid? > If you're still operating ancient computing machine, then yes, it could. If a platform has lived that long, then yes, it could. What computing platform has lived that long? x86 is only 3 decades old. I think it's the longest lived platform, at least without changes to it's instruction set. I'm not aware of any computing platform pre-dating microprocessors that hasn't died. Even IBMs platforms have died or been changed substantially over time. Have they managed to keep their instruction set the same for 50 years? By "died", I mean that they are no longer in production, not that all produced machines are no longer functional. Once the platform has "died" the code requires a complete rewrite for a new platform. Recompiling code for HLLs on the other hand is frequently a nonevent. Yes, some code requires serious rework. It depends. Does my 6502 code still work? Yes, if I pull out and power up a collectible 6502 based machine assuming the machine didn't fail upon power-up. Are 6502s still used as the primary processor in a computing platform? Not as far as I'm aware. Are 6502s still in production? I don't know. I know that fast 6502 variants were produced until a decade or so ago for I/O coprocessors. So, the 6502 microprocessor and it's codebase is effectively dead as a computing platform. If I want my 6502 source code to work on x86, I have to rewrite, recode, or port it. Assembly code "dies". It's too dependent on the platform. > > HLL code survives. > > Really? What about the guy who posted recently about his > production Modula 2 > code breaking and having no way to fix it? Well, I don't recall seeing that. But, yes, some languages survive better than others. Are you sure GNU doesn't have a GCC front-end for it? It seems to have one for all the "trivial" HLLs, like Pascal. > What about all the incompatbilities > introduced by Intel and MS so that old code doesn't > work anymore on those > platforms? DOS code won't run on anything from > NT and on...etc. > Well, I'm far from sure about all of the details of what Windows does for DOS emulation. What I do understand is that under Windows, DOS is an emulation. Apparently, the emulation is usually a application called NTVDM that's basically DOS 5.0 with software traps/exceptions. It's some other application for Win98/SE/ME. There are limitations with more recent versions of Windows with their DOS emulation. I don't recall people saying NT was one of them. I recall them saying XP and later has various restrictions. From what I recall, people said 64-bit Win7 removed it completely. It's likely it uses x86's v86 cpu mode, at least on 32-bit Windows. For 64-bit x86, it's more complicated to get back to x86's RM to enable v86 mode. So, that was probably why it was removed. But, you can run other DOS emulators: DOSBOX, Bochs with FreeDOS image, probably MESS w/AT image and DOS, etc. You can also run real-mode DOS on the bare machine, e.g., BBS spec boot an external USB stick with DOS. > Bottom line is more HLL code has been thrown away than assembler! > Does DOS still have the largest collection of software for a single platform? I believe it still does... So, vice-versa... > > The GCCMVS project (Paul Edwards) ported GCC to MVS. I don't know much > > about MVS, but I assume it was written in assembly. > > Before you said assembly was bad because it doesn't go cross platform but > here you're giving an example of the most highly ported product out there, > probably, and it's written in assembly at least enough of it to be able to > be self bootstrapping or they would have needed to use an IBM licensed > compiler to compile gcc which I'm sure Stallman and his groupies would > never tolerate since IBM is evil and charges money and does so much > closed source code. > FYI. MVS is not copyrighted (apparently). The MVS OS is not ported, they run it an emulator. GCC license (apparently) allows use with non-GPL code. GLIBC license (apparently) doesn't allow use with non-GPL code. So, they use Paul Edwards's Public Domain C libary: PDPCLIB. > [GCCMVS] is basically a way to make a mainframe run C > like on a PC, with some minor local modifications. If you are happy > with printf etc. it might be enough for you. I've not used it. I figured someday I could try it in order to test if my C code worked with EBCDIC, or if I made some non-portable assumptions. This would be a better test if it were a good non-GCC compiler. > > DOS is also written in assembly. DJGPP (GCC port) for DOS does just what > > you claim cannot be done. > > What does DOS do that I claim cannot be done? I have no idea what you are > talking about. > I meant the claim of not being able to write system code on an OS coded in assembly, admittedly DOS is not run on a mainframe... System code isn't written in C, but could be, for DOS anyway. My personal (stalled, in-progress) OS for x86 is in C except for specialized x86 instructions. > > As for C, there is no need for them whatsoever. > > http://www.kernel.org/pub/linux/docs/lkml/#s15-5 > That's total BS. I can understand them not wanting to restructure the code properly. I can also understand them claiming that use of GOTOs ensures the OS is speedy, without them having to test their logic. That's probably part of the real reason. The real reason being: control and/or speed. They don't have to determine if some logic will exit properly. They know it'll exit, correctly or not, if it reaches a GOTO. > What you said is not true and goes against the original K&R where they > explained when goto is appropriate in C. Huh? Sorry, I never read K&R. I knew a bit of C before I bought mid-level and advanced books about it many years ago. I recall the K&R book "seemed thin" on content. I started basically with H&S "C: A Reference Manual", 3rd. I do have a .pdf, that may be of that book. Let me go take a look to see what you're talking about. It might be a more recent version than the original book: "3.8 Goto and labels C provides the infinitely-abusable goto statement, and labels to branch to. Formally, the goto statement is never necessary, and in practice it is almost always easy to write code without it. We have not used goto in this book. Nevertheless, there are a few situations where gotos may find a place. [snip examples] Code involving a goto can always be written without one, though perhaps at the price of some repeated tests or an extra variable. [snip example] With a few exceptions like those cited here, code that relies on goto statements is generally harder to understand and to maintain than code without gotos. Although we are not dogmatic about the matter, it does seem that goto statements should be used rarely, if at all. " Like I said, there's no point in using gotos with C... They've given some examples: 1) used to exit nested code This is unecessary: restructure the code, or use status flags, or setup a fall-through, or use different flow control. 2) use of labels Labels are unecessary in C code. They are there for ported or program generated code. 3) to avoid use of a status flag ... > Now I realize goto's are almost > never appropriate in C but you don't realize > they are almost always > appropriate in FORTRAN and COBOL. I never programmed COBOL. I hated FORTRAN. Two decades after the fact I'm supposed to remember FORTRAN had GOTOs? Unfortunately, I don't recall there being any GOTOs in FORTRAN... > > Ada is a US Gov't requirement for some projects. > > Not for more than a decade. And what does that have to do with what we > were discussing? > You didn't seem to know why a market for Ada programmers still exists, i.e., "... so there has to be some market ..." Maintaining Gov't software is one likely reason, .e.g., 100 year code lifetime... > yeah but then you still have to deal with Intel's abominable > "architecture". > So? It's got what you said you desired. Now, you're adding *more* constraints as to what you'll accept??? It seems you're rationalizing more reasons to not attempt to use it, ever. > The reason MVS is so nice for assembler developers is the OS is written in > assembler and all the system interface is in assembler. There are many OS projects for x86 written in assembler. Usually, the assembler based OS' for x86 don't seem to become as complete or as professional as OS' coded in C. They get the basics down and then stall. That could be due to complexity or that could be due to a lack of (skilled) x86 assembly programmers. I can only speculate. E.g., here is one example of an OS in C that was written from scratch: http://visopsys.org/ > We don't have to > figure out idiotic C calling conventions designed for compiler > back ends or look at header files in a foreign language, > everything is designed around > supporting the assembler programmer. Well then, try an assembly based OS for x86. > The architecture is elegant, powerful > and efficient. x86 can be setup in quite a variety of ways depending on what the OS designer needs. It can be fully open and clean, or it can be complicated, or it can use full security features, or it can use a wild mix of features. > No horseshit libraries needed to do things like storage > management (can you spell libc boys and girls?), You can do that without libc. Novices just don't understand how. And, it's not as flexible or guaranteed to be portable. Yes, there are some trivial language design mistakes in regards to memory allocation without libc, IMO. > Maybe but PL/I application code doesn't crash the system or cause > integrity exposures and C code does. Every day of the week. > You mean IBM PL/I on an IBM computing system... Now, it just happened the non-IBM PL/1 I programmed was for a fault tolerant system, so I don't know if the language itself had problems. I've not tried the reduce PL/I variants for an x86 PC. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2011-07-04 02:21 -0700 |
| Message-ID | <6a84b96f-a43d-4a48-ab10-7633511a1111@q1g2000vbj.googlegroups.com> |
| In reply to | #3766 |
On Jul 4, 1:24 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm> wrote: > "Fritz Wuehler" <fr...@spamexpire-201107.rodent.frell.theremailer.net> wrote > in messagenews:2746c0939d1a238ee58384acafc1b122@msgid.frell.theremailer.net... > > Keep the headers please! I can't figure out which post(s) you were replying > too. I wasn't sure it was me either... > > > > Assembly code "dies". It's affixed to the specific processor in use. I > > > learned that decades ago. > > > Well I learned decades ago that the same assembler code that worked in > > 1964 still works today. That's almost 50 years. How much longer should > > the code live before your concern becomes invalid? > > If you're still operating ancient computing machine, then yes, it could. If > a platform has lived that long, then yes, it could. What computing platform > has lived that long? x86 is only 3 decades old. I think it's the longest > lived platform, at least without changes to it's instruction set. Ah, the young of today. No sense of history ;-) > I'm not > aware of any computing platform pre-dating microprocessors that hasn't died. > Even IBMs platforms have died or been changed substantially over time. Have > they managed to keep their instruction set the same for 50 years? Yes. IBM's most modern machines (z Series) will still run code written in 1964. [rest snipped] Those who cannot remember the past are condemned to repeat it.
[toc] | [prev] | [next] | [standalone]
| From | Fritz Wuehler <fritz@spamexpire-201107.rodent.frell.theremailer.net> |
|---|---|
| Date | 2011-07-04 16:02 +0200 |
| Message-ID | <fbea4798d922ac758d0059ba4a6b1feb@msgid.frell.theremailer.net> |
| In reply to | #3766 |
> If you're still operating ancient computing machine, then yes, it could. If > a platform has lived that long, then yes, it could. What computing platform > has lived that long? System Z is the upward compatible system that exists today based on the System 360 from 1964. > x86 is only 3 decades old. I think it's the longest lived platform, at > least without changes to it's instruction set. Not even close. Object code from 1964 will run on today's IBM machines. Much source from those days will still compile and most of it will assemble. If it doesn't, you can almost always use an older version of a compiler or assembler and get anything written since then to run. > I'm not aware of any computing platform pre-dating microprocessors that > hasn't died. Now you are. It's the most widely used commercial data processing platform in the world, virtually all the Fortune 1000 companies have one or more of them running their enterprise workload. Until the mid 1980s it was *the* computer system the world ran on. It still is, but now it has company. > Even IBMs platforms have died or been changed substantially over time. Have > they managed to keep their instruction set the same for 50 years? By > "died", I mean that they are no longer in production, not that all produced > machines are no longer functional. Once the platform has "died" the code > requires a complete rewrite for a new platform. Recompiling code for HLLs > on the other hand is frequently a nonevent. Yes, some code requires serious > rework. It depends. Yes, they have kept the same instruction set for 50 years, of course it is now much bigger and has many more features, but none of the old design was removed. For example it still has 24 bit addressing, but it also has 64 bit (and 31 bit) addressing. It now has extra floating point registers for IEEE in addition to the original IBM floating point regs. All the instructions defined in the 1960's era manuals still work as stated. > Does my 6502 code still work? Yes, if I pull out and power up a collectible > 6502 based machine assuming the machine didn't fail upon power-up. Are > 6502s still used as the primary processor in a computing platform? Not as > far as I'm aware. Are 6502s still in production? I don't know. I know > that fast 6502 variants were produced until a decade or so ago for I/O > coprocessors. So, the 6502 microprocessor and it's codebase is effectively > dead as a computing platform. If I want my 6502 source code to work on x86, > I have to rewrite, recode, or port it. Assembly code "dies". It's too > dependent on the platform. Again, not in all cases! One of the most important cases from a commercial and technology viewpoint is IBM System Z. It is still being developed and sold, hardware is being updated and sold. It's IBM's flagship and it's amazing how little people who don't work on it know about it, considering how important it is. > Well, I don't recall seeing that. But, yes, some languages survive better > than others. Are you sure GNU doesn't have a GCC front-end for it? It > seems to have one for all the "trivial" HLLs, like Pascal. Hehe afaik, gcc was originally a Pascal compiler. Anyway there are several Modula 2 compilers around, just not one that can save the guy who is running production that now needs fixing, based on a specific compiler that is no longer maintained. That's just one case. My point is think of how many compilers and languages have come and gone, there is no guarantee any HLL code will live past the time the company who wrote the compiler goes out of business. > Does DOS still have the largest collection of software for a single I don't know, probably is close to Linux for the amount of freely available apps. > FYI. MVS is not copyrighted (apparently). The MVS OS is not ported, they > run it an emulator. GCC license (apparently) allows use with non-GPL code. > GLIBC license (apparently) doesn't allow use with non-GPL code. So, they > use Paul Edwards's Public Domain C libary: PDPCLIB. Ok, let's step back. MVS is licensed and copyrighted and covered under thousands if not tens of thousands of patents. The 1974 version that was released by IBM to the public domain was pre copyright (I heard US copyright law changed in 1980) and the specific one we are talking about in reference to what Paul is doing with gccmvs, MVS 3.8, is the only publicly available version. MVS does not use GPL code or gcc or anything to do with PDPCLIB. It was and is a pure IBM product and has IBM and third party compilers available for it. FYI, MVS is the generic name for all of the OS on the mainframe from 1964 to the present day. They call UNIX version this and UNIX version that, whereas IBM has changed the name of the OS to match the hardware level. But it's an evolution of the same OS which is why we still call it MVS (which was actually not the first version but I digress). Paul's work came much later and has nothing to do with IBM or MVS. He wants to take that publicly available 1974 version which uses 24 bit addressing and bring it up to the early 1990's when they had 31 bit addressing. I don't know why he chose to use C, but I do know there was no C compiler for IBM for the first decades, I don't know when it started because as I have been saying, C has never been a significant language on that platform. In the first 20 or 30 years, there was no C at all on mainframes. At some point IBM came out with their own compiler but again it has a full set of libraries to make application programming possible. pdpclib does not come close to providing that useful level of functionality. And all the IBM stuff is copyrighted, patented, licensed, and expensive. I can't make this point strongly enough, MVS doesn't need gcc, doesn't include gcc, and doesn't ship with any gpl code, and it never will. MVS has nothing to do with gcc. > I've not used it. I figured someday I could try it in order to test if my C > code worked with EBCDIC, or if I made some non-portable assumptions. > This would be a better test if it were a good non-GCC compiler. I have access to an IBM compiler, so if you need any code compiled post it somewhere and I'll run it for you. It's about 15 years old but that's still pretty new in IBM years. > I meant the claim of not being able to write system code on an OS coded in > assembly, admittedly DOS is not run on a mainframe... System code isn't > written in C, but could be, for DOS anyway. My personal (stalled, > in-progress) OS for x86 is in C except for specialized x86 instructions. I did not mean that at all. What I said is you cannot write system code in any language but assembler on the mainframe. That's just the way it is. That's not a theoretical argument and I only said it concerning the platform I know about. I did not think it applied to other platforms but I do know it's easier to write system code in C on UNIX because the OS is written in C with C interface and needs libc to do basic stuff. It's not an exact comparison because you can write system code in other languages (assembly) on NIX but it's harder because you have to create mappings. In the IBM environment it is simply impossible, not *only* because of the mappings and interface, but because of other issues that simply don't exist on other architectures. No other language available on IBM systems can support the requirements. Since Andy is trying to cut in with his new-found wikipedia knowledge, I am including PL/X variants when I say "assembler" because that's what they are. They aren't available outside of IBM (PL/X was, and I used it, but it is no longer available) so all system code written by vendors is written in assembler proper. It always has been. > 1) used to exit nested code > This is unecessary: restructure the code, or use status flags, or setup a > fall-through, or use different flow control. That's intellectual dishonesty. At the end of the day it's still a goto. If you can tolerate extra branches in your loop structures or have to define more switches to test just so you can say you avoided a goto, what have you really accomplished? > You didn't seem to know why a market for Ada programmers still exists, i.e., > "... so there has to be some market ..." Maintaining Gov't software is one > likely reason, .e.g., 100 year code lifetime... Oh, no, I understand why the market exists. I'm not sure why you thought I mean that. > > The reason MVS is so nice for assembler developers is the OS is written in > > assembler and all the system interface is in assembler. > > There are many OS projects for x86 written in assembler. Usually, the > assembler based OS' for x86 don't seem to become as complete or as > professional as OS' coded in C. They get the basics down and then stall. > That could be due to complexity or that could be due to a lack of (skilled) > x86 assembly programmers. I can only speculate. E.g., here is one example > of an OS in C that was written from scratch: > http://visopsys.org/ Ok but it doesn't matter. I'm talking about the most widely used, longest-lived influential OS of all time, it's not a toy OS, it's in production in tens of thousands of companies world wide. It's more professional than any UNIX or LINUX or Windows will ever live to be. It has complete, professional documentation sets, real error messages, real recovery, real resource management. It's the highest quality OS and programming environment you will never see. But you can see the doc if you want, it's online. > You can do that without libc. Novices just don't understand how. And, it's > not as flexible or guaranteed to be portable. Yes, there are some trivial > language design mistakes in regards to memory allocation without libc, > IMO. UNIX delegated application memory management to libc. It's a chickenshit "solution". How can you do malloc and free without libc? AFAIK you can't. You can set the break point but it doesn't free memory after you set it repeatedly, at least according to what I read. The more I learn about UNIX and LINUX the more I realize I was right to avoid learning them all these years, they're true crap. If I am wrong, please tell me how I can dynamically allocate and free storage for structures in assembly, or even discrete variables. I heard you have to write your own memory manager in UNIX/LINUX if you don't use libc. Didn't understand your comment about the posting headers. All mine should have a references header to make threading work (it does for me) but other headers are stipped by the mix system, nothing we can do about that.
[toc] | [prev] | [next] | [standalone]
| From | Tarkin <tarkin000@gmail.com> |
|---|---|
| Date | 2011-07-04 10:21 -0700 |
| Message-ID | <1edfeea4-578a-42ee-a7b7-7eaf7eae3814@y30g2000yqb.googlegroups.com> |
| In reply to | #3775 |
On Jul 4, 10:02 am, Fritz Wuehler <fr...@spamexpire-201107.rodent.frell.theremailer.net> wrote: > > If you're still operating ancient computing machine, then yes, it could. If > > a platform has lived that long, then yes, it could. What computing platform > > has lived that long? > > System Z is the upward compatible system that exists today based on the > System 360 from 1964. > Roughly the same span of time as the Fillet-o-fish.... > > x86 is only 3 decades old. I think it's the longest lived platform, at > > least without changes to it's instruction set. > > Not even close. Object code from 1964 will run on today's IBM machines. Much > source from those days will still compile and most of it will assemble. If > it doesn't, you can almost always use an older version of a compiler or > assembler and get anything written since then to run. > And, oddly enough, critics of the WinTel architecture usually use backwards compatability as a harsh criticism.... > > I'm not aware of any computing platform pre-dating microprocessors that > > hasn't died. > > Now you are. It's the most widely used commercial data processing platform > in the world, virtually all the Fortune 1000 companies have one or more of > them running their enterprise workload. Until the mid 1980s it was *the* > computer system the world ran on. It still is, but now it has company. > > > Even IBMs platforms have died or been changed substantially over time. Have > > they managed to keep their instruction set the same for 50 years? By > > "died", I mean that they are no longer in production, not that all produced > > machines are no longer functional. Once the platform has "died" the code > > requires a complete rewrite for a new platform. Recompiling code for HLLs > > on the other hand is frequently a nonevent. Yes, some code requires serious > > rework. It depends. > > Yes, they have kept the same instruction set for 50 years, of course it is > now much bigger and has many more features, but none of the old design was > removed. For example it still has 24 bit addressing, but it also has 64 bit > (and 31 bit) addressing. It now has extra floating point registers for IEEE > in addition to the original IBM floating point regs. All the instructions > defined in the 1960's era manuals still work as stated. > > > Does my 6502 code still work? Yes, if I pull out and power up a collectible > > 6502 based machine assuming the machine didn't fail upon power-up. Are > > 6502s still used as the primary processor in a computing platform? Not as > > far as I'm aware. Are 6502s still in production? I don't know. I know > > that fast 6502 variants were produced until a decade or so ago for I/O > > coprocessors. So, the 6502 microprocessor and it's codebase is effectively > > dead as a computing platform. If I want my 6502 source code to work on x86, > > I have to rewrite, recode, or port it. Assembly code "dies". It's too > > dependent on the platform. > > Again, not in all cases! One of the most important cases from a commercial > and technology viewpoint is IBM System Z. It is still being developed and > sold, hardware is being updated and sold. It's IBM's flagship and it's > amazing how little people who don't work on it know about it, considering > how important it is. > I'll restate one of your statements: "It's IBM's flagship and it's amazing how little people who don't work on it know about it, considering how important it is." snip dialogue about GCC,MVS, etc.... > > I meant the claim of not being able to write system code on an OS coded in > > assembly, admittedly DOS is not run on a mainframe... System code isn't > > written in C, but could be, for DOS anyway. My personal (stalled, > > in-progress) OS for x86 is in C except for specialized x86 instructions. > > I did not mean that at all. What I said is you cannot write system code in > any language but assembler on the mainframe. That's just the way it > is. That's not a theoretical argument and I only said it concerning the > platform I know about. I did not think it applied to other platforms but I > do know it's easier to write system code in C on UNIX because the OS is > written in C with C interface and needs libc to do basic stuff. It's not an > exact comparison because you can write system code in other languages > (assembly) on NIX but it's harder because you have to create mappings. In Not on LINUX. Kernel-level system calls use a register-based argument system. Programming in assembler on Linux is a breeze, for me. I'm guessing you're thinkg of BSD and derivatives, which almost requires the use of C-isms and stack frames and such. > the IBM environment it is simply impossible, not *only* because of the > mappings and interface, but because of other issues that simply don't exist > on other architectures. No other language available on IBM systems can > support the requirements. > This is a deliberate architectural design decision. IMO, one made to enforce vendor-lock in, requiring hefty licenses to make or sell third-party products, and keep the end-user dependant upon IBM. Profitable? Yes. Important? Perhaps to IBM's shareholders, and the shareholders of the companies that depend on IBM to run their 'enterprise'. > Since Andy is trying to cut in with his new-found wikipedia knowledge, I am > including PL/X variants when I say "assembler" because that's what they > are. They aren't available outside of IBM (PL/X was, and I used it, but it > is no longer available) so all system code written by vendors is written in > assembler proper. It always has been. > > > 1) used to exit nested code > > This is unecessary: restructure the code, or use status flags, or setup a > > fall-through, or use different flow control. > > That's intellectual dishonesty. At the end of the day it's still a goto. If > you can tolerate extra branches in your loop structures or have to define > more switches to test just so you can say you avoided a goto, what have you > really accomplished? > You omit code restructuring, which in most cases would obviate the need for goto; that's a shade of dishonesty, eh? > > You didn't seem to know why a market for Ada programmers still exists, i.e., > > "... so there has to be some market ..." Maintaining Gov't software is one > > likely reason, .e.g., 100 year code lifetime... > > Oh, no, I understand why the market exists. I'm not sure why you thought I > mean that. > > > > The reason MVS is so nice for assembler developers is the OS is written in > > > assembler and all the system interface is in assembler. > I hope you aware that some detractors of C consider it a glorified assembler... > > There are many OS projects for x86 written in assembler. Usually, the > > assembler based OS' for x86 don't seem to become as complete or as > > professional as OS' coded in C. They get the basics down and then stall. > > That could be due to complexity or that could be due to a lack of (skilled) > > x86 assembly programmers. I can only speculate. E.g., here is one example > > of an OS in C that was written from scratch: > >http://visopsys.org/ > > Ok but it doesn't matter. I'm talking about the most widely used, > longest-lived influential OS of all time, it's not a toy OS, it's in > production in tens of thousands of companies world wide. It's more > professional than any UNIX or LINUX or Windows will ever live to be. It has > complete, professional documentation sets, real error messages, real > recovery, real resource management. It's the highest quality OS and > programming environment you will never see. But you can see the doc if you > want, it's online. > That's a boatload of opinion you have there. Is there any scientific work being done with MVS/zSystem? When DARPA farmed out development of ARPANet, where were zSys/MVS? And, of course, what about one of Forth's earliest applications, Radio Telescope Astronomy? What did Lorenz discover his strange attractor on? Can zSys/MVS sequence the human, or, for that matter, _any_ genome? I opine that you have a tremendous amount of worship for what is essentially an overgrown Data Processing System, a kind of Incredible Hulk of a spreadsheet/database/timesharing system. Quaterly reports of sales of the McFlurry do not interest me. Please, enlighten me with something tremendous- control systems at CERN, digital imaging of the surface of Mars, adaptive learning networks....anything of real value to humanity? > > You can do that without libc. Novices just don't understand how. And, it's > > not as flexible or guaranteed to be portable. Yes, there are some trivial > > language design mistakes in regards to memory allocation without libc, > > IMO. > > UNIX delegated application memory management to libc. It's a chickenshit > "solution". How can you do malloc and free without libc? AFAIK you > can't. You can set the break point but it doesn't free memory after you set > it repeatedly, at least according to what I read. The more I learn about > UNIX and LINUX the more I realize I was right to avoid learning them all > these years, they're true crap. > Subjective. Though your pet may be able to track the sales of smart phones, a lot of them are running Android, which is Linux with some chrome.... > If I am wrong, please tell me how I can dynamically allocate and free > storage for structures in assembly, or even discrete variables. I heard you > have to write your own memory manager in UNIX/LINUX if you don't use libc. > Yes. A trivial programming exercise. So, tell yourself how you dynamically allocate and free storage structures in assembly: you write your own, using the s/brk system call, easily done in Linux; other *nices, YMMV <snipped stuff about headers> TTFN, Tarkin
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2011-07-04 11:13 -0700 |
| Message-ID | <4721e29d-e1b6-45b0-ba43-2f7820e6a386@g16g2000yqg.googlegroups.com> |
| In reply to | #3777 |
On Jul 4, 6:21 pm, Tarkin <tarkin...@gmail.com> wrote: > On Jul 4, 10:02 am, Fritz Wuehler > > <fr...@spamexpire-201107.rodent.frell.theremailer.net> wrote: > > > If you're still operating ancient computing machine, then yes, it could. If > > > a platform has lived that long, then yes, it could. What computing platform > > > has lived that long? > > > System Z is the upward compatible system that exists today based on the > > System 360 from 1964. > > Roughly the same span of time as the Fillet-o-fish.... > > > > x86 is only 3 decades old. I think it's the longest lived platform, at > > > least without changes to it's instruction set. > > > Not even close. Object code from 1964 will run on today's IBM machines. Much > > source from those days will still compile and most of it will assemble. If > > it doesn't, you can almost always use an older version of a compiler or > > assembler and get anything written since then to run. > > And, oddly enough, critics of the WinTel architecture usually use > backwards compatability as a harsh criticism.... > > > > > > > > > > > > I'm not aware of any computing platform pre-dating microprocessors that > > > hasn't died. > > > Now you are. It's the most widely used commercial data processing platform > > in the world, virtually all the Fortune 1000 companies have one or more of > > them running their enterprise workload. Until the mid 1980s it was *the* > > computer system the world ran on. It still is, but now it has company. > > > > Even IBMs platforms have died or been changed substantially over time. Have > > > they managed to keep their instruction set the same for 50 years? By > > > "died", I mean that they are no longer in production, not that all produced > > > machines are no longer functional. Once the platform has "died" the code > > > requires a complete rewrite for a new platform. Recompiling code for HLLs > > > on the other hand is frequently a nonevent. Yes, some code requires serious > > > rework. It depends. > > > Yes, they have kept the same instruction set for 50 years, of course it is > > now much bigger and has many more features, but none of the old design was > > removed. For example it still has 24 bit addressing, but it also has 64 bit > > (and 31 bit) addressing. It now has extra floating point registers for IEEE > > in addition to the original IBM floating point regs. All the instructions > > defined in the 1960's era manuals still work as stated. > > > > Does my 6502 code still work? Yes, if I pull out and power up a collectible > > > 6502 based machine assuming the machine didn't fail upon power-up. Are > > > 6502s still used as the primary processor in a computing platform? Not as > > > far as I'm aware. Are 6502s still in production? I don't know. I know > > > that fast 6502 variants were produced until a decade or so ago for I/O > > > coprocessors. So, the 6502 microprocessor and it's codebase is effectively > > > dead as a computing platform. If I want my 6502 source code to work on x86, > > > I have to rewrite, recode, or port it. Assembly code "dies". It's too > > > dependent on the platform. > > > Again, not in all cases! One of the most important cases from a commercial > > and technology viewpoint is IBM System Z. It is still being developed and > > sold, hardware is being updated and sold. It's IBM's flagship and it's > > amazing how little people who don't work on it know about it, considering > > how important it is. > > I'll restate one of your statements: > "It's IBM's flagship and it's amazing how little > people who don't work on it know about it, considering how important > it is." > > snip dialogue about GCC,MVS, etc.... > > > > I meant the claim of not being able to write system code on an OS coded in > > > assembly, admittedly DOS is not run on a mainframe... System code isn't > > > written in C, but could be, for DOS anyway. My personal (stalled, > > > in-progress) OS for x86 is in C except for specialized x86 instructions. > > > I did not mean that at all. What I said is you cannot write system code in > > any language but assembler on the mainframe. That's just the way it > > is. That's not a theoretical argument and I only said it concerning the > > platform I know about. I did not think it applied to other platforms but I > > do know it's easier to write system code in C on UNIX because the OS is > > written in C with C interface and needs libc to do basic stuff. It's not an > > exact comparison because you can write system code in other languages > > (assembly) on NIX but it's harder because you have to create mappings. In > > Not on LINUX. Kernel-level system calls use a register-based argument > system. Programming in assembler on Linux is a breeze, for me. > I'm guessing you're thinkg of BSD and derivatives, which almost > requires the use of C-isms and stack frames and such. > > > the IBM environment it is simply impossible, not *only* because of the > > mappings and interface, but because of other issues that simply don't exist > > on other architectures. No other language available on IBM systems can > > support the requirements. > > This is a deliberate architectural design decision. Evidence please. > IMO, one made > to enforce vendor-lock in, requiring hefty licenses to make or sell > third-party products, and keep the end-user dependant upon IBM. > Profitable? Yes. Important? Perhaps to IBM's shareholders, and > the shareholders of the companies that depend on IBM to run > their 'enterprise'. > > > Since Andy is trying to cut in with his new-found wikipedia knowledge, I am > > including PL/X variants when I say "assembler" because that's what they > > are. They aren't available outside of IBM (PL/X was, and I used it, but it > > is no longer available) so all system code written by vendors is written in > > assembler proper. It always has been. > > > > 1) used to exit nested code > > > This is unecessary: restructure the code, or use status flags, or setup a > > > fall-through, or use different flow control. > > > That's intellectual dishonesty. At the end of the day it's still a goto. If > > you can tolerate extra branches in your loop structures or have to define > > more switches to test just so you can say you avoided a goto, what have you > > really accomplished? > > You omit code restructuring, which in most cases would obviate the > need for > goto; that's a shade of dishonesty, eh? > > > > You didn't seem to know why a market for Ada programmers still exists, i.e., > > > "... so there has to be some market ..." Maintaining Gov't software is one > > > likely reason, .e.g., 100 year code lifetime... > > > Oh, no, I understand why the market exists. I'm not sure why you thought I > > mean that. > > > > > The reason MVS is so nice for assembler developers is the OS is written in > > > > assembler and all the system interface is in assembler. > > I hope you aware that some detractors of C consider it a glorified > assembler... > > > > > > > > > > > > There are many OS projects for x86 written in assembler. Usually, the > > > assembler based OS' for x86 don't seem to become as complete or as > > > professional as OS' coded in C. They get the basics down and then stall. > > > That could be due to complexity or that could be due to a lack of (skilled) > > > x86 assembly programmers. I can only speculate. E.g., here is one example > > > of an OS in C that was written from scratch: > > >http://visopsys.org/ > > > Ok but it doesn't matter. I'm talking about the most widely used, > > longest-lived influential OS of all time, it's not a toy OS, it's in > > production in tens of thousands of companies world wide. It's more > > professional than any UNIX or LINUX or Windows will ever live to be. It has > > complete, professional documentation sets, real error messages, real > > recovery, real resource management. It's the highest quality OS and > > programming environment you will never see. But you can see the doc if you > > want, it's online. > > That's a boatload of opinion you have there. Is there any scientific > work being > done with MVS/zSystem? When DARPA farmed out development of > ARPANet, where were zSys/MVS? And, of course, what about one of > Forth's earliest applications, Radio Telescope Astronomy? What did > Lorenz discover his strange attractor on? Can zSys/MVS sequence > the human, or, for that matter, _any_ genome? > > I opine that you have a tremendous amount of worship for what > is essentially an overgrown Data Processing System, a kind of > Incredible Hulk of a spreadsheet/database/timesharing system. Spreadsheets? Do you even know what you're talking about? > > Quaterly reports of sales of the McFlurry do not interest me. > Please, enlighten me with something tremendous- control > systems at CERN, digital imaging of the surface of Mars, > adaptive learning networks....anything of real value to humanity? Your bank account. Boring, yes, but of real value if you have one. Or work on nuclear power simulations. Boring, yes, but of real value if you happen to own one. Or large scale weather simulations. Is there weather where you are? One of the real strengths of an IBM mainframe system is the amount of data it can move around. Cray systems were often fed IO by IBM mainframes; they were the only processors that could keep up. > > > > You can do that without libc. Novices just don't understand how. And, it's > > > not as flexible or guaranteed to be portable. Yes, there are some trivial > > > language design mistakes in regards to memory allocation without libc, > > > IMO. > > > UNIX delegated application memory management to libc. It's a chickenshit > > "solution". How can you do malloc and free without libc? AFAIK you > > can't. You can set the break point but it doesn't free memory after you set > > it repeatedly, at least according to what I read. The more I learn about > > UNIX and LINUX the more I realize I was right to avoid learning them all > > these years, they're true crap. > > Subjective. Though your pet may be able to track the sales of smart > phones, > a lot of them are running Android, which is Linux with some chrome.... > > > If I am wrong, please tell me how I can dynamically allocate and free > > storage for structures in assembly, or even discrete variables. I heard you > > have to write your own memory manager in UNIX/LINUX if you don't use libc. > > Yes. A trivial programming exercise. So, tell yourself how you > dynamically > allocate and free storage structures in assembly: you write your own, > using the s/brk system call, easily done in Linux; other *nices, YMMV > > <snipped stuff about headers> > > TTFN, > Tarkin That's a whole boatload of opinion there.
[toc] | [prev] | [next] | [standalone]
| From | Tarkin <tarkin000@gmail.com> |
|---|---|
| Date | 2011-07-04 12:31 -0700 |
| Message-ID | <08501fd9-ca7c-4841-9e4d-319d9d0a8058@o4g2000vbv.googlegroups.com> |
| In reply to | #3780 |
On Jul 4, 2:13 pm, Alex McDonald <b...@rivadpm.com> wrote: > On Jul 4, 6:21 pm, Tarkin <tarkin...@gmail.com> wrote: > > > On Jul 4, 10:02 am, Fritz Wuehler > > > <fr...@spamexpire-201107.rodent.frell.theremailer.net> wrote: > > > > If you're still operating ancient computing machine, then yes, it could. If > > > > a platform has lived that long, then yes, it could. What computing platform > > > > has lived that long? > > > > System Z is the upward compatible system that exists today based on the > > > System 360 from 1964. > > > Roughly the same span of time as the Fillet-o-fish.... > > > > > x86 is only 3 decades old. I think it's the longest lived platform, at > > > > least without changes to it's instruction set. > > > > Not even close. Object code from 1964 will run on today's IBM machines. Much > > > source from those days will still compile and most of it will assemble. If > > > it doesn't, you can almost always use an older version of a compiler or > > > assembler and get anything written since then to run. > > > And, oddly enough, critics of the WinTel architecture usually use > > backwards compatability as a harsh criticism.... > > > > > I'm not aware of any computing platform pre-dating microprocessors that > > > > hasn't died. > > > > Now you are. It's the most widely used commercial data processing platform > > > in the world, virtually all the Fortune 1000 companies have one or more of > > > them running their enterprise workload. Until the mid 1980s it was *the* > > > computer system the world ran on. It still is, but now it has company. > > > > > Even IBMs platforms have died or been changed substantially over time. Have > > > > they managed to keep their instruction set the same for 50 years? By > > > > "died", I mean that they are no longer in production, not that all produced > > > > machines are no longer functional. Once the platform has "died" the code > > > > requires a complete rewrite for a new platform. Recompiling code for HLLs > > > > on the other hand is frequently a nonevent. Yes, some code requires serious > > > > rework. It depends. > > > > Yes, they have kept the same instruction set for 50 years, of course it is > > > now much bigger and has many more features, but none of the old design was > > > removed. For example it still has 24 bit addressing, but it also has 64 bit > > > (and 31 bit) addressing. It now has extra floating point registers for IEEE > > > in addition to the original IBM floating point regs. All the instructions > > > defined in the 1960's era manuals still work as stated. > > > > > Does my 6502 code still work? Yes, if I pull out and power up a collectible > > > > 6502 based machine assuming the machine didn't fail upon power-up. Are > > > > 6502s still used as the primary processor in a computing platform? Not as > > > > far as I'm aware. Are 6502s still in production? I don't know. I know > > > > that fast 6502 variants were produced until a decade or so ago for I/O > > > > coprocessors. So, the 6502 microprocessor and it's codebase is effectively > > > > dead as a computing platform. If I want my 6502 source code to work on x86, > > > > I have to rewrite, recode, or port it. Assembly code "dies". It's too > > > > dependent on the platform. > > > > Again, not in all cases! One of the most important cases from a commercial > > > and technology viewpoint is IBM System Z. It is still being developed and > > > sold, hardware is being updated and sold. It's IBM's flagship and it's > > > amazing how little people who don't work on it know about it, considering > > > how important it is. > > > I'll restate one of your statements: > > "It's IBM's flagship and it's amazing how little > > people who don't work on it know about it, considering how important > > it is." > > > snip dialogue about GCC,MVS, etc.... > > > > > I meant the claim of not being able to write system code on an OS coded in > > > > assembly, admittedly DOS is not run on a mainframe... System code isn't > > > > written in C, but could be, for DOS anyway. My personal (stalled, > > > > in-progress) OS for x86 is in C except for specialized x86 instructions. > > > > I did not mean that at all. What I said is you cannot write system code in > > > any language but assembler on the mainframe. That's just the way it > > > is. That's not a theoretical argument and I only said it concerning the > > > platform I know about. I did not think it applied to other platforms but I > > > do know it's easier to write system code in C on UNIX because the OS is > > > written in C with C interface and needs libc to do basic stuff. It's not an > > > exact comparison because you can write system code in other languages > > > (assembly) on NIX but it's harder because you have to create mappings. In > > > Not on LINUX. Kernel-level system calls use a register-based argument > > system. Programming in assembler on Linux is a breeze, for me. > > I'm guessing you're thinkg of BSD and derivatives, which almost > > requires the use of C-isms and stack frames and such. > > > > the IBM environment it is simply impossible, not *only* because of the > > > mappings and interface, but because of other issues that simply don't exist > > > on other architectures. No other language available on IBM systems can > > > support the requirements. > > > This is a deliberate architectural design decision. > > Evidence please. Evidence to the contrary, please. > > > IMO, one made > > to enforce vendor-lock in, requiring hefty licenses to make or sell > > third-party products, and keep the end-user dependant upon IBM. > > Profitable? Yes. Important? Perhaps to IBM's shareholders, and > > the shareholders of the companies that depend on IBM to run > > their 'enterprise'. > > > > Since Andy is trying to cut in with his new-found wikipedia knowledge, I am > > > including PL/X variants when I say "assembler" because that's what they > > > are. They aren't available outside of IBM (PL/X was, and I used it, but it > > > is no longer available) so all system code written by vendors is written in > > > assembler proper. It always has been. > > > > > 1) used to exit nested code > > > > This is unecessary: restructure the code, or use status flags, or setup a > > > > fall-through, or use different flow control. > > > > That's intellectual dishonesty. At the end of the day it's still a goto. If > > > you can tolerate extra branches in your loop structures or have to define > > > more switches to test just so you can say you avoided a goto, what have you > > > really accomplished? > > > You omit code restructuring, which in most cases would obviate the > > need for > > goto; that's a shade of dishonesty, eh? > > > > > You didn't seem to know why a market for Ada programmers still exists, i.e., > > > > "... so there has to be some market ..." Maintaining Gov't software is one > > > > likely reason, .e.g., 100 year code lifetime... > > > > Oh, no, I understand why the market exists. I'm not sure why you thought I > > > mean that. > > > > > > The reason MVS is so nice for assembler developers is the OS is written in > > > > > assembler and all the system interface is in assembler. > > > I hope you aware that some detractors of C consider it a glorified > > assembler... > > > > > There are many OS projects for x86 written in assembler. Usually, the > > > > assembler based OS' for x86 don't seem to become as complete or as > > > > professional as OS' coded in C. They get the basics down and then stall. > > > > That could be due to complexity or that could be due to a lack of (skilled) > > > > x86 assembly programmers. I can only speculate. E.g., here is one example > > > > of an OS in C that was written from scratch: > > > >http://visopsys.org/ > > > > Ok but it doesn't matter. I'm talking about the most widely used, > > > longest-lived influential OS of all time, it's not a toy OS, it's in > > > production in tens of thousands of companies world wide. It's more > > > professional than any UNIX or LINUX or Windows will ever live to be. It has > > > complete, professional documentation sets, real error messages, real > > > recovery, real resource management. It's the highest quality OS and > > > programming environment you will never see. But you can see the doc if you > > > want, it's online. > > > That's a boatload of opinion you have there. Is there any scientific > > work being > > done with MVS/zSystem? When DARPA farmed out development of > > ARPANet, where were zSys/MVS? And, of course, what about one of > > Forth's earliest applications, Radio Telescope Astronomy? What did > > Lorenz discover his strange attractor on? Can zSys/MVS sequence > > the human, or, for that matter, _any_ genome? > > > I opine that you have a tremendous amount of worship for what > > is essentially an overgrown Data Processing System, a kind of > > Incredible Hulk of a spreadsheet/database/timesharing system. > > Spreadsheets? Do you even know what you're talking about? I mismatched metaphors there, perhaps. An overgrown spreadsheet. I am curious as to why you decline to opine on any appearances of MVS / zSys at places / times of notable innovation and paradigm-shifting discovery. > > Quaterly reports of sales of the McFlurry do not interest me. > > Please, enlighten me with something tremendous- control > > systems at CERN, digital imaging of the surface of Mars, > > adaptive learning networks....anything of real value to humanity? > > Your bank account. Boring, yes, but of real value if you have one. Or > work on nuclear power simulations. Boring, yes, but of real value if > you happen to own one. Or large scale weather simulations. Is there > weather where you are? One of the real strengths of an IBM mainframe > system is the amount of data it can move around. Cray systems were > often fed IO by IBM mainframes; they were the only processors that > could keep up. Towards the end there, you expose what I consider what a mainframe's strength is: I/O. So, it seems there is something that we can agree upon. Nuclear simulations? A quick search turns up US D.o.E. / ANL, so, I'll eat crow on that one. But let's look at performance: ( http://www.ne.anl.gov/codes/mc2-2/ ) "A 1740-group consistent P1 homogeneous twelve-isotope problem with 27 broad groups requires about 6.5 minutes of CPU time on an IBM 370/195. The same problem requires approximately 30% less time on the CDC 7600 and approximately 50% less time on the RS6000 and the SS20 SUN systems." Hehe. You want to model atomic particles and nuclear forces? Ok, use an IBM solution. You want to manipulate those forces...check out what CERN is using.... Yes, there is weather where I am. Any source for statitistics regarding accurate predictions? I'm prepared to pleasantly surprised, but my gut tells me they wouldn't be much better than the Farmer's Almanac. > > > > You can do that without libc. Novices just don't understand how. And, it's > > > > not as flexible or guaranteed to be portable. Yes, there are some trivial > > > > language design mistakes in regards to memory allocation without libc, > > > > IMO. > > > > UNIX delegated application memory management to libc. It's a chickenshit > > > "solution". How can you do malloc and free without libc? AFAIK you > > > can't. You can set the break point but it doesn't free memory after you set > > > it repeatedly, at least according to what I read. The more I learn about > > > UNIX and LINUX the more I realize I was right to avoid learning them all > > > these years, they're true crap. > > > Subjective. Though your pet may be able to track the sales of smart > > phones, > > a lot of them are running Android, which is Linux with some chrome.... > > > > If I am wrong, please tell me how I can dynamically allocate and free > > > storage for structures in assembly, or even discrete variables. I heard you > > > have to write your own memory manager in UNIX/LINUX if you don't use libc. > > > Yes. A trivial programming exercise. So, tell yourself how you > > dynamically > > allocate and free storage structures in assembly: you write your own, > > using the s/brk system call, easily done in Linux; other *nices, YMMV > > > <snipped stuff about headers> > > > TTFN, > > Tarkin > > That's a whole boatload of opinion there. It's my experience one tends to get what one gives. Don't be too proud of this technological terror that IBM has constructed; the power to issue my bank statement is insigificant next to the power of smashing hadrons together. http://accelconf.web.cern.ch/accelconf/ica05/proceedings/pdf/I1_001.pdf TTFN, Tarkin
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2011-07-04 15:01 -0700 |
| Message-ID | <0c3e34e6-dfaa-4d2c-8a1a-78b91fdeedc8@d1g2000yqm.googlegroups.com> |
| In reply to | #3783 |
On Jul 4, 8:31 pm, Tarkin <tarkin...@gmail.com> wrote: > On Jul 4, 2:13 pm, Alex McDonald <b...@rivadpm.com> wrote: > > > On Jul 4, 6:21 pm, Tarkin <tarkin...@gmail.com> wrote: > > > > On Jul 4, 10:02 am, Fritz Wuehler > > > > <fr...@spamexpire-201107.rodent.frell.theremailer.net> wrote: [some snipped] > > > > > the IBM environment it is simply impossible, not *only* because of the > > > > mappings and interface, but because of other issues that simply don't exist > > > > on other architectures. No other language available on IBM systems can > > > > support the requirements. > > > > This is a deliberate architectural design decision. > > > Evidence please. > > Evidence to the contrary, please. > No, you made the statement. Support it with evidence. [more snippage] > > > > That's a boatload of opinion you have there. Is there any scientific > > > work being > > > done with MVS/zSystem? When DARPA farmed out development of > > > ARPANet, where were zSys/MVS? And, of course, what about one of > > > Forth's earliest applications, Radio Telescope Astronomy? What did > > > Lorenz discover his strange attractor on? Can zSys/MVS sequence > > > the human, or, for that matter, _any_ genome? > > > > I opine that you have a tremendous amount of worship for what > > > is essentially an overgrown Data Processing System, a kind of > > > Incredible Hulk of a spreadsheet/database/timesharing system. > > > Spreadsheets? Do you even know what you're talking about? > > I mismatched metaphors there, perhaps. > An overgrown spreadsheet. > I am curious as to why you decline to opine on any appearances of > MVS / zSys at places / times of notable innovation and > paradigm-shifting discovery. I see you're impressed by whizz-bangs. The 360 was the most significant computing architecture ever introduced. In no particular order; . The 8-bit byte, with byte-addressable memory and 32-bit words . First commercial microcoded CPU . Floating point; the IEEE 754-1985 floating-point standard took 20 years to arrive . Paging, virtual memory, segmentation, instruction pipelining, memory protection, unburstable security... A z series can stay on its feet for years, with no downtime while major components are replaced or upgraded. It was VM ready from day 1; something most computers couldn't claim. The Intel line of x86 chips couldn't do VMs until 1985, and only then very badly. Solaris couldn't do VMs until 2004. The IBM 360/370/390/z series been at the heart of computing for 5 decades, and ahead of the pack for most of that time. > > > > Quaterly reports of sales of the McFlurry do not interest me. > > > Please, enlighten me with something tremendous- control > > > systems at CERN, digital imaging of the surface of Mars, > > > adaptive learning networks....anything of real value to humanity? > > > Your bank account. Boring, yes, but of real value if you have one. Or > > work on nuclear power simulations. Boring, yes, but of real value if > > you happen to own one. Or large scale weather simulations. Is there > > weather where you are? One of the real strengths of an IBM mainframe > > system is the amount of data it can move around. Cray systems were > > often fed IO by IBM mainframes; they were the only processors that > > could keep up. > > Towards the end there, you expose what I consider what a mainframe's > strength is: I/O. So, it seems there is something that we can agree > upon. > Nuclear simulations? A quick search turns up US D.o.E. / ANL, so, > I'll eat crow on that one. > > But let's look at performance: > (http://www.ne.anl.gov/codes/mc2-2/) > "A 1740-group consistent P1 homogeneous twelve-isotope problem with 27 > broad groups requires about 6.5 minutes of CPU time on an IBM 370/195. > The same problem requires approximately 30% less time on the CDC 7600 > and approximately 50% less time on the RS6000 and the SS20 SUN > systems." > > Hehe. 370/195? CDC 7600? That's ancient history. The 1970s; before you were even a twinkle in your daddy's eye. > > You want to model atomic particles and nuclear forces? Ok, use > an IBM solution. You want to manipulate those forces...check > out what CERN is using.... > > Yes, there is weather where I am. Any source for statitistics > regarding > accurate predictions? I'm prepared to pleasantly surprised, but my gut > tells me they wouldn't be much better than the Farmer's Almanac. Now that's remarkably silly, since I suspect what you know about weather modelling consists of deciding to wear a coat when it rains. [more snipped] > > > That's a whole boatload of opinion there. > > It's my experience one tends to get what one gives. > Don't be too proud of this technological terror that IBM > has constructed; the power to issue my bank statement > is insigificant next to the power of smashing hadrons > together.http://accelconf.web.cern.ch/accelconf/ica05/proceedings/pdf/I1_001.pdf O get real. Computers don't smash atoms together. > > TTFN, > Tarkin
[toc] | [prev] | [next] | [standalone]
| From | Elizabeth D Rather <erather@forth.com> |
|---|---|
| Date | 2011-07-04 13:23 -1000 |
| Message-ID | <FrWdnYrx7sAN1o_TnZ2dnUVZ_vOdnZ2d@supernews.com> |
| In reply to | #3787 |
On 7/4/11 12:01 PM, Alex McDonald wrote:
> On Jul 4, 8:31 pm, Tarkin<tarkin...@gmail.com> wrote:
...
>> But let's look at performance:
>> (http://www.ne.anl.gov/codes/mc2-2/)
>> "A 1740-group consistent P1 homogeneous twelve-isotope problem with 27
>> broad groups requires about 6.5 minutes of CPU time on an IBM 370/195.
>> The same problem requires approximately 30% less time on the CDC 7600
>> and approximately 50% less time on the RS6000 and the SS20 SUN
>> systems."
>>
>> Hehe.
>
> 370/195? CDC 7600? That's ancient history. The 1970s; before you were
> even a twinkle in your daddy's eye.
You laugh. I programmed all those! And some of their predecessors.
>> You want to model atomic particles and nuclear forces? Ok, use
>> an IBM solution. You want to manipulate those forces...check
>> out what CERN is using....
>>
>> Yes, there is weather where I am. Any source for statitistics
>> regarding
>> accurate predictions? I'm prepared to pleasantly surprised, but my gut
>> tells me they wouldn't be much better than the Farmer's Almanac.
>
> Now that's remarkably silly, since I suspect what you know about
> weather modelling consists of deciding to wear a coat when it rains.
Should you want to look at some of the source code, it's available for
one of the models here:
http://www.mcs.anl.gov/~michalak/B/mpmm_index.html
Among the features of the latest release, I note:
"5. Optimized routines to ensure faster run times. The new routines
especially improve run times on IBM computers. In order to give
users a choice, both the optimized and original code are available.
6. New Cray X1 and INTEL compiler flags are added."
>>
>>> That's a whole boatload of opinion there.
>>
>> It's my experience one tends to get what one gives.
>> Don't be too proud of this technological terror that IBM
>> has constructed; the power to issue my bank statement
>> is insigificant next to the power of smashing hadrons
>> together.http://accelconf.web.cern.ch/accelconf/ica05/proceedings/pdf/I1_001.pdf
>
> O get real. Computers don't smash atoms together.
Wanna bet? How do you think they control every aspect of the operation
of a supercollider? From the link above, there's a list of the
computers used for this purpose, including:
"The VME Front End Computers: 350 VME computers are being added to the
existing 300 crates already existing for the PS Complex and SPS, to deal
with high performance acquisitions and real-time processing. They house
a large variety of commercial or CERN-made I/O modules. These FECs run
either the same LynxOS real-time operating system as those of the PS and
of the SPS or Red Hat Linux. Mostly they are diskless to increase
reliability and they boot over the network. Typically, the LHC beam
instrumentation and the LHC beam interlock systems use VME front-ends."
Then there are more *categories* of front- and back-end computers
listed, including industrial PC front ends and PLC back ends.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2011-07-05 01:45 -0700 |
| Message-ID | <ba7e19c1-8ddb-4bf5-b263-7b26f1d28286@s17g2000yqs.googlegroups.com> |
| In reply to | #3790 |
On Jul 5, 12:23 am, Elizabeth D Rather <erat...@forth.com> wrote: > On 7/4/11 12:01 PM, Alex McDonald wrote: > > > On Jul 4, 8:31 pm, Tarkin<tarkin...@gmail.com> wrote: > ... > >> But let's look at performance: > >> (http://www.ne.anl.gov/codes/mc2-2/) > >> "A 1740-group consistent P1 homogeneous twelve-isotope problem with 27 > >> broad groups requires about 6.5 minutes of CPU time on an IBM 370/195. > >> The same problem requires approximately 30% less time on the CDC 7600 > >> and approximately 50% less time on the RS6000 and the SS20 SUN > >> systems." > > >> Hehe. > > > 370/195? CDC 7600? That's ancient history. The 1970s; before you were > > even a twinkle in your daddy's eye. > > You laugh. I programmed all those! And some of their predecessors. Dear Lord, don't tell me you've morphed into Tarkin. You'll increase the ire of Aguilar; now you're a moving target (and possibly a cross dressing target too, something he'll have apoplexy about). IBM 1401. I was in my early teens and fascinated to the point of obsession by computers; I still am. My bible at the time was a copy of Scientific American, and on the cover was an owl made up of Honeywell computer parts. I must have read and re-read that edition -- it was thick, over 1/2inch of paper -- a hundred times or more, especially the article on natural language recognition. It got lost in a house move. I'd love to know what year it was and get my hands on a copy again; I think it was some time in the late 60s/very early 70s. In 1973/4, the computing club at the school I was at won nearly unlimited time on Edinburgh Uni's mainframe to run a simulator we'd designed, on an OS (EMAS), both written entirely in IMP, an Algol-like language. That also led to meeting and being seriously impressed by Donald Michie, but I was persuaded to take a wrong turn on leaving school and I didn't do CS and AI there as I should have done. My one big regret. But then, I wouldn't have met my wife, and so on... I got back into computing a few years later; IBM systems programming, amongst other jobs. Now I don't program for a living, but I've got one of the coolest tech jobs on the planet. 35 years in the IT business, and a lot of it spent promoting innovation. Life, as they say, is good. > > >> You want to model atomic particles and nuclear forces? Ok, use > >> an IBM solution. You want to manipulate those forces...check > >> out what CERN is using.... > > >> Yes, there is weather where I am. Any source for statitistics > >> regarding > >> accurate predictions? I'm prepared to pleasantly surprised, but my gut > >> tells me they wouldn't be much better than the Farmer's Almanac. > > > Now that's remarkably silly, since I suspect what you know about > > weather modelling consists of deciding to wear a coat when it rains. > > Should you want to look at some of the source code, it's available for > one of the models here:http://www.mcs.anl.gov/~michalak/B/mpmm_index.html > > Among the features of the latest release, I note: > "5. Optimized routines to ensure faster run times. The new routines > especially improve run times on IBM computers. In order to give > users a choice, both the optimized and original code are available. > > 6. New Cray X1 and INTEL compiler flags are added." > > > > >>> That's a whole boatload of opinion there. > > >> It's my experience one tends to get what one gives. > >> Don't be too proud of this technological terror that IBM > >> has constructed; the power to issue my bank statement > >> is insigificant next to the power of smashing hadrons > >> together.http://accelconf.web.cern.ch/accelconf/ica05/proceedings/pdf/I1_001.pdf > > > O get real. Computers don't smash atoms together. > > Wanna bet? How do you think they control every aspect of the operation > of a supercollider? From the link above, there's a list of the > computers used for this purpose, including: > > "The VME Front End Computers: 350 VME computers are being added to the > existing 300 crates already existing for the PS Complex and SPS, to deal > with high performance acquisitions and real-time processing. They house > a large variety of commercial or CERN-made I/O modules. These FECs run > either the same LynxOS real-time operating system as those of the PS and > of the SPS or Red Hat Linux. Mostly they are diskless to increase > reliability and they boot over the network. Typically, the LHC beam > instrumentation and the LHC beam interlock systems use VME front-ends." > > Then there are more *categories* of front- and back-end computers > listed, including industrial PC front ends and PLC back ends. And unless hadrons know a thing or two about computers, like Tarkin they will be blissfully unaware. Yes, computers manage the process. I was being picky about Tarkin's assertion that "the power to issue my bank statement is insigificant [sic] next to the power of smashing hadrons" as though there's some kind of hammer wielding uber-processor with a virtual anvil making the sparks fly. One of the major issues CERN face is data and processing of data; they're producing huge amounts of it (20PB a year and growing if I have the numbers right). Management of the front end pales into insignificance by comparison with that task. (And no, I'm not claiming that IBM mainframes do the data crunching. It just that the sexy bits -- smashing hadrons -- isn't really where the innovation is happening.) > > Cheers, > Elizabeth > > -- > ================================================== > Elizabeth D. Rather (US & Canada) 800-55-FORTH > FORTH Inc. +1 310.999.6784 > 5959 West Century Blvd. Suite 700 > Los Angeles, CA 90045http://www.forth.com > > "Forth-based products and Services for real-time > applications since 1973." > ==================================================
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-07-05 11:34 +0000 |
| Message-ID | <2011Jul5.133434@mips.complang.tuwien.ac.at> |
| In reply to | #3787 |
Alex McDonald <blog@rivadpm.com> writes:
>I see you're impressed by whizz-bangs. The 360 was the most
>significant computing architecture ever introduced. In no particular
>order;
>
>. The 8-bit byte, with byte-addressable memory and 32-bit words
Yes.
>. First commercial microcoded CPU
Possibly. Related, and More important: the concept of an
(instruction-set) architecture independent of the implementation.
>. Floating point; the IEEE 754-1985 floating-point standard took 20
>years to arrive
No. Floating point hardware had been available on many computer
systems before, including systems from IBM (e.g., the IBM 704). The
IBM 360 FP format is quite nasty and not at all influential.
>. Paging, virtual memory, segmentation, instruction pipelining, memory
>protection, unburstable security...
No. Not only did the IBM System/360 not pioneer these, it did not have
them. Exception: the 360/67, introduced 1967, had virtual memory; but
in general virtual memory is associated with the 370 family, although
even there it was not included at first; and the /91 had pipelining
and out-of-order execution with (and that's a first) register
renaming.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2011: http://www.euroforth.org/ef11/
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2011-07-05 05:34 -0700 |
| Message-ID | <20803bfa-6d51-4c45-9e6e-719b18ab099a@hd10g2000vbb.googlegroups.com> |
| In reply to | #3804 |
On Jul 5, 12:34 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > Alex McDonald <b...@rivadpm.com> writes: > >I see you're impressed by whizz-bangs. The 360 was the most > >significant computing architecture ever introduced. In no particular > >order; > > >. The 8-bit byte, with byte-addressable memory and 32-bit words > > Yes. Well, see below, since I wasn't claiming a first. IBM/STRETCH introduced the 8bit byte. > > >. First commercial microcoded CPU > > Possibly. Related, and More important: the concept of an > (instruction-set) architecture independent of the implementation. > > >. Floating point; the IEEE 754-1985 floating-point standard took 20 > >years to arrive > > No. Floating point hardware had been available on many computer > systems before, including systems from IBM (e.g., the IBM 704). The > IBM 360 FP format is quite nasty and not at all influential. I'll agree violently with the nasty. It was horrible. > > >. Paging, virtual memory, segmentation, instruction pipelining, memory > >protection, unburstable security... > > No. Not only did the IBM System/360 not pioneer these, it did not have > them. Exception: the 360/67, introduced 1967, had virtual memory; but > in general virtual memory is associated with the 370 family, although > even there it was not included at first; and the /91 had pipelining > and out-of-order execution with (and that's a first) register > renaming. Atlas was the first (1959); the 360/60 and /65 (1965) with DAT predated the /67, but not by much. I'll repeat; the 360 was the most significant computing architecture ever introduced. I was clear on the "first"; I don't claim any firsts except for microcode. 50 years is a long time, and the extended innovation with backward compatibility over that period is truly remarkable. > > - anton > -- > M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html > comp.lang.forth FAQs:http://www.complang.tuwien.ac.at/forth/faq/toc.html > New standard:http://www.forth200x.org/forth200x.html > EuroForth 2011:http://www.euroforth.org/ef11/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-07-05 14:28 +0000 |
| Message-ID | <2011Jul5.162811@mips.complang.tuwien.ac.at> |
| In reply to | #3806 |
Alex McDonald <blog@rivadpm.com> writes:
>On Jul 5, 12:34=A0pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>wrote:
>> Alex McDonald <b...@rivadpm.com> writes:
>> >I see you're impressed by whizz-bangs. The 360 was the most
>> >significant computing architecture ever introduced. In no particular
>> >order;
>>
>> >. The 8-bit byte, with byte-addressable memory and 32-bit words
>>
>> Yes.
>
>Well, see below, since I wasn't claiming a first. IBM/STRETCH
>introduced the 8bit byte.
In the Stretch, 8-bit bytes were just one possible byte size among
several (1 to 8 bits); it's unclear from the Wikipedia page how
addressing worked in the Stretch, but given the varying byte sizes, it
is unlikely to have had byte-addressed memory.
So byte-addressed memory appears to habe originated with the IBM 360
(see also the thread in comp.arch).
One trait that has not taken over the world is big-endian byte order.
One trait it shares with even more modern machines than byte
addressability is 2's-complement arithmetic.
>I'll repeat; the 360 was the most significant computing architecture
>ever introduced.
By what measure of significance?
Sure, in the two aspects mentioned above it's the first modern
machine, so we can say that all the world's an IBM 360. But somehow
the saying (or complaint) is "All the world's a VAX".
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2011: http://www.euroforth.org/ef11/
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2011-07-05 09:39 -0700 |
| Message-ID | <9703cc62-3c3c-4903-8902-06d09bdb0650@u42g2000yqm.googlegroups.com> |
| In reply to | #3809 |
On Jul 5, 3:28 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > Alex McDonald <b...@rivadpm.com> writes: > >On Jul 5, 12:34=A0pm, an...@mips.complang.tuwien.ac.at (Anton Ertl) > >wrote: > >> Alex McDonald <b...@rivadpm.com> writes: > >> >I see you're impressed by whizz-bangs. The 360 was the most > >> >significant computing architecture ever introduced. In no particular > >> >order; > > >> >. The 8-bit byte, with byte-addressable memory and 32-bit words > > >> Yes. > > >Well, see below, since I wasn't claiming a first. IBM/STRETCH > >introduced the 8bit byte. > > In the Stretch, 8-bit bytes were just one possible byte size among > several (1 to 8 bits); it's unclear from the Wikipedia page how > addressing worked in the Stretch, but given the varying byte sizes, it > is unlikely to have had byte-addressed memory. > > So byte-addressed memory appears to habe originated with the IBM 360 > (see also the thread in comp.arch). I followed it with some interest when the post started; but that I missed. I'll reread. > > One trait that has not taken over the world is big-endian byte order. Or EBCDIC. > > One trait it shares with even more modern machines than byte > addressability is 2's-complement arithmetic. > > >I'll repeat; the 360 was the most significant computing architecture > >ever introduced. > > By what measure of significance? Well, given that it has some features that no other architecture has; a 50 year lifespan (give or take a few years). I'd also add in full virtualization capability, Popek/Goldberg complete, and here I'm thinking of VM/CP and CP-40 etc, and ok, it needed a 360/67 or better; but the significance of this can't IMHO be understated. It took others until, what, 2000 and onwards to accomplish this; Intel didn't "get it" until 2005. > > Sure, in the two aspects mentioned above it's the first modern > machine, so we can say that all the world's an IBM 360. But somehow > the saying (or complaint) is "All the world's a VAX". No, that's a statement too far for the wrong platforms. A goodly proportion of the world thinks everything is (and this is my complaint) Intel shaped. > > - anton > -- > M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html > comp.lang.forth FAQs:http://www.complang.tuwien.ac.at/forth/faq/toc.html > New standard:http://www.forth200x.org/forth200x.html > EuroForth 2011:http://www.euroforth.org/ef11/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-07-07 15:36 +0000 |
| Subject | OT: full virtualization (was: The Lisp Curse) |
| Message-ID | <2011Jul7.173621@mips.complang.tuwien.ac.at> |
| In reply to | #3813 |
Alex McDonald <blog@rivadpm.com> writes:
>I'd also add in full
>virtualization capability, Popek/Goldberg complete, and here I'm
>thinking of VM/CP and CP-40 etc, and ok, it needed a 360/67 or better;
>but the significance of this can't IMHO be understated. It took others
>until, what, 2000 and onwards to accomplish this; Intel didn't "get
>it" until 2005.
Sure it can be understated: Saying that it has no significance would
be an understatement, but not by much.
The usefulness of full virtualization on the later IBM 370s has to do with
the software (especially OS) environment that the 370 inherited from
the 360, and that was enriched with additional OSs that supported the
new features; it also has to do with the I/O architecture of the 360.
Full virtualization is much less useful in other environments, so the
hardware support for that was not implemented for a long time. I
remember a comp.arch discussion (from long ago) where someone asked
why Intel Processors did not have support for full virtualization, and
an Intel architect answered that there was not enough customer demand
for it, and gave reasons why.
Still, eventually there was customer demand for these kinds of virtual
machines, and VMware implemented full virtualization without hardware
support through binary translation. Then Intel and AMD added the
missing bits, so the binary translation solution is no longer
necessary.
However, in the environment on the Intel/AMD-based machines, even with
hardware support full virtualization is relatively slow: e.g., I/O
works through multiple instructions storing to memory-mapped I/O or
I/O ports; the hypervisor has to interpret that and translate it to
the corresponding commands on the actual hardware (doing any other
translation it needs to do).
Therefore, paravirtualization is preferred: The guest OS knows it is
being run in a virtual machine environment and communicates directly
with the hypervisor, asking it in a higher-level way to, e.g., do I/O.
Paravirtualization does not need the hardware support needed for full
virtualization.
There are some other features that are useful for having decent
performance when running a lot of guest OSs that are being added by
Intel and AMD that are more significant, in particular MMU
enhancements.
So, while full hardware virtualization is a cute idea and was useful
on the IBM 370 etc., does it have any wider significance? Not really.
It's just one thing among many that may help in implementing
virtualization, which is also a cute idea whose usefulness varied over
time.
BTW, why was there demand for virtualization in Intel/AMD eventually?
The thing I heard is that the conventional wisdom is to run only one
application/server on Windows or it becomes unstable. So companies
had a lot of mostly idle machines around, each running one server:
mail server, web server, SAP server, database server, ... They wanted
to consolidate these on one machine, and VMware gave them a solution
for that: run all the Windowses under VMware on one machine. ISPs
hosting (Linux or Windows) servers for several different customers on
one machine are another market.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2011: http://www.euroforth.org/ef11/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-07-07 13:17 -0500 |
| Subject | Re: OT: full virtualization |
| Message-ID | <6tKdnaCOYfeAZYjTnZ2dnUVZ8tqdnZ2d@supernews.com> |
| In reply to | #3859 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > > BTW, why was there demand for virtualization in Intel/AMD > eventually? The thing I heard is that the conventional wisdom is to > run only one application/server on Windows or it becomes unstable. That doesn't explain the preference for virtualization on real OSs. There it's more to do with the ability to run on the cloud, to move servers across hardware, to isolate them from each other for security reasons, ease of management, and so on. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2011-07-08 04:53 -0700 |
| Subject | Re: OT: full virtualization |
| Message-ID | <30c64215-347d-4123-a444-347591a88b01@34g2000yqr.googlegroups.com> |
| In reply to | #3862 |
On Jul 7, 7:17 pm, Andrew Haley <andre...@littlepinkcloud.invalid> wrote: > Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote: > > > BTW, why was there demand for virtualization in Intel/AMD > > eventually? The thing I heard is that the conventional wisdom is to > > run only one application/server on Windows or it becomes unstable. A bit of an old wives tale. The main reason was to do with the way these systems were acquired on departmental budgets where sharing was anathema. Even networks were sometimes purchased on a no sharing basis, but it's been some time since I saw that. Compute is going through that change right now, because economic realities demand it, not because end-users actually want it. Largely, they still prefer their own tin running their own isolated app. Shall we let 'em eat cake? No, because it's just to damn expensive. Next up; data. There's still an obsession with directly attached storage on servers, even fully virtualised ones; and it doesn't sit well with VM mobility (see below) where data sharing is a big requirement. There are a few data motion issues to overcome too, but they're being worked on. > > That doesn't explain the preference for virtualization on real OSs. > There it's more to do with the ability to run on the cloud, to move > servers across hardware, to isolate them from each other for security > reasons, ease of management, and so on. > > Andrew. The biggie here is what cloud types refer to as "elasticity". Basically, the ability to run up and down VMs based on demand, and to suspend, move and restart VM images either on the same machine or elsewhere. Paravirtual VM support is the new OS in a sense, and is more application centric; given that we can add and virtualise just about any layer in the stack, it becomes much more effective to suspend/move/resume just the application rather than the entire OS. See VMware's SpringSource for an example. (An aside. I invented cloud computing in the early 1980s. Yes, VM/CMS based running APL applications on a mainframe. Suspend to tape, send the tape to another site, resume the processing. OK, it's not quite as slick as it is now, but I think I should get some royalties, no?)
[toc] | [prev] | [next] | [standalone]
Page 13 of 17 — ← Prev page 1 … 11 12 [13] 14 15 … 17 Next page →
Back to top | Article view | comp.lang.forth
csiph-web