Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #6484 > unrolled thread
| Started by | Mark Thorson <nospam@sonic.net> |
|---|---|
| First post | 2012-04-10 19:31 -0800 |
| Last post | 2012-04-14 08:02 -0700 |
| Articles | 13 on this page of 133 — 28 participants |
Back to article view | Back to comp.arch
Indirect Bit Mark Thorson <nospam@sonic.net> - 2012-04-10 19:31 -0800
Re: Indirect Bit Robert Wessel <robertwessel2@yahoo.com> - 2012-04-11 01:29 -0500
Re: Indirect Bit sarr.blumson@alum.dartmouth.org - 2012-04-11 14:48 +0000
Re: Indirect Bit mac <acolvin@efunct.com> - 2012-04-12 14:43 +0000
Re: Indirect Bit Morten Reistad <first@last.name> - 2012-04-22 15:19 +0200
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-22 23:24 -0700
Re: Indirect Bit Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-04-11 08:32 +0200
Re: Indirect Bit Michael S <already5chosen@yahoo.com> - 2012-04-11 05:49 -0700
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 21:22 -0700
Re: Indirect Bit "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-04-13 08:14 -0700
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-13 16:13 -0700
Re: Indirect Bit "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-04-13 20:01 -0700
Re: Indirect Bit Andrew Reilly <areilly.---@bigpond.net.au> - 2012-04-14 03:16 +0000
Re: Indirect Bit "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-04-14 08:14 -0700
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-13 16:05 -0700
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-13 17:01 -0700
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-14 13:49 -0700
Re: Indirect Bit Anne & Lynn Wheeler <lynn@garlic.com> - 2012-04-13 20:07 -0400
Re: Indirect Bit Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-04-14 18:47 +0200
Re: Indirect Bit Morten Reistad <first@last.name> - 2012-04-22 15:26 +0200
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-22 23:25 -0700
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-23 09:18 +0100
Re: Indirect Bit EricP <ThatWouldBeTelling@thevillage.com> - 2012-04-23 19:35 -0400
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-24 08:37 +0100
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-24 09:42 +0100
Re: Indirect Bit Michael S <already5chosen@yahoo.com> - 2012-04-24 01:58 -0700
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-24 11:26 +0100
Re: Indirect Bit Michael S <already5chosen@yahoo.com> - 2012-04-24 05:02 -0700
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-24 13:58 +0100
Re: Indirect Bit Michael S <already5chosen@yahoo.com> - 2012-04-24 10:07 -0700
Re: Indirect Bit Michael S <already5chosen@yahoo.com> - 2012-04-24 04:30 -0700
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-24 13:01 +0100
Re: Indirect Bit Stefan Monnier <monnier@iro.umontreal.ca> - 2012-04-11 10:03 -0400
Re: Indirect Bit kenney@cix.compulink.co.uk - 2012-04-11 09:22 -0500
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-12 14:11 -0700
Re: Indirect Bit Stefan Monnier <monnier@iro.umontreal.ca> - 2012-04-12 18:05 -0400
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 20:13 -0700
Re: Indirect Bit Mark Thorson <nospam@sonic.net> - 2012-04-12 16:55 -0800
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-12 17:25 -0700
Re: Indirect Bit Robert Wessel <robertwessel2@yahoo.com> - 2012-04-12 20:03 -0500
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 21:33 -0700
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-13 15:57 -0700
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-13 17:03 -0700
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 20:14 -0700
Re: Indirect Bit Anne & Lynn Wheeler <lynn@garlic.com> - 2012-04-11 10:35 -0400
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-11 08:54 -0700
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 07:55 -0700
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-12 10:16 -0700
Re: Indirect Bit jacko <jackokring@gmail.com> - 2012-04-12 11:07 -0700
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 21:34 -0700
Re: Indirect Bit Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2012-04-12 11:35 -0700
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 21:41 -0700
Re: Indirect Bit jacko <jackokring@gmail.com> - 2012-04-13 14:52 -0700
Re: Indirect Bit Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2012-04-15 09:24 -0700
Re: Indirect Bit Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-04-15 22:45 +0200
Re: Indirect Bit Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2012-04-15 18:04 -0700
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 21:12 -0700
Re: Indirect Bit timcaffrey@aol.com (Tim McCaffrey) - 2012-04-12 19:23 +0000
Re: Indirect Bit Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-04-13 08:54 +0200
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-14 14:37 -0700
Re: Indirect Bit Andrew Reilly <areilly.---@bigpond.net.au> - 2012-04-15 23:42 +0000
Re: Indirect Bit "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-04-16 08:08 -0700
Re: Indirect Bit Andrew Reilly <areilly.---@bigpond.net.au> - 2012-04-16 23:38 +0000
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-16 21:29 -0700
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-16 21:25 -0700
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-12 14:05 -0700
Re: Indirect Bit ChrisQ <blackhole@devnull.com> - 2012-04-14 10:12 +0000
Re: Indirect Bit "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-04-14 06:25 -0700
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-14 14:50 +0100
Re: Indirect Bit ChrisQ <blackhole@devnull.com> - 2012-04-14 18:01 +0000
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-14 14:00 -0700
Re: Indirect Bit Anne & Lynn Wheeler <lynn@garlic.com> - 2012-04-14 20:58 -0400
Re: Indirect Bit "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-04-16 09:57 -0700
Re: Indirect Bit timcaffrey@aol.com (Tim McCaffrey) - 2012-04-20 23:19 +0000
Re: Indirect Bit "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-04-16 08:50 -0700
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-16 18:09 +0100
Re: Indirect Bit Andrew Reilly <areilly.---@bigpond.net.au> - 2012-04-16 23:19 +0000
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-17 09:20 +0100
Re: Indirect Bit Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-04-17 12:49 +0200
Re: Indirect Bit Andrew Reilly <areilly.---@bigpond.net.au> - 2012-04-17 12:40 +0000
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-18 12:01 +0100
Re: Indirect Bit anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-17 12:34 +0000
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-17 09:10 -0700
Re: Indirect Bit Andrew Reilly <areilly.---@bigpond.net.au> - 2012-04-17 22:05 +0000
Re: Indirect Bit jgk@panix.com (Joe keane) - 2012-04-19 19:37 +0000
Re: Indirect Bit torbenm@diku.dk (Torben Ægidius Mogensen) - 2012-04-20 11:10 +0200
Re: Indirect Bit Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-04-20 11:24 +0200
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-20 15:01 +0100
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-20 15:03 +0100
Re: Indirect Bit Michael S <already5chosen@yahoo.com> - 2012-04-20 08:01 -0700
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-20 16:35 +0100
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-18 11:10 -0700
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-18 15:37 -0700
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-16 11:21 -0700
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-16 19:36 +0100
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-18 11:17 -0700
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-18 15:33 -0700
Re: Indirect Bit Andreas Eder <andreas_eder@gmx.net> - 2012-04-19 00:29 +0200
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-19 10:50 +0100
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-19 11:29 -0700
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-19 21:39 +0100
Re: Indirect Bit EricP <ThatWouldBeTelling@thevillage.com> - 2012-04-20 15:14 -0400
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-20 22:43 -0700
Re: Indirect Bit EricP <ThatWouldBeTelling@thevillage.com> - 2012-04-21 17:14 -0400
Re: Indirect Bit Robert Wessel <robertwessel2@yahoo.com> - 2012-04-21 19:47 -0500
Re: Indirect Bit Nomen Nescio <nobody@dizum.com> - 2012-04-22 10:45 +0200
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-22 09:57 +0100
Re: Indirect Bit Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-04-22 12:54 +0200
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-22 13:00 +0100
Re: Indirect Bit Nomen Nescio <nobody@dizum.com> - 2012-04-22 13:28 +0200
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-22 13:04 +0100
Re: Indirect Bit Fritz Wuehler <fritz@spamexpire-201204.rodent.frell.theremailer.net> - 2012-04-22 23:00 +0200
Re: Indirect Bit Anne & Lynn Wheeler <lynn@garlic.com> - 2012-04-22 18:05 -0400
Re: Indirect Bit glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-04-22 23:20 +0000
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-23 08:22 +0100
Re: Indirect Bit Michael S <already5chosen@yahoo.com> - 2012-04-22 03:56 -0700
Re: Indirect Bit EricP <ThatWouldBeTelling@thevillage.com> - 2012-04-22 12:28 -0400
Re: Indirect Bit Robert Wessel <robertwessel2@yahoo.com> - 2012-04-22 12:56 -0500
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-22 13:15 -0700
Re: Indirect Bit Nomen Nescio <nobody@dizum.com> - 2012-04-22 22:30 +0200
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-22 21:40 +0100
Re: Indirect Bit Robert Wessel <robertwessel2@yahoo.com> - 2012-04-22 17:15 -0500
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-23 08:26 +0100
Re: Indirect Bit Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2012-04-23 08:02 -0700
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-23 17:02 +0100
Re: Indirect Bit Fritz Wuehler <fritz@spamexpire-201204.rodent.frell.theremailer.net> - 2012-04-23 20:17 +0200
Re: Indirect Bit Robert Wessel <robertwessel2@yahoo.com> - 2012-04-23 13:07 -0500
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-22 13:16 -0700
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-23 13:14 -0700
Re: Indirect Bit Anne & Lynn Wheeler <lynn@garlic.com> - 2012-04-23 16:51 -0400
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-23 14:22 -0700
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-21 11:17 -0700
Re: Indirect Bit jacko <jackokring@gmail.com> - 2012-04-14 08:02 -0700
Page 7 of 7 — ← Prev page 1 2 3 4 5 6 [7]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2012-04-22 21:40 +0100 |
| Message-ID | <jn1qc5$pni$1@needham.csi.cam.ac.uk> |
| In reply to | #6606 |
In article <4d55a2d89ceee7dee6f37bab28e8c924@dizum.com>, Nomen Nescio <nobody@dizum.com> wrote: > >On IBM Packed decimal has always been a standard and highly used format. It works >great for monetary calcs. It is similar to what people know as BCD, but with a few >extras including opcodes that convert back and forth from display (zoned >decimal) to packed decimal. It's heavily optimized since it's used so much >in commerical programming. COBOL uses it heavily. I believe it's not catered >for in FORTRAN at all. Only Cobol, PL/I and possibly RPG. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2012-04-22 17:15 -0500 |
| Message-ID | <quv8p7tmmdmai0065aep1r2pdb321qls37@4ax.com> |
| In reply to | #6607 |
On Sun, 22 Apr 2012 21:40:37 +0100 (BST), nmm1@cam.ac.uk wrote: >In article <4d55a2d89ceee7dee6f37bab28e8c924@dizum.com>, >Nomen Nescio <nobody@dizum.com> wrote: >> >>On IBM Packed decimal has always been a standard and highly used format. It works >>great for monetary calcs. It is similar to what people know as BCD, but with a few >>extras including opcodes that convert back and forth from display (zoned >>decimal) to packed decimal. It's heavily optimized since it's used so much >>in commerical programming. COBOL uses it heavily. I believe it's not catered >>for in FORTRAN at all. > >Only Cobol, PL/I and possibly RPG. RPG definitely. Also a bunch of other languages implemented on mainframes, mainly because the type is so commonly used. IBM's C compiler even has packed decimal extensions.
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2012-04-23 08:26 +0100 |
| Message-ID | <jn307k$r03$1@needham.csi.cam.ac.uk> |
| In reply to | #6611 |
In article <quv8p7tmmdmai0065aep1r2pdb321qls37@4ax.com>, Robert Wessel <robertwessel2@yahoo.com> wrote: >On Sun, 22 Apr 2012 21:40:37 +0100 (BST), nmm1@cam.ac.uk wrote: >>In article <4d55a2d89ceee7dee6f37bab28e8c924@dizum.com>, >>Nomen Nescio <nobody@dizum.com> wrote: >>> >>>On IBM Packed decimal has always been a standard and highly used format. It works >>>great for monetary calcs. It is similar to what people know as BCD, but with a few >>>extras including opcodes that convert back and forth from display (zoned >>>decimal) to packed decimal. It's heavily optimized since it's used so much >>>in commerical programming. COBOL uses it heavily. I believe it's not catered >>>for in FORTRAN at all. >> >>Only Cobol, PL/I and possibly RPG. > >RPG definitely. Also a bunch of other languages implemented on >mainframes, mainly because the type is so commonly used. IBM's C >compiler even has packed decimal extensions. You might have a job picking that bunch :-) I don't recollect IBM's C compiler having it when I worked with IBM, but it might have done; I suspect that it was added later, though. The point is that the type was NOT heavily used outside its core market of financial accounting, and few other languages bothered with it. Admittedly, that was IBM's core business, but there were a fair number of other IBM compilers and LOTS of third-party ones. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <SFuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2012-04-23 08:02 -0700 |
| Message-ID | <jn3qub$u3t$1@dont-email.me> |
| In reply to | #6618 |
On 4/23/2012 12:26 AM, nmm1@cam.ac.uk wrote: snip > The point is that the > type was NOT heavily used outside its core market of financial > accounting, and few other languages bothered with it. Perhaps it is just a matter of terminology, but I would word it differently. It was used heavily wherever money (at least in the US with its decimal money system) was used. This included systems like payroll, sales, business analysis and forecasting, etc. Since most companies that were large enough to have an IBM computer had enough employees to have a payroll system at least, and most of them sell something, it was widely used. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2012-04-23 17:02 +0100 |
| Message-ID | <jn3uek$us5$1@needham.csi.cam.ac.uk> |
| In reply to | #6621 |
In article <jn3qub$u3t$1@dont-email.me>, Stephen Fuld <SFuld@Alumni.cmu.edu.invalid> wrote: > >> The point is that the >> type was NOT heavily used outside its core market of financial >> accounting, and few other languages bothered with it. > >Perhaps it is just a matter of terminology, but I would word it >differently. It was used heavily wherever money (at least in the US >with its decimal money system) was used. This included systems like >payroll, sales, business analysis and forecasting, etc. Since most >companies that were large enough to have an IBM computer had enough >employees to have a payroll system at least, and most of them sell >something, it was widely used. That made it important, heavily used, but not widely used. It was typically used only for a few, closely-related purposes and supported only by a few compilers. I can't remember all of the compilers IBM sold in the 1970s and 1980s, but it was not supported by IBM Algol, and I don't remember it being supported by ANY compiler for any language other than the three I mentioned. And there were hundreds, of which we used dozens, but I am not claiming that our usage was representative. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Fritz Wuehler <fritz@spamexpire-201204.rodent.frell.theremailer.net> |
|---|---|
| Date | 2012-04-23 20:17 +0200 |
| Message-ID | <2d4cc133d1da83f71bada90192fa389a@msgid.frell.theremailer.net> |
| In reply to | #6621 |
Stephen Fuld <SFuld@alumni.cmu.edu.invalid> wrote: > On 4/23/2012 12:26 AM, nmm1@cam.ac.uk wrote: > > > snip > > > > The point is that the > > type was NOT heavily used outside its core market of financial > > accounting, and few other languages bothered with it. > > > Perhaps it is just a matter of terminology, but I would word it > differently. It was used heavily wherever money (at least in the US > with its decimal money system) was used. This included systems like > payroll, sales, business analysis and forecasting, etc. Since most > companies that were large enough to have an IBM computer had enough > employees to have a payroll system at least, and most of them sell > something, it was widely used. > Yes it was and is one of the most heavily used portions of the instruction set. Just about every language except FORTRAN uses it!
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2012-04-23 13:07 -0500 |
| Message-ID | <aj5bp75nb8igjasgsu7h1lrfp19ur3tqk2@4ax.com> |
| In reply to | #6618 |
On Mon, 23 Apr 2012 08:26:44 +0100 (BST), nmm1@cam.ac.uk wrote:
>In article <quv8p7tmmdmai0065aep1r2pdb321qls37@4ax.com>,
>Robert Wessel <robertwessel2@yahoo.com> wrote:
>>On Sun, 22 Apr 2012 21:40:37 +0100 (BST), nmm1@cam.ac.uk wrote:
>>>In article <4d55a2d89ceee7dee6f37bab28e8c924@dizum.com>,
>>>Nomen Nescio <nobody@dizum.com> wrote:
>>>>
>>>>On IBM Packed decimal has always been a standard and highly used format. It works
>>>>great for monetary calcs. It is similar to what people know as BCD, but with a few
>>>>extras including opcodes that convert back and forth from display (zoned
>>>>decimal) to packed decimal. It's heavily optimized since it's used so much
>>>>in commerical programming. COBOL uses it heavily. I believe it's not catered
>>>>for in FORTRAN at all.
>>>
>>>Only Cobol, PL/I and possibly RPG.
>>
>>RPG definitely. Also a bunch of other languages implemented on
>>mainframes, mainly because the type is so commonly used. IBM's C
>>compiler even has packed decimal extensions.
>
>You might have a job picking that bunch :-) I don't recollect IBM's
>C compiler having it when I worked with IBM, but it might have done;
>I suspect that it was added later, though. The point is that the
>type was NOT heavily used outside its core market of financial
>accounting, and few other languages bothered with it. Admittedly,
>that was IBM's core business, but there were a fair number of other
>IBM compilers and LOTS of third-party ones.
I was thinking more of (small-ish) languages like Easytrieve, DYLACOR,
EARL...
There were dozens of those. Sure they were somewhat specialized, and
not much, if at all, implemented on other platforms, and not all of
them, were compiled, but they usually did support packed decimal.
But I agree, outside the business side of the S/370 user base it was
not heavily used, and usually had limited support. And these days
it's easy to forget there ever actually was a non-business group of
users for S/370.
Anyway, the C compiler has had packed decimal support for a number of
years. Some of it is hidden behind macros, but you can declare a
decimal type with:
#include <decimal.h>
...
decimal(10,2) x; // 10 digits, 2 decimal places
use decimal constants ("10.5D"), use decimal fields in ordinary C
statements, etc.
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2012-04-22 13:16 -0700 |
| Message-ID | <3e4a15fe-47d7-42e5-9306-55699606a690@v17g2000pbt.googlegroups.com> |
| In reply to | #6593 |
On Apr 22, 2:45 am, Nomen Nescio <nob...@dizum.com> wrote: > They also have had 128 bit formats since the S/360 days (late 1960s). Yes. Extended precision floating point was introduced on the System/ 360 Model 85. And, as noted, there was no divide instruction, that being done in software. John Savard
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <MitchAlsup@aol.com> |
|---|---|
| Date | 2012-04-23 13:14 -0700 |
| Message-ID | <1599778.2421.1335212097869.JavaMail.geo-discussion-forums@vbq19> |
| In reply to | #6605 |
On Sunday, April 22, 2012 3:16:50 PM UTC-5, Quadibloc wrote: > On Apr 22, 2:45 am, Nomen Nescio <nob...@dizum.com> wrote: > > > They also have had 128 bit formats since the S/360 days (late 1960s). > > Yes. Extended precision floating point was introduced on the System/ > 360 Model 85. And, as noted, there was no divide instruction, that > being done in software. We had been granted access to the machine room where a 360/67 an 1108, and several PDP machines were "kept away from the madding crowds' for practical useful student purposes. One night in 1973 we opend up the doors of the 360/67 and found 2 wires hanging, well marked as to what pins they should be attached (in that cabinet.) So, since it was 3:00 AM and no one was around and no jobs running, brought the machine to a quiessent point, attached the wires and ran diagnostics. The only thinigs that changesd wer that the 128-bit FP instructions now ran in microcode rather than as sowtware trap assists. Apparently IBM wanted several tens of thosands of dollars to enable instructions already present in the machines shipped. We disconnedted the wires and continues along out assigned duties. Mitch
[toc] | [prev] | [next] | [standalone]
| From | Anne & Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2012-04-23 16:51 -0400 |
| Message-ID | <m3vckqjho9.fsf@garlic.com> |
| In reply to | #6626 |
MitchAlsup <MitchAlsup@aol.com> writes: > We had been granted access to the machine room where a 360/67 an 1108, > and several PDP machines were "kept away from the madding crowds' for > practical useful student purposes. > > One night in 1973 we opend up the doors of the 360/67 and found 2 > wires hanging, well marked as to what pins they should be attached (in > that cabinet.) So, since it was 3:00 AM and no one was around and no > jobs running, brought the machine to a quiessent point, attached the > wires and ran diagnostics. The only thinigs that changesd wer that the > 128-bit FP instructions now ran in microcode rather than as sowtware > trap assists. > > Apparently IBM wanted several tens of thosands of dollars to enable > instructions already present in the machines shipped. > > We disconnedted the wires and continues along out assigned duties. early 70s saw transition from leased machines to purchase. there were all sort of things about lease charges based on use. back in the tab machine days ... paid higher lease for card reader that ran faster ... even though slow&fast reader were the same with different belts (there was scenario that running faster did require more maintenance). for overall system ... machines had "system meter" that determined monthly lease ... "system meter" ran whenever processor &/or channel were doing something. for the cp67-based online commerical offerrings there was quite a bit of work for 7x24 operations. early on wanted to have channel programs active to accept any incoming terminal characters ... but not wanting the "system meter" to run when nothing was actually happening (sort of chicken and egg ... needed to have actual use to justify leaving system up ... but systems had to be left up 7x24 in order to encourage off-shift & weekend use). other stuff was supporting operator-less and "dark room" operation. "prepare" channel program CCW would let the channel go idle (allowing "system meter" to coast to stop if nothing else going on) ... but still be able to kick things off when characters did start coming in. turns out that both processor and all channels had to be idle for at least 400milliseconds before "system meter" would coast to stop. some indication that MVS had a different cultural heritage and some of SRM design originated before transition from lease to purchase ... since it had a fixed timer wakeup every 400milliseconds ... which would have made sure that the "system meter" never came to a stop (even if there was otherwise absolutely nothing going on). -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2012-04-23 14:22 -0700 |
| Message-ID | <df390bb6-0ecc-4044-a0c7-4ffac9f2b464@k7g2000pbo.googlegroups.com> |
| In reply to | #6626 |
On Apr 23, 2:14 pm, MitchAlsup <MitchAl...@aol.com> wrote: > Apparently IBM wanted several tens of thosands of dollars to enable instructions already present in the machines shipped. Even in the present day, on System z products, IBM ships hardware that the customer has to pay extra to fully utilize, rather than trying to sell performance with minimum hardware costs and razor-thin margins. They're selling a premium-priced product, because it lets you use certain software which is valuable. John Savard
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <MitchAlsup@aol.com> |
|---|---|
| Date | 2012-04-21 11:17 -0700 |
| Message-ID | <1363666.388.1335032275734.JavaMail.geo-discussion-forums@yndm3> |
| In reply to | #6587 |
On Friday, April 20, 2012 2:14:31 PM UTC-5, EricP wrote: > The weirdness is because there is a silent conversion to > double (64 bits) on save, then back to long double on load. I would like to point out that this "wierdness" is exactly what the code sequences was designed to expose on machines that have those properties. Having the compiler "optimize" the wierdness away on machines that have this property is in no sense of the word "optimal". Mitch
[toc] | [prev] | [next] | [standalone]
| From | jacko <jackokring@gmail.com> |
|---|---|
| Date | 2012-04-14 08:02 -0700 |
| Message-ID | <8563569.1169.1334415728633.JavaMail.geo-discussion-forums@vbiz13> |
| In reply to | #6535 |
CISC is better simulated. To this end the best returns on RISC design are a fast call/return mechanism, using a specialized code return address stack, with pre-fetch and separate threading cache (T-cache). Using a link register just encourages altering the return stack as a dumping ground for non control flow data, and pollutes the return stack usefulness as an optimization source. It also allows effective speculative execution and subroutine prediction (non conditional branch prediction). If as some suggest, every fourth instruction is a branch, then 4 threads should be available for execution, and perhaps this avoids wasting resources on speculative execution. And a fifth thread to handle interrupts perhaps, or maybe any one of the four which is in a HALT state. A load store architecture does perform well, and allows fast separation of data fetch and retire instructions. Something like: load/store/alu/call as using the two low bits on a 32 bit aligned machine. Or maybe this wastes too much instruction space on direct addressed memory. Maybe some specialized registers are in order, maybe a base pointer, a user stack pointer, the hidden system return stack pointer. Cheers Jacko
[toc] | [prev] | [standalone]
Page 7 of 7 — ← Prev page 1 2 3 4 5 6 [7]
Back to top | Article view | comp.arch
csiph-web