| Author |
Message |
|
Glen Herrmannsfeld
#1 / 835
|
 A Dark Day...
Quote:
> >We had a VAX 11/780 with WCS, and Ron Hardin
> >coded the basic string operations for the C library using it.
> >It was somewhat faster, as I recall, but not enough to
> >overcome the nonstandard implementation aspects of
> >the compiler and library (e.g. same object programs
> >wouldn't work on the 11/750).
> That's pretty much a universal experience, I think. Looking for places
> that are so heavily used that a microcode hack is worth the effort is
> often a dead end. This is the message of RISC, after all.
Instructions similar to the C operations are now in the IBM ESA/390 and successor architectures. It might be that the S/370 implementations weren't so efficient. IBM software tended to use length fields on variable length data, instead of terminating with a special characters. Crossposting changed, unisys removed, asm370 added.
-- glen
|
| Wed, 23 Nov 2005 00:38:09 GMT |
|
 |
|
Randy Huds
#2 / 835
|
A Dark Day...
Quote: > That's pretty much a universal experience, I think. Looking for places
> that are so heavily used that a microcode hack is worth the effort is
> often a dead end. This is the message of RISC, after all.
In the late 70s, over 50% of many customers' mainframe CPU time was used in IERRCO00 (sort). IBM added the CFC and UPT instructions to put much of the work of sorting into microcode, with a huge gain for customers. The message of RISC was that rather than defining a powerful machine
language supported by a complex microode interpreter, it was better to have
the machine language close to the hardware, as most user programs were
written in compiled languages rather than assembler, and compilers didn't
generally take advantage of complex machine languages.
--
Randy Hudson (posting in comp.lang.asm370)
|
| Wed, 23 Nov 2005 03:13:08 GMT |
|
|
|
Brian Ingli
#3 / 835
|
A Dark Day... On Fri, 6 Jun 2003 19:13:08 +0000 (UTC) in
Quote:
>> That's pretty much a universal experience, I think. Looking for places
>> that are so heavily used that a microcode hack is worth the effort is
>> often a dead end. This is the message of RISC, after all.
>In the late 70s, over 50% of many customers' mainframe CPU time was used in
>IERRCO00 (sort). IBM added the CFC and UPT instructions to put much of the
>work of sorting into microcode, with a huge gain for customers.
Thought about 80% of customers used SyncSort instead of IBM [DF]sort anyhow? Noticed that the "new" instructions do the basic operations of a heap sort. Quote: >The message of RISC was that rather than defining a powerful machine
>language supported by a complex microode interpreter, it was better to have
>the machine language close to the hardware, as most user programs were
>written in compiled languages rather than assembler, and compilers didn't
>generally take advantage of complex machine languages.
Forcing compiler code generators to become a lot better at optimization of architecture and model dependent primitive hardware operations is a win how? Run time library routines often made good use of complex machine languages. Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
--
fake address use address above to reply
|
| Wed, 23 Nov 2005 11:21:35 GMT |
|
|
|
Randy Huds
#4 / 835
|
A Dark Day...
Quote: > Thought about 80% of customers used SyncSort instead of IBM
> [DF]sort anyhow?
IERRCO00 was the free predecessor of DFSort. It was embarassing to IBM that so many of their customers were willing to spend money to purchase a replacement for a utility IBM supplied for free. Later, after IBM unbundled its software, IO-related software was given a DF (device facility?) prefix. A new sort product was added in this class, a program product called DFSort. Quote: > Noticed that the "new" instructions do the basic operations of a heap
> sort.
Heaven forfend! No, the instructions simplify the implementation of a replacement-selection tree with minimal compare. Quote: > Forcing compiler code generators to become a lot better at
> optimization of architecture and model dependent primitive
> hardware operations is a win how? Run time library routines often
> made good use of complex machine languages.
Which means that the compiler has to pass the information to the library routine, and then make use of the result. All that linkage is overhead that could be avoided if the compiler generated the code itself instead of relying on a library routine. Not that I meant to walk in on an argument which has probably been argued
better on both sides in comp.arch, one of the groups this thread is
cross-posted to.
--
Randy Hudson
|
| Wed, 23 Nov 2005 13:49:30 GMT |
|
|
|
Anne & Lynn Wheele
#5 / 835
|
A Dark Day... Quote:
> Heaven forfend! No, the instructions simplify the implementation of a
> replacement-selection tree with minimal compare.
luther's radix stuff? ... he finally got them into hardware going on 10? years ago. past mention of luther's radix stuff: http://www.garlic.com/~lynn/98.html#19 S/360 operating systems geneaology http://www.garlic.com/~lynn/98.html#20 Reviving the OS/360 thread (Questions about OS/360) http://www.garlic.com/~lynn/2001.html#2 A new "Remember when?" period happening right now http://www.garlic.com/~lynn/2001h.html#73 Most complex instructions http://www.garlic.com/~lynn/2002.html#14 index searching http://www.garlic.com/~lynn/2002d.html#18 Mainframers: Take back the light (spotlight, that is) http://www.garlic.com/~lynn/2002q.html#10 radix sort http://www.garlic.com/~lynn/2003e.html#80 "Super-Cheap" Supercomputing http://www.garlic.com/~lynn/2003i.html#58 assembler performance superiority: a given --
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
|
| Wed, 23 Nov 2005 22:22:57 GMT |
|
|
|
jsav..
#6 / 835
|
A Dark Day...
: Instructions similar to the C operations are now in the IBM ESA/390 and : successor architectures. It might be that the S/370 implementations weren't : so efficient. IBM software tended to use length fields on variable length : data, instead of terminating with a special characters. Yes, and I think they did the right thing.
This meant that one could mix text and binary data in file I/O, and still
have one's data file composed of discrete records, without worrying about
a binary integer accidentally containing the code for "carriage return" or
"line feed".
The operating system also basically protected all other programs from
buffer overflows.
John Savard
|
| Thu, 24 Nov 2005 20:58:42 GMT |
|
|
|
Peter da Sil
#7 / 835
|
A Dark Day... Quote:
>This meant that one could mix text and binary data in file I/O, and still
>have one's data file composed of discrete records, without worrying about
>a binary integer accidentally containing the code for "carriage return" or
>"line feed".
I don't think that the instruction set and the file formats are related nearly so closely as that. After all, RSX on the PDP-11 used counted records in files, while UNIX used terminated records. They were both running on the same hardware. --
Rev. Peter da Silva, ULC. 29.6852N 95.5770W WWFD?
"Be conservative in what you generate, and liberal in what you accept"
-- Matthew 10:16 (l.trans)
|
| Thu, 24 Nov 2005 23:37:57 GMT |
|
|
|
Anne & Lynn Wheele
#8 / 835
|
A Dark Day...
Quote: > I don't think that the instruction set and the file formats are
> related nearly so closely as that. After all, RSX on the PDP-11
> used counted records in files, while UNIX used terminated records.
> They were both running on the same hardware.
and multics (implemented in PLI) and 360 generation had little or no buffer overflow exploits (aka the claim is that implicit length conventions and implementation reflected in C libraries and things implemented in C is the major contributor to buffer overflow vulnerabilities in the world today). in fact the 1974 air force study has claimed no buffer ovreflow exploits for multics. multics on ge (later honeywell) and single level store had very different operating system and hardware architecture from 360 genre. references to study:
http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
lots of references to vulnerabilities & exploits (including
various buffer overflows):
http://www.garlic.com/~lynn/subpubkey.html#fraud
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
|
| Fri, 25 Nov 2005 00:34:59 GMT |
|
|
|
Brian Ingli
#9 / 835
|
A Dark Day... On Sun, 08 Jun 2003 16:34:59 GMT in alt.folklore.computers, Anne
Quote:
>> I don't think that the instruction set and the file formats are >> related nearly so closely as that. After all, RSX on the PDP-11 >> used counted records in files, while UNIX used terminated records. >> They were both running on the same hardware. >and multics (implemented in PLI) and 360 generation had little or no
>buffer overflow exploits (aka the claim is that implicit length
>conventions and implementation reflected in C libraries and things
>implemented in C is the major contributor to buffer overflow
>vulnerabilities in the world today). in fact the 1974 air force study
>has claimed no buffer ovreflow exploits for multics. multics on ge
>(later honeywell) and single level store had very different operating
>system and hardware architecture from 360 genre.
Bad programming (practices) are the reason there are any vulnerabilities, buffer overflow or otherwise. Maybe it's time programnmers got fired for not checking lengths and return codes? We've had separate I&D spaces available on hardware since the bigger PDP-11s, and execute bits since paging was implemented, but how many OS implementations use them to stop data being executable! Maybe it's time systems programmers got fired for not keeping data non-executable? Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
--
fake address use address above to reply
|
| Fri, 25 Nov 2005 03:23:19 GMT |
|
|
|
Charles Richmon
#10 / 835
|
A Dark Day... Quote:
> : Instructions similar to the C operations are now in the IBM ESA/390 and
> : successor architectures. It might be that the S/370 implementations weren't
> : so efficient. IBM software tended to use length fields on variable length
> : data, instead of terminating with a special characters.
One thing that our college's IBM/370-155 lacked in 1978, was an instruction to convert an integer to a floating point number. To do this required a small subroutine... --
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+
|
| Fri, 25 Nov 2005 03:42:51 GMT |
|
|
|
Anne & Lynn Wheele
#11 / 835
|
A Dark Day... Quote:
> One thing that our college's IBM/370-155 lacked in 1978, was an
> instruction to convert an integer to a floating point number.
> To do this required a small subroutine...
but 360/370 did have CVB (convert to binary) and CVD (convert to decimal) instructions ... somewhat more oriented towards commercial market(? ... as well as all the straight packed decimal operations). http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/7... http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/7... the above CVB & CVD instruction refs are taken from the z/architecture
... so the 64-bit version of the instructions are included.
and for something really different ... they now have convert unicode
to UTF-8 and UTF-8 to UNICODE hardware instructions:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/7...
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/7...
and they now have hardware covert to/from binary floating point and
hexadecimal floating point formats
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/9...
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/9...
current floating point overview:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/9...
and finally, they now have convert from fixed and convert to fixed hardware
instructions
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/9...
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/9...
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
|
| Fri, 25 Nov 2005 04:12:27 GMT |
|
|
|
Anne & Lynn Wheele
#12 / 835
|
A Dark Day... oops, and the convert from/to fixed instruction detailed hardware
descriptions
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/1...
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR001/1...
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
|
| Fri, 25 Nov 2005 04:15:53 GMT |
|
|
|
Paul DeMon
#13 / 835
|
A Dark Day... Quote:
> [...]
> Bad programming (practices) are the reason there are any
> vulnerabilities, buffer overflow or otherwise. Maybe it's time
> programnmers got fired for not checking lengths and return codes?
> We've had separate I&D spaces available on hardware since the
> bigger PDP-11s, and execute bits since paging was implemented,
> but how many OS implementations use them to stop data being
> executable! Maybe it's time systems programmers got fired for not
> keeping data non-executable?
That's fine in theory but one person's more secure system software is another
two "I" words, incompatible seems to be bigger sales poison than insecure. Until that changes, perhaps on the demand side by more aware buyers, perhaps on the supply side through reduced product liability shielding of the
software
industry, I doubt we will ever see much change.
--
Paul W. DeMone The 801 experiment SPARCed an ARMs race of EPIC
Kanata, Ontario proportions to put more PRECISION and POWER into
that ends well.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
|
| Fri, 25 Nov 2005 08:34:29 GMT |
|
|
|
Peter Flas
#14 / 835
|
A Dark Day... Quote:
> Bad programming (practices) are the reason there are any
> vulnerabilities, buffer overflow or otherwise.
Yes, but there are languages that encourage bad programming and languages that discourage it. It *is* possible to write PL/I code to cause buffer overflows, but you really have to work at it. In C, you have to work at least as hard to avoid them. That's not just my thinking, the Multics retrospective paper published last year says this flat out.
|
| Fri, 25 Nov 2005 08:36:09 GMT |
|
|
|
Mark Crispi
#15 / 835
|
A Dark Day... Quote:
> That's fine in theory but one person's more secure system software is
> another
the way." One of the flames against TOPS-20 was that you had to have a privilege to
be permitted to send non-TCP packets or listen on port numbers lower than
256 (this was in the days when everybody knew that system server port
numbers would never get that high...).
In a futile attempt at pacifying the demand, I wrote support to allow
unprivileged UDP client access; but that didn't help.
I suspect that even in today's day of personal machines, the world would
be a less vulnerable place if unprivileged user programs didn't have
unrestained access to send any kind of packet.
Quote: > Of the
> two "I" words, incompatible seems to be bigger sales poison than insecure.
There is no doubt about that. Quote: > Until that changes, perhaps on the demand side by more aware buyers, perhaps
> on the supply side through reduced product liability shielding of the
> software
> industry, I doubt we will ever see much change.
Be careful about what you wish for. The loss of product liability shielding of the software industry may come back to haunt those individuals who lobby for it. -- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
|
| Fri, 25 Nov 2005 09:59:38 GMT |
|
| |
