A Dark Day... 
Author Message
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 
 [ 835 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56]

 Relevant Pages 

1. Welcome To Another Dark Day on this World

2. Day of year- the day number

3. File Day, System Day

4. DAY OF THE WEEK ROUTINE - day-week.txt (1/1)

5. DAY OF THE WEEK ROUTINE - day-week.txt (0/1)

6. utime-to-days, days-to-utime

7. lisp as a day to day language

8. Art and all that Jazz: the frames, shirts, and jackets are all dark and bizarre

9. About Static texts on the dark side...

10. How do you make rpt check boxes darker

11. LFN support - other than Dark Black?

12. Light & Dark library help

 

 
Powered by phpBB® Forum Software