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 324 — 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 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: 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 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 14 of 17 — ← Prev page 1 … 12 13 [14] 15 16 17 Next page →
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2011-07-10 13:06 -0700 |
| Subject | Re: OT: full virtualization (was: The Lisp Curse) |
| Message-ID | <3c6c24d9-c87c-4290-b695-43d3b0adf144@w24g2000yqw.googlegroups.com> |
| In reply to | #3941 |
On Jul 10, 5:03 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > Alex McDonald <b...@rivadpm.com> writes: > >On Jul 7, 4:36=A0pm, an...@mips.complang.tuwien.ac.at (Anton Ertl) > >wrote: > >> Full virtualization is much less useful in other environments, so the > >> hardware support for that was not implemented for a long time. =A0I > >> 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. > > >It must have been a long time ago indeed, since virtualization (or > >virtualisation, pick your spelling poison of choice) is a primary > >requirement now; there's no question that the demand is there. > > It was several years before AMD and Intel added the hardware feature > that is necessary to run an unaware OS without workarounds like binary > translation. As for the primary requirement, I explained why I think > that this hardware feature is not that important, but maybe I did not > come across, so here's a compact summary: > > 1) For performance we need paravirtualization, so the guest OS is > aware anyway that it is being run virtualized. That is where the extensions will be. Paravirtualization is just a fancy word for the functions we would normally associate with an OS running on bare metal. Except that the VM "bare metal" is now much smarter then the real bare metal. > > 2) Other hardware features (like MMU enhancements) are also important, > maybe more important (a few years after the introduction of the > feature above I heard some presentation where someone said that in the > near future AMD and Intel would add hardware support for > virtualisation; he was obviously thinking of some other feature than > the one mentioned above). Personal opinion; The hypervisor is disappearing into the silicon. And OSes are destined to get thin. Very thin indeed. > > >> So, while full hardware virtualization is a cute idea and was useful > >> on the IBM 370 etc., does it have any wider significance? =A0Not 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. > > >Hmmmm... I'm now getting a distinct feeling that the IBM mainframe is > >your least favourite platform. It's certainly the first time I've > >heard VM/CMS described as cute. > > I was actually referring to the hardware feature that was present in > IBM 370 after 1972, but not in Intel/AMD CPUs until 2005 or so. It > occured in the "Introduction to Computer Science" course I took. Why? > Because it was so significant? I don't think so; if it had been > significant, it would not have been limited to one hardware platform > for more than 30 years. So it occured in the course because it's a > cute (or, if you prefer, "neat") idea. > Software has been described using a number of adjectives, most of them unrepeatable here. I think you took me too seriously over the word "cute". I found your description, for want of a better word, cute. A smiley is in order ;-) > Concerning IBM mainframes, I have no experience with them, so no > reason to consider them my least favourite platform. > > - 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 | Nomen Nescio <nobody@dizum.com> |
|---|---|
| Date | 2011-07-07 00:11 +0200 |
| Message-ID | <283d1b6e0f8b23931780cf040e28481c@dizum.com> |
| In reply to | #3809 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: I'm not seeing Alex's posts because of my googlegroups filtering. No offense intended to you, Alex. > 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. I don't think that is correct, but I don't know for sure. If you ask on comp.lang.misc or comp.lang.pl1 there are some guys who do know though. > 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. Depends how you count it. RISC is also big endian. Nevertheless, big endian is the sensible approach from a programmer's view. What's the point of having to read registers one way and storage the other? That's just stupid. If they would have been true little-endian everywhere then at least it would make sense. As it is, it's a bad implementation. Big endian makes sense, doesn't get in your way, and has been working longer than little endian so how popular it is really doesn't matter. How right it is does. > 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? By market share, certainly. By longevity. By profitability. By almost every metric. A better question is what hasn't been influenced by it. Just because Intel did things to not be like IBM doesn't mean anything except that Intel made a lot of stupid decisions that haunt them to this day. > 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, because the VAX is dead. DEC is dead. The hardware and software are gone, and only a handful of sites are using anything related to them in production (just a few PDP 11's are left along with a commercial emulator). Countless microprocessor designs are dead. They all came later than IBM and IBM machines based on the original architecture are still running the world almost 50 years later. That's pretty conclusive. It's a rare example of something that is fundamentally correct and elegant and was also marketed well. Usually you have only one of those things (Windows, Linux, UNIX). example.)
[toc] | [prev] | [next] | [standalone]
| From | Elizabeth D Rather <erather@forth.com> |
|---|---|
| Date | 2011-07-06 12:47 -1000 |
| Message-ID | <yfSdna9tGf56eInTnZ2dnUVZ_gGdnZ2d@supernews.com> |
| In reply to | #3841 |
On 7/6/11 12:11 PM, Nomen Nescio wrote: > anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: ... >> >> One trait that has not taken over the world is big-endian byte order. > > Depends how you count it. RISC is also big endian. Nevertheless, big endian > is the sensible approach from a programmer's view. What's the point of > having to read registers one way and storage the other? That's just > stupid. If they would have been true little-endian everywhere then at least > it would make sense. As it is, it's a bad implementation. Big endian makes > sense, doesn't get in your way, and has been working longer than little > endian so how popular it is really doesn't matter. How right it is does. I don't know anyone who disagrees with that assessment: yet another example of technical superiority not being sufficient to triumph in the marketplace. Little-endianness maintains its dominance because of Intel and the dominance of the x86 via (primarily) PCs. Market power comes from many things, of which technical excellence is often a minor component. 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-07-07 10:07 +0000 |
| Message-ID | <2011Jul7.120741@mips.complang.tuwien.ac.at> |
| In reply to | #3841 |
Nomen Nescio <nobody@dizum.com> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>> One trait that has not taken over the world is big-endian byte order.
>
>Depends how you count it. RISC is also big endian.
Berkeley RISC? Maybe, but it's irrelevant. Or do you mean RISC CPUs
in general? They tend to be able to work in both byte orders; some of
them are usually big-endian (SPARC, PowerPC), some usually
little-endian (ARM, Alpha), some are used in both directions in
significant numbers (MIPS).
> Nevertheless, big endian
>is the sensible approach from a programmer's view.
As a programmer, I find little-endian more sensible.
There's a reason why the names "big-endian" and "little-endian" were
chosen.
>> By what measure of significance?
>
>By market share, certainly.
Evidence?
>By longevity.
By that metric, Jeanne Calment is the most significant human.
> By profitability.
Evidence? And that metric may be significant to accountants, but why
would it make it significant in c.l.f?
>> 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, because the VAX is dead.
And yet, the saying has survived to this day. Probably because many
more people have programmed a VAX than an IBM 360.
- 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 | Tarkin <tarkin000@gmail.com> |
|---|---|
| Date | 2011-07-07 13:00 -0700 |
| Message-ID | <b69c89c2-5087-4f65-8efc-283eb9d2d53b@u30g2000vby.googlegroups.com> |
| In reply to | #3787 |
On Jul 4, 6:01 pm, Alex McDonald <b...@rivadpm.com> wrote: > 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. > All right, I'll retract my statement, and resubmit it as opinion, one distilled from years of following alt.folklore.computers, and absorbing the dubious practices of mainframe/minicomputer manufacturers of the the era- not limited to IBM, FWIW > [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... > And sentiment is mirrored by least one person who worked with that system at it's inception. > 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. > See above; the virtualization was strong with that one. > 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. I am slighty older than you think. I was born in the seventies, know how to read an analog clock, and remember 45rpm records and reel-to-reels. So, now that we are over how old or young I am, isn't it fair to say that a comparably aged system beat the IBM system by 30%? But I thought IBM's solutions were superior in every way.... > > 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. > Again, you'd be flat wrong. I attended one of the first Fractal Mathematics Confrences in Massachusetts, with the blessings of my High School principal and Physics teacher. You must have missed my reference to Lorentz, as I believe^H^H know it was his meteorological research that formed modern chaos theory as we know it. Now, as to whatever black magic is being used these days, if it ain't based on stochastics, it's not even _wrong_ ..... > [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. > No. But as Ms. Rather points out later, the machines that do are everything and anything _but_ IBM. Now, had you said, "But surely you'll agree that the governments and the banks that those CERN folks are in regular contact depend upon the enterprise computing power of MVS/zSYS somewhere down the line", well then, that would have been more honest and less "chickenshit". But please, do tell us how superior in every way that MVS/zSys is to everything else, and how rotten *nices are, even though I'd bet *nix deployments outnumber MVS/zSys by a hefty factor. TTFN, Tarkin
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-07-04 12:40 -0500 |
| Message-ID | <AP-dnb4XDZWbZozTnZ2dnUVZ8uednZ2d@supernews.com> |
| In reply to | #3775 |
Fritz Wuehler <fritz@spamexpire-201107.rodent.frell.theremailer.net> wrote: > > 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. Lots of OSes were written in various system-specific PL/ languages: I remember PLZ/SYS and PL/M. Are you really going to claim that they are all, in fact, "assembly language" or that IBM's PL/S was lower-level than those? I don't know, I never used it. The Wikipedia page says it was based on PL/1. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2011-07-04 11:15 -0700 |
| Message-ID | <8f3223e7-bcc9-4d2e-b08f-176e87219fbc@j15g2000yqf.googlegroups.com> |
| In reply to | #3779 |
On Jul 4, 6:40 pm, Andrew Haley <andre...@littlepinkcloud.invalid> wrote: > Fritz Wuehler <fr...@spamexpire-201107.rodent.frell.theremailer.net> wrote: > > > 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. > > Lots of OSes were written in various system-specific PL/ languages: I > remember PLZ/SYS and PL/M. Are you really going to claim that they > are all, in fact, "assembly language" or that IBM's PL/S was > lower-level than those? I don't know, I never used it. The Wikipedia > page says it was based on PL/1. > > Andrew. PL/S was pretty low level. It was to PL/I what C is to Algol.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-07-04 15:53 -0500 |
| Message-ID | <itCdnb-504KktY_TnZ2dnUVZ8iKdnZ2d@supernews.com> |
| In reply to | #3781 |
Alex McDonald <blog@rivadpm.com> wrote: > On Jul 4, 6:40?pm, Andrew Haley <andre...@littlepinkcloud.invalid> > wrote: >> Fritz Wuehler <fr...@spamexpire-201107.rodent.frell.theremailer.net> wrote: >> >> > 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. >> >> Lots of OSes were written in various system-specific PL/ languages: I >> remember PLZ/SYS and PL/M. ?Are you really going to claim that they >> are all, in fact, "assembly language" or that IBM's PL/S was >> lower-level than those? ?I don't know, I never used it. ?The Wikipedia >> page says it was based on PL/1. > > PL/S was pretty low level. It was to PL/I what C is to Algol. They all were, from what I remember, although PLZ is the only one I actually used. Nothing like assembly language, though. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Nomen Nescio <nobody@dizum.com> |
|---|---|
| Date | 2011-07-05 10:16 +0200 |
| Message-ID | <786873169ef8eec59cdf1bd8af228c92@dizum.com> |
| In reply to | #3779 |
Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > Fritz Wuehler <fritz@spamexpire-201107.rodent.frell.theremailer.net> wrote: > > > > 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. > > Lots of OSes were written in various system-specific PL/ languages: I > remember PLZ/SYS and PL/M. Are you really going to claim that they > are all, in fact, "assembly language" or that IBM's PL/S was > lower-level than those? I don't know, I never used it. The Wikipedia > page says it was based on PL/1. Oh, I knew I was right, you're getting this all from Wikipedia. It would have been a lot better if you had just asked instead of stating incorrect things as if you knew they were facts. I have never heard of PLZ/SYS, so I have nothing to say on that. I'm familiar with PL/I, it's a very nice HLL that should have been more successful. No IBM version of PL/I (and I believe only IBM ever sold a PL/I capable of running on a mainframe) can be used for writing systems software. AFAIK, PL/M *was* a derivative of PL/I that was created (I think) by Digital Research and used to write much of their DOS code. Again, it was not a mainframe language and was not an assembly language although it could be used, and was, to write system code, since that's what they designed it for. But it doesn't run on a mainframe and can't be used to write systems software on mainframes, it's strictly a PC language. I can tell you PL/S, PL/AS, and PL/X are all proprietary, high level assemblers targeting the IBM mainframe. They do have similarities to PL/I because they're all more or less ALGOL-derived languages with control structures and declarations similar to ALGOL. That's where the similarity ends. PL/X and predecessors don't have a runtime, because they translate pretty much directly to assembler and they have critical features for writing system code that HLLs don't, like being able to manipulate registers and other low level areas, and issue system service requests. All the system services requests are actually dual-language PL/AS / PL/X and assembler. This wasn't worth mentioning before because these languages don't go outside IBM, but since we are discussing it the truth is all the systems services macros can be invoked from either assembler or PL/X. Another point where the wikipedia article is wrong (I hadn't looked at it until now) is about not being able to modify the OS because of not having access to PL/S. PL/S and assembler coexist without effort, there is no problem to extend one from the other and indeed many people did all kinds of system modifications in assembler then and now. I do that for my job, and I use assembler. I'm not sure PL/S could be based on PL/I since they both came out around the same time. I don't even know whether they were developed by the same group or just happen to be similar and it's not impossible that they were designed by different groups and look similar because of the ALGOL influence. Many ALGOL descendants are strikingly similar in many ways. Syntax is similar, but that's it. What they can actually do and how they are used is completely different. So yes, PL/S, PL/AS, and PL/X are much lower level languages than PL/I, and they're only distant relatives insomuch as their structure looks familiar to a PL/I programmer...but not more than that, and in many ways much less. They have no library calls, no conversion routines, etc. They're really not much more than a custom built HLA for the IBM platform. I'm familiar with all of them more or less because we have to read code in PL/AS and I wrote code in PL/X when it was available for a short time. I didn't like it though, I feel assembler was more natural and easier to use. It's not unusual for systems software vendors to develop their own languages for writing their OS and tools and part of the reason is it keeps their staff around since what they learn isn't portable. Nobody outside IBM uses these languages, so people who spent careers learning them don't have any transferable skills, aside from their internals knowledge, which of course is valuable. That brings us around to what I have been saying. If you want to write systems software on the mainframe, it can only be done in assembler. Now I'll add, if you work for IBM, you can do it in PL/X.
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2011-07-05 02:23 -0700 |
| Message-ID | <e8285647-c114-4ce1-900d-a3a08ab8003c@u30g2000vby.googlegroups.com> |
| In reply to | #3797 |
On Jul 5, 9:16 am, Nomen Nescio <nob...@dizum.com> wrote: > Andrew Haley <andre...@littlepinkcloud.invalid> wrote: > > Fritz Wuehler <fr...@spamexpire-201107.rodent.frell.theremailer.net> wrote: > > > > 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. > > > Lots of OSes were written in various system-specific PL/ languages: I > > remember PLZ/SYS and PL/M. Are you really going to claim that they > > are all, in fact, "assembly language" or that IBM's PL/S was > > lower-level than those? I don't know, I never used it. The Wikipedia > > page says it was based on PL/1. > > Oh, I knew I was right, you're getting this all from Wikipedia. It would > have been a lot better if you had just asked instead of stating incorrect > things as if you knew they were facts. > > I have never heard of PLZ/SYS, so I have nothing to say on that. > > I'm familiar with PL/I, it's a very nice HLL that should have been more > successful. No IBM version of PL/I (and I believe only IBM ever sold a PL/I > capable of running on a mainframe) can be used for writing systems software. It was too damn complicated for the average code jockey. (Aside: I borrowed one of its features for my assembler programs; Q type address constants. Cool feature.) [snip] > > That brings us around to what I have been saying. If you want to write > systems software on the mainframe, it can only be done in assembler. Now > I'll add, if you work for IBM, you can do it in PL/X. Amongst commercial organisations that wrote major apps for IBM mainframe OSes, it was common to mix approaches; high level languages for all but the interfaces to the OS. For instance, I worked on a very large parts distribution system (100s of 100s of line items, 100s of suppliers, several tens of warehouses and automated stocking/picking) where everything was COBOL up to the IO interface. The rest was written in ASM/H and managed 100s of discrete VSAM databases using shared buffer pools, something COBOL couldn't do.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-07-05 09:54 -0500 |
| Message-ID | <gYednRcpyM0IuI7TnZ2dnUVZ8jydnZ2d@supernews.com> |
| In reply to | #3797 |
Nomen Nescio <nobody@dizum.com> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > >> Fritz Wuehler <fritz@spamexpire-201107.rodent.frell.theremailer.net> wrote: >> > >> > 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. >> >> Lots of OSes were written in various system-specific PL/ languages: I >> remember PLZ/SYS and PL/M. Are you really going to claim that they >> are all, in fact, "assembly language" or that IBM's PL/S was >> lower-level than those? I don't know, I never used it. The Wikipedia >> page says it was based on PL/1. > > Oh, I knew I was right, you're getting this all from Wikipedia. It > would have been a lot better if you had just asked instead of > stating incorrect things as if you knew they were facts. Attempt at evasion noted. I was merely responding to > If you look at the IBM mainframe the operating system is written in > assembler. which seems not to have been true. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Nomen Nescio <nobody@dizum.com> |
|---|---|
| Date | 2011-07-05 22:33 +0200 |
| Message-ID | <a2f10593f8a8260a3d444cb63f5dfb69@dizum.com> |
| In reply to | #3808 |
A shit-eating, argumentative, know-nothing Linux clown named Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > Attempt at evasion noted. > > I was merely responding to > > > If you look at the IBM mainframe the operating system is written in > > assembler. > > which seems not to have been true. Ok asshole, look here: http://www.mainframe.eu/mvs38/asm/ All the source for the only version of MVS released to the public is available for browsing online. A quick review indicates the majority of the code is pure assembler. Ok fuckhead? Happy now? Now you can apologize for jerking off in public, talking shit about things you have no idea about and no involvement in, and arguing for no good reason other than the fact you're a sanctimonious, argumentative, shit-eating sonofabitch. I hope you learned your lesson, but I sincerely doubt it. And to the ladies present, "Please pardon our French"!
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-07-05 16:28 -0500 |
| Message-ID | <LvKdnVXfHqpkHI7TnZ2dnUVZ7oCdnZ2d@supernews.com> |
| In reply to | #3819 |
Nomen Nescio <nobody@dizum.com> wrote:
> A shit-eating, argumentative, know-nothing Linux clown named Andrew Haley
> <andrew29@littlepinkcloud.invalid> wrote:
>
>> Attempt at evasion noted.
>>
>> I was merely responding to
>>
>> > If you look at the IBM mainframe the operating system is written in
>> > assembler.
>>
>> which seems not to have been true.
>
> Ok asshole, look here:
>
> http://www.mainframe.eu/mvs38/asm/
>
> All the source for the only version of MVS released to the public is
> available for browsing online. A quick review indicates the majority of the
> code is pure assembler.
Well, if I look at http://www.mainframe.eu/mvs38/asm/TSO%20%28IKJ%29/IKJCT431
I see stuff like
* /*****************************************************************/ 00079000
* /* */ 00080000
* /* CHECK GETMAIN RETURN CODE */ 00081000
* /* */ 00082000
* /*****************************************************************/ 00083000
* 0112 00084000
* IF R15^=CON0 THEN /* CONTROL BLOCKS */ 00085000
LTR R15,R15 0112 00086000
BZ @RF00112 0112 00087000
* DO; /* IF STORAGE COULD NOT BE */ 00088000
* RFY 0114 00089000
* R15 UNRSTD; /* OBTAINED THEN NOTIFY USER AND */ 00090000
* EXMSGID=M511; /* RETURN RC=16 */ 00091000
MVC EXMSGID(4),@CC01271 0115 00092000
* CALL MSGRTN; /* ISSUE MESSAGE */ 00093000
BAL @14,MSGRTN 0116 00094000
* NOTEXEC=YES; /* COMMAND PROCEDURE NOT 0117 00095000
* EXECUTABLE */ 00096000
OI NOTEXEC(ECDAPTR),B'01000000' 0117 00097000
* CT431RET=CON16; 0118 00098000
MVC CT431RET(4),@CF01028 0118 00099000
* END; /* CONTROL RETURNS TO EXIT POINT */ 00100000
*
Is it possible that this assembly source is, in fact, the output of a
compiler?
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2011-07-05 16:18 -0700 |
| Message-ID | <0aeb5c4f-7407-4f56-9250-4b1a860369b2@hd10g2000vbb.googlegroups.com> |
| In reply to | #3823 |
On Jul 5, 10:28 pm, Andrew Haley <andre...@littlepinkcloud.invalid> wrote: > Nomen Nescio <nob...@dizum.com> wrote: > > A shit-eating, argumentative, know-nothing Linux clown named Andrew Haley > > <andre...@littlepinkcloud.invalid> wrote: > > >> Attempt at evasion noted. > > >> I was merely responding to > > >> > If you look at the IBM mainframe the operating system is written in > >> > assembler. > > >> which seems not to have been true. > > > Ok asshole, look here: > > >http://www.mainframe.eu/mvs38/asm/ > > > All the source for the only version of MVS released to the public is > > available for browsing online. A quick review indicates the majority of the > > code is pure assembler. > > Well, if I look athttp://www.mainframe.eu/mvs38/asm/TSO%20%28IKJ%29/IKJCT431 > > I see stuff like > > * /*****************************************************************/ 00079000 > * /* */ 00080000 > * /* CHECK GETMAIN RETURN CODE */ 00081000 > * /* */ 00082000 > * /*****************************************************************/ 00083000 > * 0112 00084000 > * IF R15^=CON0 THEN /* CONTROL BLOCKS */ 00085000 > LTR R15,R15 0112 00086000 > BZ @RF00112 0112 00087000 > * DO; /* IF STORAGE COULD NOT BE */ 00088000 > * RFY 0114 00089000 > * R15 UNRSTD; /* OBTAINED THEN NOTIFY USER AND */ 00090000 > * EXMSGID=M511; /* RETURN RC=16 */ 00091000 > MVC EXMSGID(4),@CC01271 0115 00092000 > * CALL MSGRTN; /* ISSUE MESSAGE */ 00093000 > BAL @14,MSGRTN 0116 00094000 > * NOTEXEC=YES; /* COMMAND PROCEDURE NOT 0117 00095000 > * EXECUTABLE */ 00096000 > OI NOTEXEC(ECDAPTR),B'01000000' 0117 00097000 > * CT431RET=CON16; 0118 00098000 > MVC CT431RET(4),@CF01028 0118 00099000 > * END; /* CONTROL RETURNS TO EXIT POINT */ 00100000 > * > > Is it possible that this assembly source is, in fact, the output of a > compiler? > > Andrew. Yes, it's PL/S. The 4 digit line number in the comment field is characteristic of the output of PL/S; it allowed you to xref the raw source to the assembler output listing. It's 30 years since I last saw this :-)
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@noavailemail.cmm> |
|---|---|
| Date | 2011-07-04 15:03 -0400 |
| Message-ID | <iut2qo$804$1@speranza.aioe.org> |
| In reply to | #3775 |
"Fritz Wuehler" <fritz@spamexpire-201107.rodent.frell.theremailer.net> wrote in message news:fbea4798d922ac758d0059ba4a6b1feb@msgid.frell.theremailer.net... > > > 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. Exactly, usually... With some exceptions, C compilers are very good at optimization. I.e., if a GOTO worked there originally, the optimized non-GOTO code will usually reduce to a similar code with a jump. So, what's the reason for using 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've created code that can be modified much more easily. Once a GOTO is used in C code, it becomes more difficult to reorganize the code. You must eliminate the use of the GOTO before reorganizing the code. In one case I came across, there where three GOTOs in the same procedure. You can't reorganize, modify, or change the existing control flow, because you're effectively being blocked by the GOTO(s). > 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 need to drop the "most widely used" and "influential"... That comes off as an extreme exaggeration. To be the "most widely used" it must've outsold x86 PCs. To be the "most widely used" it must've outsold the billions of ARM-based portable devices. To be the most "influential" must deny the <pick-a-world-changing-OS-from-history> OS, e.g., MacIntosh, Wintel, C64, etc. > How can you do malloc and free without libc? > AFAIK you can't. Oh, sure you can... Memory is allocated and free'd behinds the scenes in C in a number of ways. 1) You can allocate large file scope arrays and apply your own memory allocation. This can be far simpler than malloc()/free(). You just set a pointer to a typedef for a struct, union, etc to free space in the array. Or, you can use one of the three or so publicly available memory allocators applied to the array. 2) You can also declare procedure local variables which allocates space from the stack (like non-standard alloca()). Returning from a procedure call frees the allocated stack space. You can call C functions recursively, which allocates from the stack repeatedly (like multiple alloca() calls and free's when returned). 3) The file I/O functions in C essentially creates a hidden memory allocator behind the scenes. Most C file I/O functions allocate space from a storage device, not from memory. However, a file created by tmpfile() will be created in memory in most C implementations. So, file I/O can also be used effectively as a memory allocator, i.e., appending to the end of a file effectively allocates memory. If tmpfile() doesn't create in memory, it'll create on disk and with enough buffering, it's effectively the same as using memory. > 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. > I don't like their CLIs, but I do like their C compiler when combined with Posix file I/O. The everything is a file concept works well for me. > If I am wrong, please tell me how I can dynamically allocate and free > storage for structures in assembly, In assembly or for assembly structures? I think you meant the latter. You're not asking me to write assembly for C are you? ... > how I can dynamically allocate and free > storage or even discrete variables. The easiest is #1 above. C allows typedef's of objects. This creates an addressing structure without allocating space for the object. If you declare a pointer to the typedef of some object, i.e., struct or union, you can then set the pointer to a previously allocated memory region to provide space. This is commonly done with memory allocated via malloc(). However, it can be done with any memory that is allocated. In C you can declare arrays, i.e., allocate "empty" storage space that can hold a bunch of objects. > I heard you > have to write your own memory manager in > UNIX/LINUX if you don't use libc. You could write your own. When you have many objects of a fixed size and use typedef's, it can be very simple, i.e., not much more than a linked list of typedef'd objects stored in an array. If you don't want to, you can use one of these: John Walker's bget http://www.fourmilab.ch/bget/ Doug Lea's dlmalloc http://gee.cs.oswego.edu/dl/html/malloc.html Dynamic Storage Allocator, Richard Harter, comp.lang.c, Nov. 11, 1990. http://groups.google.com/group/comp.lang.c/msg/7da27dcbc6e2ace1 Apparently, FreeBSD has a nice memory allocator also. Or, #1 above is easiest. #3 is easy also. > but other headers are stipped by the mix system, nothing we can do about > that. Sorry to hear that... The carets > in the header and used as indentation (one more caret) in the post are used to indicate who said what in the replied to posts. Since the method you're using to post, strips them, I can't tell who said what from the post. I must go back to the indentation of the messages to figure out which caret level was which person. > [Usenet] headers On the message I replied to, there was no header. With my reply, it adds your header (above and copied here): "Fritz Wuehler" <fritz@spamexpire-201107.rodent.frell.theremailer.net> wrote in message news:fbea4798d922ac758d0059ba4a6b1feb@msgid.frell.theremailer.net... Since you replied to me, my header should've been there, indented once: > Rod Pemberton" <do_not_have@noavailemail.cmm> wrote in message news:iur1a7$gad$1@speranza.aioe.org... Since some of your comments from the earlier message were included, your prior header should've been there indented twice: > > "Fritz Wuehler" <fritz@spamexpire-201107.rodent.frell.theremailer.net> wrote in message news:2746c0939d1a238ee58384acafc1b122@msgid.frell.theremailer.net... So, it should've looked something like this at the top of the post: "Fritz Wuehler" <fritz@spamexpire-201107.rodent.frell.theremailer.net> wrote in message news:fbea4798d922ac758d0059ba4a6b1feb@msgid.frell.theremailer.net... > Rod Pemberton" <do_not_have@noavailemail.cmm> wrote in message news:iur1a7$gad$1@speranza.aioe.org... > > "Fritz Wuehler" <fritz@spamexpire-201107.rodent.frell.theremailer.net> wrote in message news:2746c0939d1a238ee58384acafc1b122@msgid.frell.theremailer.net... See, you can see it was "you"-me-"you"... But, lets say someone else was inbetween, without those headers, it becomes more confusing as to who said what. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Nomen Nescio <nobody@dizum.com> |
|---|---|
| Date | 2011-07-05 00:20 +0200 |
| Message-ID | <c58cc7ab95384b37ff11fe9ced570ca4@dizum.com> |
| In reply to | #3782 |
> Exactly, usually... With some exceptions, C compilers are very good at > optimization. I.e., if a GOTO worked there originally, the optimized > non-GOTO code will usually reduce to a similar code with a jump. So, what's > the reason for using a GOTO? Don't ask me, I don't write C code. I'm just disputing the universal wisdom that goto's have no place in code when people who never coded anything but C are saying it, and showing a project that is widely regarded as good (not by me though) uses them and K&R says there is a place for them even in C. > You need to drop the "most widely used" and "influential"... That comes off > as an extreme exaggeration. Extreme exaggeration? Not just exaggeration but "extreme exaggeration"? If I am going to exaggerate I like to do it with extremism. Go all the way. But it's not exaggeration, on this topic that would be almost impossible to do. Every company who ran a computer in the 1960s and 1970s used IBM mainframes, and every major company and government still uses them. They're king, baby! > To be the "most widely used" it must've outsold x86 PCs. It was the most widely used computer for decades in business, before there was such a thing as Intel, and IBM is still the worlds biggest computer company, they make more money than Microsoft and their software quality is so much better Microsoft can't even see them from where they are. > To be the "most widely used" it must've outsold the billions of ARM-based > portable devices. It outsold everything before there was such thing as ARM and it's still selling and running major corporations and countries today. Nobody cares of one or a dozen Intel boxes crashes. If a mainframe crashes, it's millions of dollars a minute. So they stay up. > To be the most "influential" must deny the > <pick-a-world-changing-OS-from-history> OS, e.g., MacIntosh, Wintel, C64, > etc. That all came later, and was influenced by what IBM did. You have everything upside down. The world didn't start with the 8080. Learn some history, bucko! It's good for you! > > > How can you do malloc and free without libc? > > AFAIK you can't. > > Oh, sure you can... Memory is allocated and free'd behinds the scenes in C > in a number of ways. 1) You can allocate large file scope arrays and apply > your own memory allocation. mmap? > This can be far simpler than malloc()/free(). You just set a pointer to a > typedef for a struct, union, etc to free space in the array. Or, you can > use one of the three or so publicly available memory allocators applied to > the array. But that calls malloc or libc, does it not? > 2) You can also declare procedure local variables which allocates space > from the stack (like non-standard alloca()). Returning from a procedure > call frees the allocated stack space. Ok. > You can call C functions recursively, which allocates from the stack > repeatedly (like multiple alloca() calls and free's when returned). 3) The > file I/O functions in C essentially creates a hidden memory allocator behind > the scenes. Most C file I/O functions allocate space from a storage device, > not from memory. However, a file created by tmpfile() will be created in > memory in most C implementations. So, file I/O can also be used effectively > as a memory allocator, i.e., appending to the end of a file effectively > allocates memory. If tmpfile() doesn't create in memory, it'll create on > disk and with enough buffering, it's effectively the same as using memory. Ok but I was not talking about C. And are we talking DOS or Windows or Linux or what? How is this hidden memory allocator invoked? Libc call? The whole point is that CrapOS doesn't give you any application level memory management, you have to call libc. That's chicken shit. In a real OS you can ask for storage and free it, you don't need a library call to do it. I think even Windows got this right, why not UNIX? > > If I am wrong, please tell me how I can dynamically allocate and free > > storage for structures in assembly, > > In assembly or for assembly structures? I think you meant the latter. > You're not asking me to write assembly for C are you? ... In assembly...since presumably everything you do in c uses libc. > > > how I can dynamically allocate and free > > storage or even discrete variables. > > The easiest is #1 above. C allows typedef's of objects. This creates an > addressing structure without allocating space for the object. If you > declare a pointer to the typedef of some object, i.e., struct or union, you > can then set the pointer to a previously allocated memory region to provide > space. This is commonly done with memory allocated via malloc(). However, > it can be done with any memory that is allocated. In C you can declare > arrays, i.e., allocate "empty" storage space that can hold a bunch of > objects. But we're going in circles. The question is how do you allocate memory on Linux without malloc (libc) since Linux/UNIX doesn't provide any application memory management at the OS level, only through libc. If you're saying you just create a bunch of .data elements that's also not dynamically allocating anything. Even .bss doesn't qualify because it's just stealing from heap or stack once, when the program is loaded. For example if you want to read in an unknown amount of data and want to create a linked list of it, how are you supposed to allocate each node? AFAIK you have to call libc whether you do it directly or indirectly. The point is not that C is bad, the point is UNIX/LINUX are CrapOS since there is no OS call to allocate and free memory at the application level. They tell you to use libc or write your own. That's not an OS, that's a chickenshit Berkleyism. Damn those Birkenstock-wearing faggots! > Apparently, FreeBSD has a nice memory allocator also. Or, #1 above is > easiest. #3 is easy also. Yeah but that kind of proves there's no memory management at the OS level for applications? And AFAIK, FreeBSD has the same problem as other UNIX/LINUX. It only has break and mmap like all other UNIX. I hope I missed something but I don't think I did, from looking at the syscalls. > Sorry to hear that... The carets > in the header and used as indentation > (one more caret) in the post are used to indicate who said what in the > replied to posts. Since the method you're using to post, strips them, I > can't tell who said what from the post. I must go back to the indentation > of the messages to figure out which caret level was which person. I'm replying to one person and the single > are you, the double >> are me or someone else using a remailer, and the >>> are you, etc. > Since you replied to me, my header should've been there, indented once: > > Rod Pemberton" <do_not_have@noavailemail.cmm> wrote in message > news:iur1a7$gad$1@speranza.aioe.org... Oh, I just cut that out since the threading tells me who posted it. Sorry, I'll try to leave it in. > See, you can see it was "you"-me-"you"... But, lets say someone else was > inbetween, without those headers, it becomes more confusing as to who said > what. I'll try to fix it in the future (too late for this post though).
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@noavailemail.cmm> |
|---|---|
| Date | 2011-07-05 11:35 -0400 |
| Message-ID | <iuvb1t$b78$1@speranza.aioe.org> |
| In reply to | #3789 |
"Nomen Nescio" <nobody@dizum.com> wrote in message news:c58cc7ab95384b37ff11fe9ced570ca4@dizum.com... > > I'm just disputing the universal wisdom > that goto's have no place in code when > people who never coded anything but C > are saying it, > Who would that be? Almost everyone here is a Forth coder. Surely, you don't mean me... I've experienced quite a variety of programming languages. When not required by the language proper, e.g., BASIC, there are very limited situations where a GOTO is *absolutely* needed. I already mentioned these. > [...] K&R says there is a place for them even in C. > That's intellectual dishonesty. I quoted K&R. It says it's unecessary. > But it's not exaggeration, on this topic that would be almost impossible > to do. Every company who ran a computer in the 1960s and 1970s used > IBM mainframes, and every major company and government still uses > them. They're king, baby! > You're ignoring the fact that other OS' havely clearly: outsold that OS, changed the world, etc. You can't claim IBM's OS's are the "most influential" or "widely used", unless you restrict the time period to 1960's, the first half of the 1970's, and maybe, it's questionable, the second half of the 1970's. You can't claim the 1980's with the personal computer revolution. You can't claim the late 1990's and 2000's with the portable smart device revolution. If IBM's OS work is currently revolutionary, where are the lawsuits of patent infringement of IBM's patents? There are effectively "none". Google, MS, Intel, Nokia, Apple, Samsung, RIM, even Motorola, AT&T and Oracle, etc have had many, many patent infringement lawsuits in the last decade. You read about them all the time. IBM? IBM sues Amazon, but on Internet related patents... Mostly, IBM is being sued by others for infringement. > You have everything > upside down. The world didn't start with the 8080. > Learn some history, > bucko! It's good for you! > I lived through it. You're correct that the "world" didn't start with the 8080, it all started with the 6502. The 6502 was the first microprocessor that had the major breakthrough that brought inexpensive and increasingly faster microprocessor based computing to the masses: pipelining. http://groups.google.com/group/alt.lang.asm/msg/e38c78eb59dba037 Yes, central processing units had some type of pipelining earlier, i.e., Seymore Cray CDC 6600/7600, but mainframes were and still are virtually inaccessible by the masses. > mmap? > mmap is non-standard. > > This can be far simpler than malloc()/free(). You just set a pointer to > > a typedef for a struct, union, etc to free space in the array. Or, you > > can use one of the three or so publicly available memory allocators > > applied to the array. > > But that calls malloc or libc, does it not? > No. Since it's C language only, it's supposed to be independent of libc... > The question is how do you allocate memory on > Linux without malloc (libc) since Linux/UNIX doesn't provide any > application memory management at the OS level, only through libc. > Linux? Oh that's a new constraint... I've not coded for Linux, but Linux does have wrappers for calling OS functions from C. One should be able to call the OS' memory allocation routines via the appropriate syscall, or so I would assume. I'd have to find a syscall list to see if there was a memory allocation call. There should be one since libc must call the OS to allocate memory. > If you're saying you just create a bunch of .data elements that's also not > dynamically allocating anything. Even .bss doesn't qualify because it's > just stealing from heap or stack once, when the program is loaded. For > example if you want to read in an unknown amount of data and want to > create a linked list of it, how are you supposed to allocate each node? > AFAIK you have to call libc whether you do it directly or indirectly. > Oh, another new constraint: dynamically... Without libc, dynamic allocation requires use of the stack, i.e., procedure local variables and recursive procedure calls. Each procedure declares a local node. The link for the older node is passed in the procedure call as one of the parameters. Calling a the procedure recursively allocates another node. I.e., you'll create a linked-list on the stack, intermixed with the procedure's stackframe. (FYI, technically, C doesn't require use of a stack. At least one C implementation was doen without a stack. Most C's do use a stack. So, "stack" means: whatever temporary allocation and free method used for a procedure.) > It only has break and mmap like all other UNIX. > Those are probably the two main memory allocation methods for *nix... AIUI, brk just adjusts the start or end of the stack. I understand they were moving away from brk towards mmap. I'm not to familiar with either. I'd have to look over their syscall lists to see if there are others. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2011-07-05 09:46 -0700 |
| Message-ID | <ea8b56d2-5665-4254-b6ab-f05ecf031606@m18g2000vbl.googlegroups.com> |
| In reply to | #3811 |
On Jul 5, 4:35 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm> wrote: > > If IBM's OS work is currently revolutionary, where are the lawsuits of > patent infringement of IBM's patents? There are effectively "none". > Google, MS, Intel, Nokia, Apple, Samsung, RIM, even Motorola, AT&T and > Oracle, etc have had many, many patent infringement lawsuits in the last > decade. You read about them all the time. IBM? IBM sues Amazon, but on > Internet related patents... Mostly, IBM is being sued by others for > infringement. IBM has by far and away the largest portfolio of patents. But measuring technology by patent lawsuits is using the wrong number; they're about economics and competition (or the stifling thereof), not innovation.
[toc] | [prev] | [next] | [standalone]
| From | Fritz Wuehler <fritz@spamexpire-201107.rodent.frell.theremailer.net> |
|---|---|
| Date | 2011-07-05 23:13 +0200 |
| Message-ID | <d3d3d6e91b24ebd7f48a1c4bfd36d760@msgid.frell.theremailer.net> |
| In reply to | #3811 |
"Rod Pemberton" <do_not_have@noavailemail.cmm> wrote: Here, I left your attribution in! > > I'm just disputing the universal wisdom > > that goto's have no place in code when > > people who never coded anything but C > > are saying it, > > > > Who would that be? Almost everyone here is a Forth coder. Surely, you > don't mean me... I've experienced quite a variety of programming > languages. No, I don't mean you. I mean since Wirth and Dijkstra started on their rampage, everybody thinks it's obvious you don't use goto's. That might be mostly true in C, but it's not universally true. The main thing is people who only code in C shouldn't be making generalizations about languages and platforms they never heard of. > You're ignoring the fact that other OS' havely clearly: outsold that OS, > changed the world, etc. You can't claim IBM's OS's are the "most > influential" or "widely used", unless you restrict the time period to > 1960's, the first half of the 1970's, and maybe, it's questionable, the > second half of the 1970's. You can't claim the 1980's with the personal > computer revolution. You can't claim the late 1990's and 2000's with the > portable smart device revolution. Hey, it all had to start somewhere. Give some credit to the machine and software that started it all and is still going today! No other computing platform has that track record of market success, market share, and longevity. It rocks! And yes, IBM also ruled in the 1980s, by market share, by profit, by income, by every possible financial metric. Go check it out if you want. > If IBM's OS work is currently revolutionary, where are the lawsuits of > patent infringement of IBM's patents? There are effectively "none". > Google, MS, Intel, Nokia, Apple, Samsung, RIM, even Motorola, AT&T and > Oracle, etc have had many, many patent infringement lawsuits in the last > decade. You read about them all the time. IBM? IBM sues Amazon, but on > Internet related patents... Mostly, IBM is being sued by others for > infringement. No, IBM is real good at keeping their stuff under wraps. Real security for employees and contractors. One time a Japanese company stole their stuff by using dumps and they paid almost a billion in cash settlement in US courts. IBM doesn't mess around. > I lived through it. You're correct that the "world" didn't start with the > 8080, it all started with the 6502. The 6502 was the first microprocessor > that had the major breakthrough that brought inexpensive and increasingly > faster microprocessor based computing to the masses: pipelining. > http://groups.google.com/group/alt.lang.asm/msg/e38c78eb59dba037 Yawn, bring me back to 1964! IBM OS/360, who needs more? > > But that calls malloc or libc, does it not? > > > > No. Since it's C language only, it's supposed to be independent of > >libc... Ok > > > The question is how do you allocate memory on > > Linux without malloc (libc) since Linux/UNIX doesn't provide any > > application memory management at the OS level, only through libc. > > > > Linux? Oh that's a new constraint... I've not coded for Linux, but Linux > does have wrappers for calling OS functions from C. One should be able to > call the OS' memory allocation routines via the appropriate syscall, or so I > would assume. I'd have to find a syscall list to see if there was a memory > allocation call. There should be one since libc must call the OS to > allocate memory. Yes, from what I read libc uses brk. The point is there is almost no application level storage management in NIX without libc. It's a bad "design". Other than mmap and stuff to manipulate r/w for pages there isn't any memory management syscall designed for application use in NIX. You can't say "give me 100 bytes, give me 20 bytes, give me 40 bytes, now I'm freeing the 20 bytes in the middle" without going through libc. Pure CrapOS! > Those are probably the two main memory allocation methods for *nix... AIUI, > brk just adjusts the start or end of the stack. I understand they were > moving away from brk towards mmap. I'm not to familiar with either. I'd > have to look over their syscall lists to see if there are others. >From what I have seen only page r/w type of stuff. Real disappointing. Maybe it's time to go off Linux and see what Windows has to offer the developer. Never thought I would say that!
[toc] | [prev] | [next] | [standalone]
| From | John Passaniti <john.passaniti@gmail.com> |
|---|---|
| Date | 2011-07-05 15:31 -0700 |
| Message-ID | <d882ef07-74bd-46d3-b577-628ff35c2fc5@y30g2000yqb.googlegroups.com> |
| In reply to | #3821 |
On Jul 5, 5:13 pm, Fritz Wuehler <fr...@spamexpire-201107.rodent.frell.theremailer.net> wrote: > No, I don't mean you. I mean since Wirth and Dijkstra started > on their rampage, everybody thinks it's obvious you don't use > goto's. That might be mostly true in C, but it's not universally > true. The main thing is people who only code in C shouldn't be > making generalizations about languages and platforms they > never heard of. Guns don't kill people; people kill people. Gotos don't kill programs; programmers kill programs. The only thing worse than a programmer who uses goto and creates a mess are the programmers who domatically refuse to use goto even when using it would be perfectly justified and result in better (or at least nicer) code. Is there a magic button I can press that will erase the programmers at both ends of that spectrum? An annoyingly- large amount of my career has been spent cleaning up the messes left behind both by the sloppy and dogmatic. Those of us with a more pragmatic streak don't recoil in horror when we see "goto" in code. We look at it, decide if it's stupid or not, and then move on. > Other than mmap and stuff to manipulate r/w for pages there > isn't any memory management syscall designed for application > use in NIX. You can't say "give me 100 bytes, give me 20 bytes, > give me 40 bytes, now I'm freeing the 20 bytes in the middle" > without going through libc. Pure CrapOS! Works for me. What I want in an operating system is generic and thin layer over the hardware so that my application can make its own decisions on how best to manage memory, rather than by going through some one-size-fits-all abstraction provided at the operating system level. The operating system doesn't have any great insight into the allocation patterns at the application level, nor should it. And what you call "libc" has never been terribly constraining to me, because "libc" isn't one single thing. There are several "libc" libraries available and most of them (especially the ones targeting embedded systems) allow you to pick and choose from different allocators to match your application's needs. But I'm willing to be convinced: Explain to me how a general purpose operating system is a better arbiter of allocation strategy than the application itself (or the libraries that the application chooses to use)? Seems to me that the operating system can't possibly know that allocation #81348 will be freed 20ms from now but allocation #81349 will be freed in two days. But an application's programmer can know, and can choose an allocator that could easily out-perform even the best adaptive allocator at the operating sytem level. And that's especially true when we're no longer talking about low-level C applications, but applications written with "managed" storage that run on that operating system. > it's time to go off Linux and see what Windows has to > offer the developer. Never thought I would say that! These days, the Windows world is no longer dominated by old-school C applications that directly manage memory, but by .NET applications that are hosted on a virtual machine that has a sophisticated multi- process, multi-processor generational garbage collector to manage memory. The .NET virtual machine can most certainly allocate memory more efficiently than the underlying operating system because it has access to program and usage metadata that can give information on the lifetime and other attributes of that data.
[toc] | [prev] | [next] | [standalone]
Page 14 of 17 — ← Prev page 1 … 12 13 [14] 15 16 17 Next page →
Back to top | Article view | comp.lang.forth
csiph-web