campbell@redsox.bsw.com (Larry Campbell) (04/16/91)
Why is it (he wonders out loud) that the only machines on which people still (in this day and age) seem to use assembly language are IBM 360s? I can't remember who said this, but it's apropos: "Programming in assembly language is like digging postholes with a teaspoon. Sure, it takes longer, but you have complete control over every spoon of dirt." Is it just because IBM doesn't ship any decent compilers? I mean, what am I missing? Why do people put up with this stuff? -- Larry Campbell The Boston Software Works, Inc., 120 Fulton Street campbell@redsox.bsw.com Boston, Massachusetts 02109 (USA)
dave@visual1.jhuapl.edu (Dave Weintraub) (04/16/91)
In article <1991Apr16.004355.22971@redsox.bsw.com>, campbell@redsox.bsw.com (Larry Campbell) writes: |> Why is it (he wonders out loud) that the only machines on which people still |> (in this day and age) seem to use assembly language are IBM 360s? |> |> I can't remember who said this, but it's apropos: "Programming in assembly |> language is like digging postholes with a teaspoon. Sure, it takes longer, |> but you have complete control over every spoon of dirt." |> |> Is it just because IBM doesn't ship any decent compilers? I mean, what |> am I missing? Why do people put up with this stuff? |> -- |> Larry Campbell The Boston Software Works, Inc., 120 Fulton Street |> campbell@redsox.bsw.com Boston, Massachusetts 02109 (USA) Well, gee, Larry. I guess the articles I've seen in Computer Language, etc., for Assembler on PCs must be written by mainframe types (and, of course, Connection Machine PARIS, which is, for all intents and most purposes, its Assembler, is not called Assembler, so it doesn't count). One might as well ask why people use low-level compiled languages (like FORTRAN or C) when there are so many higher level languages around (APL2, REXX). IBM's compilers are perfectly decent, though sometimes conservative. The problem is that there are times when Assembler is the best choice: 1) Efficiency and control of data structures. 2) Coding of user exits. 3) Use of machine instructions and special features which still haven't made it into the high-level interfaces, or which may be difficult to describe in terms of high-level approaches. 4) Some of us can code (and debug) in Assembler at speeds greater than others (or we) can code in higher-level languages. These are just off the top of my head. We try to choose the most appropriate tools for the job. Dave.
news@ucf1vm.BITNET (04/16/91)
In article <1991Apr16.004355.22971@redsox.bsw.com>, campbell@redsox.bsw.com (Larry Campbell) writes: |> Why is it (he wonders out loud) that the only machines on which people still |> (in this day and age) seem to use assembly language are IBM 360s? |> |> I can't remember who said this, but it's apropos: "Programming in assembly |> language is like digging postholes with a teaspoon. Sure, it takes longer, |> but you have complete control over every spoon of dirt." |> |> Is it just because IBM doesn't ship any decent compilers? I mean, what |> am I missing? Why do people put up with this stuff? |> -- |> Larry Campbell The Boston Software Works, Inc., 120 Fulton Street |> campbell@redsox.bsw.com Boston, Massachusetts 02109 (USA) Well, gee, Larry. I guess the articles I've seen in Computer Language, etc., for Assembler on PCs must be written by mainframe types (and, of course, Connection Machine PARIS, which is, for all intents and most purposes, its Assembler, is not called Assembler, so it doesn't count). One might as well ask why people use low-level compiled languages (like FORTRAN or C) when there are so many higher level languages around (APL2, REXX). IBM's compilers are perfectly decent, though sometimes conservative. The problem is that there are times when Assembler is the best choice: 1) Efficiency and control of data structures. 2) Coding of user exits. 3) Use of machine instructions and special features which still haven't made it into the high-level interfaces, or which may be difficult to describe in terms of high-level approaches. 4) Some of us can code (and debug) in Assembler at speeds greater than others (or we) can code in higher-level languages. These are just off the top of my head. We try to choose the most appropriate tools for the job. Dave.
dandrews@bilver.uucp (Dave Andrews) (04/17/91)
In article <1991Apr16.004355.22971@redsox.bsw.com> campbell@redsox.bsw.com (Larry Campbell) writes: >Why is it (he wonders out loud) that the only machines on which people still >(in this day and age) seem to use assembly language are IBM 360s? > [ text deleted ] >Is it just because IBM doesn't ship any decent compilers? I mean, what >am I missing? Why do people put up with this stuff? Speaking for some of us MVS persons, there are access methods and supervisor services and exit points that are ONLY available to assembly language users. Some of this is because there have been some fairly recent architectural changes to the S/360 line that the high-level-language guys haven't caught up on, but mostly it is due to inertia, plain and simple. SAS Institute has a C compiler that is purported to be suitable for systems programming, and IBM has announced that their own C compiler can do the same trick. Basically, if you use a severely restricted subset of functions, you don't have to have the runtime libraries available. Still and all, it is a trick. Control blocks have to be interpreted in your favorite HLL, and their formats are changeable and delivered only in - you guessed it - assembly language DSECTs. The SAS product claims to be able to fairly automatically translate DSECTs into structures, but I don't think this works very well. NOTE: I haven't used their system, but studied the documentation when it first came out. BTW, assembly language is used elsewhere. You cannot do systems stuff for Mess-DOS machines in C without being able to appreciate the code that is being generated for you. Yes, it is an unwholesome mess, but it keeps me employed. - David Andrews tarpit!bilver!dandrews
news@ucf1vm.BITNET (04/17/91)
In article <1991Apr16.004355.22971@redsox.bsw.com> campbell@redsox.bsw.com (Larry Campbell) writes: >Why is it (he wonders out loud) that the only machines on which people still >(in this day and age) seem to use assembly language are IBM 360s? > [ text deleted ] >Is it just because IBM doesn't ship any decent compilers? I mean, what >am I missing? Why do people put up with this stuff? Speaking for some of us MVS persons, there are access methods and supervisor services and exit points that are ONLY available to assembly language users. Some of this is because there have been some fairly recent architectural changes to the S/360 line that the high-level-language guys haven't caught up on, but mostly it is due to inertia, plain and simple. SAS Institute has a C compiler that is purported to be suitable for systems programming, and IBM has announced that their own C compiler can do the same trick. Basically, if you use a severely restricted subset of functions, you don't have to have the runtime libraries available. Still and all, it is a trick. Control blocks have to be interpreted in your favorite HLL, and their formats are changeable and delivered only in - you guessed it - assembly language DSECTs. The SAS product claims to be able to fairly automatically translate DSECTs into structures, but I don't think this works very well. NOTE: I haven't used their system, but studied the documentation when it first came out. BTW, assembly language is used elsewhere. You cannot do systems stuff for Mess-DOS machines in C without being able to appreciate the code that is being generated for you. Yes, it is an unwholesome mess, but it keeps me employed. - David Andrews tarpit!bilver!dandrews
schales@neuron.tamu.edu (Douglas Lee Schales) (04/17/91)
In article <1991Apr16.161743.494@aplcen.apl.jhu.edu> dave@visual1.jhuapl.edu (Dave Weintraub) writes: In article <1991Apr16.004355.22971@redsox.bsw.com>, campbell@redsox.bsw.com (Larry Campbell) writes: |> Why is it (he wonders out loud) that the only machines on which people still |> (in this day and age) seem to use assembly language are IBM 360s? > The problem is that there are times when Assembler is the best choice: > > [ reasons deleted ] > The most important reason: Programming in 370 Assembly is FUN! Doug. -- +---------------------------+ | Douglas Lee Schales | | schales@cs.tamu.edu | | Dept. of Computer Science | | Texas A&M University | +---------------------------+
schales@helios.UUCP (Douglas Lee Schales) (04/17/91)
In article <1991Apr16.161743.494@aplcen.apl.jhu.edu> dave@visual1.jhuapl.edu (Dave Weintraub) writes: In article <1991Apr16.004355.22971@redsox.bsw.com>, campbell@redsox.bsw.com (Larry Campbell) writes: |> Why is it (he wonders out loud) that the only machines on which people still |> (in this day and age) seem to use assembly language are IBM 360s? > The problem is that there are times when Assembler is the best choice: > > [ reasons deleted ] > The most important reason: Programming in 370 Assembly is FUN! Doug. -- +---------------------------+ | Douglas Lee Schales | | schales@cs.tamu.edu | | Dept. of Computer Science | | Texas A&M University | +---------------------------+
seb1525@mvs.draper.COM ("Stephen E. Bacher") (04/17/91)
>In article <1991Apr16.161743.494@aplcen.apl.jhu.edu> dave@visual1.jhuapl.edu > (Dave Weintraub) writes: > In article <1991Apr16.004355.22971@redsox.bsw.com>, campbell@redsox.bsw.com > (Larry Campbell) writes: > |> Why is it (he wonders out loud) that the only machines on which people > still > |> (in this day and age) seem to use assembly language are IBM 360s? > >> The problem is that there are times when Assembler is the best choice: >> >> [ reasons deleted ] >> > >The most important reason: > >Programming in 370 Assembly is FUN! > >Doug. >-- Here's some more: Other operating systems (i.e. UNIX) were designed so that folks could interface to it in C. IBM 3*0 operatings systems were designed so that normal folks couldn't talk to it in a high-level language at all. Consider MVS. Two of the most important data access formats are PDS's and VSAM. One is thoroughly supported by TSO and ISPF, but you can't program to it in any HLL worth a damn. The other is programmable from high-level languages up the wazoo, but no TSO/ISPF interfaces will touch it. With this kind of bizarre attitude about its own data, how can you expect IBM to spawn anything but proficient assembler coders? Even access to the basic components of the user interface (TSO) are available only from assembler. Also, there hasn't been a generally available decent C compiler on IBM/3*0 up till now. (Maybe C/370 V2 will change that, especially with its new no-run-time-library optuon.) - Batchman
RKOGUT@BROWNVM.BITNET ("R. Kogut") (04/18/91)
>Why do people seem to write assembler code primarily on /360? (paraphrase)
One reason might be that 360 machine language is straightforward and easy
to use compared to Intel architecture and even more so compared to RISC
architecture. For some applications, it can be more compact than C. I remember
trying to port a C program and giving up and writing it more quickly in
assembler. I'm not saying that this is the general case, but it does happen,
especially if you are dealing with fixed length character strings which
usually require one 360 machine instruction to handle rather than a function
call in C. Also, assembler language can be easier to debug, since you don't
have to worry about compiler errors (yes, I've run into them and just having
to consider the possibility of one occuring costs time) and it's easier to
trace an assembler program you've written yourself with meaningful labels
for everything than to follow an assembler listing generated by a compiler.
Although some people will use a particular language for 'religious' reasons,
if a lot of people are using one, there's probably a reason.a10jaa8@MP.CS.NIU.EDU (Joe Adamo) (04/19/91)
> >The most important reason: > >Programming in 370 Assembly is FUN! > Yeah, it's pretty cool, but don't let too many people here you say that! They might think you're crazy! Joe Adamo a10jaa8@mp.cs.niu.edu
phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) (04/19/91)
campbell@redsox.bsw.com (Larry Campbell) writes: >Why is it (he wonders out loud) that the only machines on which people still >(in this day and age) seem to use assembly language are IBM 360s? There is programming on IBM PC's. >I can't remember who said this, but it's apropos: "Programming in assembly >language is like digging postholes with a teaspoon. Sure, it takes longer, >but you have complete control over every spoon of dirt." It depends on WHAT KIND OF HOLE you are digging. A posthole is NOT an appropriate kind of hole to use a teaspoon on, but an archeological dig could be. I'm not saying that ALL uses of assembler are appropriate, but some are. >Is it just because IBM doesn't ship any decent compilers? I mean, what >am I missing? Why do people put up with this stuff? In many cases the compilers generate far less than optimal code for an application where speed is essential (loops that run billions of times). In other cases the provided high level language libraries are deficient. I notice that very very little assembler language programming is done on UNIX systems. In part this is due to the fact that UNIX makes it easy to do system level functions in C and other languages. But there is also the draw to make a program portable and that draw is enhanced by the fact that it really is easy to do within UNIX platforms. When developing code for VM/CMS or MS-DOS, for instance, you know the assembler code is going to work on the intended platforms anyway. I believe it is a combination of poor compilers, poor run time libraries, and weak operating systems. For instance a couple years ago I was experimenting with the Mandlebrot set. I wrote the iteration in FORTRAN and had it optimized. I looked at the code it generated and saw it using an excess of load and store operations that I was sure were not needed. So I tried to code it entirely in registers. It was not that easy because as it turned out, the results from one iteration resulted in a couple of the values transposed in a pair of registers. But I just simply coded a pair of interations with the second one working with the registers swapped in context. Here is the code I wrote for the Mandelbrot set power raising loop. All intermediate values are in registers and the memory references that are present are just contants. The code ran about twice as fast as that generated by the FORTRAN VS compiler with optimization (which suggests that registers are still faster than cache). ITERATE DS 0H <<< here to iterate one point *********************************************************************** LDR FPR4,FPR2 y MDR FPR4,FPR0 x*y ADR FPR4,FPR4 2*x*y AD FPR4,Q Y = 2*x*y + Q MDR FPR0,FPR0 x**2 MDR FPR2,FPR2 y**2 LDR FPR6,FPR0 (x**2) ADR FPR6,FPR2 (x**2+y**2) CD FPR6,ESC diverging? BCR HIGH,R7 yes --> SDR FPR0,FPR2 x**2 - y**2 AD FPR0,P X = x**2 - y**2 + P ALR R6,R1 count *********************************************************************** LDR FPR2,FPR4 Y MDR FPR2,FPR0 X*Y ADR FPR2,FPR2 2*X*Y AD FPR2,Q y = 2*X*Y + Q MDR FPR0,FPR0 X**2 MDR FPR4,FPR4 Y**2 LDR FPR6,FPR0 (x**2) ADR FPR6,FPR4 (x**2+y**2) CD FPR6,ESC diverging? BCR HIGH,R7 yes --> SDR FPR0,FPR4 X**2 - Y**2 AD FPR0,P x = X**2 - Y**2 + P ALR R6,R1 count *********************************************************************** BCT R3,ITERATE --> go again if needed BR R7 all done now --> -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! / \***************************************************************************/
news@ucf1vm.BITNET (04/19/91)
campbell@redsox.bsw.com (Larry Campbell) writes: >Why is it (he wonders out loud) that the only machines on which people still >(in this day and age) seem to use assembly language are IBM 360s? There is programming on IBM PC's. >I can't remember who said this, but it's apropos: "Programming in assembly >language is like digging postholes with a teaspoon. Sure, it takes longer, >but you have complete control over every spoon of dirt." It depends on WHAT KIND OF HOLE you are digging. A posthole is NOT an appropriate kind of hole to use a teaspoon on, but an archeological dig could be. I'm not saying that ALL uses of assembler are appropriate, but some are. >Is it just because IBM doesn't ship any decent compilers? I mean, what >am I missing? Why do people put up with this stuff? In many cases the compilers generate far less than optimal code for an application where speed is essential (loops that run billions of times). In other cases the provided high level language libraries are deficient. I notice that very very little assembler language programming is done on UNIX systems. In part this is due to the fact that UNIX makes it easy to do system level functions in C and other languages. But there is also the draw to make a program portable and that draw is enhanced by the fact that it really is easy to do within UNIX platforms. When developing code for VM/CMS or MS-DOS, for instance, you know the assembler code is going to work on the intended platforms anyway. I believe it is a combination of poor compilers, poor run time libraries, and weak operating systems. For instance a couple years ago I was experimenting with the Mandlebrot set. I wrote the iteration in FORTRAN and had it optimized. I looked at the code it generated and saw it using an excess of load and store operations that I was sure were not needed. So I tried to code it entirely in registers. It was not that easy because as it turned out, the results from one iteration resulted in a couple of the values transposed in a pair of registers. But I just simply coded a pair of interations with the second one working with the registers swapped in context. Here is the code I wrote for the Mandelbrot set power raising loop. All intermediate values are in registers and the memory references that are present are just contants. The code ran about twice as fast as that generated by the FORTRAN VS compiler with optimization (which suggests that registers are still faster than cache). ITERATE DS 0H <<< here to iterate one point *********************************************************************** LDR FPR4,FPR2 y MDR FPR4,FPR0 x*y ADR FPR4,FPR4 2*x*y AD FPR4,Q Y = 2*x*y + Q MDR FPR0,FPR0 x**2 MDR FPR2,FPR2 y**2 LDR FPR6,FPR0 (x**2) ADR FPR6,FPR2 (x**2+y**2) CD FPR6,ESC diverging? BCR HIGH,R7 yes --> SDR FPR0,FPR2 x**2 - y**2 AD FPR0,P X = x**2 - y**2 + P ALR R6,R1 count *********************************************************************** LDR FPR2,FPR4 Y MDR FPR2,FPR0 X*Y ADR FPR2,FPR2 2*X*Y AD FPR2,Q y = 2*X*Y + Q MDR FPR0,FPR0 X**2 MDR FPR4,FPR4 Y**2 LDR FPR6,FPR0 (x**2) ADR FPR6,FPR4 (x**2+y**2) CD FPR6,ESC diverging? BCR HIGH,R7 yes --> SDR FPR0,FPR4 X**2 - Y**2 AD FPR0,P x = X**2 - Y**2 + P ALR R6,R1 count *********************************************************************** BCT R3,ITERATE --> go again if needed BR R7 all done now --> -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! / \***************************************************************************/
rickert@mp.cs.niu.edu (Neil Rickert) (04/20/91)
In article <9104190111.AA00321@ucbvax.Berkeley.EDU> <phil@ux1.cso.uiuc.edu> writes: >I notice that very very little assembler language programming is done on >UNIX systems. In part this is due to the fact that UNIX makes it easy to >do system level functions in C and other languages. But there is also the And in part this is due to the fact that the system features you would use assembler programming on in say MVS do not even exist in Unix. (I think for example of the ENQ/DEQ functions for interprocess synchronization, or the ability to create channel programs for a device not yet supported by the operating system). >it really is easy to do within UNIX platforms. When developing code for >VM/CMS or MS-DOS, for instance, you know the assembler code is going to work >on the intended platforms anyway. I believe it is a combination of poor >compilers, poor run time libraries, and weak operating systems. > >For instance a couple years ago I was experimenting with the Mandlebrot set. >I wrote the iteration in FORTRAN and had it optimized. I looked at the When it comes to optimization, things are not always what they seem. I remember a few years writing the same program in Assembler, PL/I, and FORTRAN. I looked at the generated code for each compiler. Like all compiler generated code it looked pretty cruddy. But in the innermost loop my hand optimized assembler code had only one less instruction than the FORTRAN code (at that time using the H-extended compiler with maximum optimization). The PL/I code had more than twice as many instructions in the innermost loop. I also remember a few years ago talking to someone at a highly Unix oriented company which happened to also run a large IBM/MVS shop. I thought this was strange, so I questionned it. The reply was that FORTRAN was used in their chip design software, and no Unix FORTRAN compiler came close to matching the optimization provided by the IBM compiler. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
rickert@MP.CS.NIU.EDU (Neil Rickert) (04/20/91)
In article <9104190111.AA00321@ucbvax.Berkeley.EDU> <phil@ux1.cso.uiuc.edu> writes: >I notice that very very little assembler language programming is done on >UNIX systems. In part this is due to the fact that UNIX makes it easy to >do system level functions in C and other languages. But there is also the And in part this is due to the fact that the system features you would use assembler programming on in say MVS do not even exist in Unix. (I think for example of the ENQ/DEQ functions for interprocess synchronization, or the ability to create channel programs for a device not yet supported by the operating system). >it really is easy to do within UNIX platforms. When developing code for >VM/CMS or MS-DOS, for instance, you know the assembler code is going to work >on the intended platforms anyway. I believe it is a combination of poor >compilers, poor run time libraries, and weak operating systems. > >For instance a couple years ago I was experimenting with the Mandlebrot set. >I wrote the iteration in FORTRAN and had it optimized. I looked at the When it comes to optimization, things are not always what they seem. I remember a few years writing the same program in Assembler, PL/I, and FORTRAN. I looked at the generated code for each compiler. Like all compiler generated code it looked pretty cruddy. But in the innermost loop my hand optimized assembler code had only one less instruction than the FORTRAN code (at that time using the H-extended compiler with maximum optimization). The PL/I code had more than twice as many instructions in the innermost loop. I also remember a few years ago talking to someone at a highly Unix oriented company which happened to also run a large IBM/MVS shop. I thought this was strange, so I questionned it. The reply was that FORTRAN was used in their chip design software, and no Unix FORTRAN compiler came close to matching the optimization provided by the IBM compiler. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) (04/20/91)
rickert@mp.cs.niu.edu (Neil Rickert) writes: >In article <9104190111.AA00321@ucbvax.Berkeley.EDU> <phil@ux1.cso.uiuc.edu> writes: >>I notice that very very little assembler language programming is done on >>UNIX systems. In part this is due to the fact that UNIX makes it easy to >>do system level functions in C and other languages. But there is also the > And in part this is due to the fact that the system features you would use >assembler programming on in say MVS do not even exist in Unix. (I think >for example of the ENQ/DEQ functions for interprocess synchronization, or >the ability to create channel programs for a device not yet supported by >the operating system). UNIX does have syncronization facilities. But these facilities are different in ways that reflect the nature of what UNIX is. For instance if you want to make sure that you don't end up with TWO processes concurrently trying to work on some sharable resource, you need to syncronize the processes in some way. UNIX does in fact need to do this, and has a means to do so. More often than not (outside of the kernel) the sharable resource is a file or device. Thus it makes sense to have a mechanism to lock files (devices are accessed via the file space in UNIX) directly. But if you need to share something else besides a file, it's no big deal to make up a null file and lock on it anyway and this is readily done in C (though not so readily in shell scripts I have found out). Channel programming is needed more than it should be needed. IBM has always taken an approach to passing much of the detail of device control to the application in its operating systems. Applications have to typically at least deal with things like the block size (and you have OPEN exits in MVS and CMS to let you do it in assembler). UNIX takes the opposite approach. You never (very rarely anyway) need to deal with a disk blocksize just to do I/O to a file. You need to when dealing with tape because of the nature of the data, but even then you can get away without dealing with it when sharing data with another UNIX application that has done so. My point is that assembler is easier on some systems, and it is NEEDED on some systems, and it is NO coincindence that these happen to be the SAME systems. > When it comes to optimization, things are not always what they seem. I >remember a few years writing the same program in Assembler, PL/I, and >FORTRAN. I looked at the generated code for each compiler. Like all >compiler generated code it looked pretty cruddy. But in the innermost >loop my hand optimized assembler code had only one less instruction than >the FORTRAN code (at that time using the H-extended compiler with maximum >optimization). The PL/I code had more than twice as many instructions in >the innermost loop. For many things I have found this to be the case as well. I've learned to recognize when it does me no good to use assembler instead of Fortran. Still in other cases it makes a big difference. Since we are bashing PL/1 I might mention a program a friend of mine wrote. He wanted to take each byte in a file and reverse the order of the bits. He did this the "obvious" way in PL/1 by defining a bit structure and taking each bit out one by one and putting them back in another one in reverse order. He discovered that his program ran "horribly" slow. It processed a file of 1000 80-byte records in about 75 seconds of CPU time on a 370/158. I wrote the same thing in aseembler. Not knowing the linkage to PL/1 at the time (due to lack of documentation for students, which is another issue) I wrote the whole thing in assembler using TR. It took less than 1 second. Doubling the size of the file didn't even seen to affect the time, so I suspect it was running under the "noise". BTW, looking back at my days as a student, I realize that in those cases where there was a lack of documentation, I ended up working around the problem by doing things in ways that would not make sense in a professional environment. It took a while to UNLEARN all the wrong things I learned in school just because someone in the computer center was paranoid about me "learning too much" about the system and keeping back documentation. I would really like to stamp out that attitude. There are times when assembler is appropriate and there are times when it is not. Students should be allowed to learn what these are. > I also remember a few years ago talking to someone at a highly Unix oriented >company which happened to also run a large IBM/MVS shop. I thought this >was strange, so I questionned it. The reply was that FORTRAN was used in >their chip design software, and no Unix FORTRAN compiler came close to >matching the optimization provided by the IBM compiler. The Fortran compiler is the toughest one to beat. It *IS* beatable by good assembler programmers, but the benefits of trying to do so are reduced now because: 1. The margin is getting narrower with better compilers. 2. Processors are caching better making the difference between good code and bad code smaller. 3. You just can't justify doing this with 1,000 to 100,000 line Fortran applications anyway. So you probably want to stick with optimizing the bottlenecks ONLY, once you determine where they are. More often a good choice of mathematical algorithm can improve things more than rewriting in assembler, depending on the scale of the problem and the machine. For instance there is a way to do a 2x2 matrix multiply with only 7 instead of 8 multiply instructions, at the cost of doing a few (5 I think) extra additions. You can recursively extend this to larger matrices with eventually a tremendous speedup. But this is only going to do you any good when a multiply costs more than an add. Some chips are now doing BOTH in one cycle. -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! / \***************************************************************************/
phil@UX1.CSO.UIUC.EDU (Phil Howard KA9WGN) (04/20/91)
rickert@mp.cs.niu.edu (Neil Rickert) writes: >In article <9104190111.AA00321@ucbvax.Berkeley.EDU> <phil@ux1.cso.uiuc.edu> writes: >>I notice that very very little assembler language programming is done on >>UNIX systems. In part this is due to the fact that UNIX makes it easy to >>do system level functions in C and other languages. But there is also the > And in part this is due to the fact that the system features you would use >assembler programming on in say MVS do not even exist in Unix. (I think >for example of the ENQ/DEQ functions for interprocess synchronization, or >the ability to create channel programs for a device not yet supported by >the operating system). UNIX does have syncronization facilities. But these facilities are different in ways that reflect the nature of what UNIX is. For instance if you want to make sure that you don't end up with TWO processes concurrently trying to work on some sharable resource, you need to syncronize the processes in some way. UNIX does in fact need to do this, and has a means to do so. More often than not (outside of the kernel) the sharable resource is a file or device. Thus it makes sense to have a mechanism to lock files (devices are accessed via the file space in UNIX) directly. But if you need to share something else besides a file, it's no big deal to make up a null file and lock on it anyway and this is readily done in C (though not so readily in shell scripts I have found out). Channel programming is needed more than it should be needed. IBM has always taken an approach to passing much of the detail of device control to the application in its operating systems. Applications have to typically at least deal with things like the block size (and you have OPEN exits in MVS and CMS to let you do it in assembler). UNIX takes the opposite approach. You never (very rarely anyway) need to deal with a disk blocksize just to do I/O to a file. You need to when dealing with tape because of the nature of the data, but even then you can get away without dealing with it when sharing data with another UNIX application that has done so. My point is that assembler is easier on some systems, and it is NEEDED on some systems, and it is NO coincindence that these happen to be the SAME systems. > When it comes to optimization, things are not always what they seem. I >remember a few years writing the same program in Assembler, PL/I, and >FORTRAN. I looked at the generated code for each compiler. Like all >compiler generated code it looked pretty cruddy. But in the innermost >loop my hand optimized assembler code had only one less instruction than >the FORTRAN code (at that time using the H-extended compiler with maximum >optimization). The PL/I code had more than twice as many instructions in >the innermost loop. For many things I have found this to be the case as well. I've learned to recognize when it does me no good to use assembler instead of Fortran. Still in other cases it makes a big difference. Since we are bashing PL/1 I might mention a program a friend of mine wrote. He wanted to take each byte in a file and reverse the order of the bits. He did this the "obvious" way in PL/1 by defining a bit structure and taking each bit out one by one and putting them back in another one in reverse order. He discovered that his program ran "horribly" slow. It processed a file of 1000 80-byte records in about 75 seconds of CPU time on a 370/158. I wrote the same thing in aseembler. Not knowing the linkage to PL/1 at the time (due to lack of documentation for students, which is another issue) I wrote the whole thing in assembler using TR. It took less than 1 second. Doubling the size of the file didn't even seen to affect the time, so I suspect it was running under the "noise". BTW, looking back at my days as a student, I realize that in those cases where there was a lack of documentation, I ended up working around the problem by doing things in ways that would not make sense in a professional environment. It took a while to UNLEARN all the wrong things I learned in school just because someone in the computer center was paranoid about me "learning too much" about the system and keeping back documentation. I would really like to stamp out that attitude. There are times when assembler is appropriate and there are times when it is not. Students should be allowed to learn what these are. > I also remember a few years ago talking to someone at a highly Unix oriented >company which happened to also run a large IBM/MVS shop. I thought this >was strange, so I questionned it. The reply was that FORTRAN was used in >their chip design software, and no Unix FORTRAN compiler came close to >matching the optimization provided by the IBM compiler. The Fortran compiler is the toughest one to beat. It *IS* beatable by good assembler programmers, but the benefits of trying to do so are reduced now because: 1. The margin is getting narrower with better compilers. 2. Processors are caching better making the difference between good code and bad code smaller. 3. You just can't justify doing this with 1,000 to 100,000 line Fortran applications anyway. So you probably want to stick with optimizing the bottlenecks ONLY, once you determine where they are. More often a good choice of mathematical algorithm can improve things more than rewriting in assembler, depending on the scale of the problem and the machine. For instance there is a way to do a 2x2 matrix multiply with only 7 instead of 8 multiply instructions, at the cost of doing a few (5 I think) extra additions. You can recursively extend this to larger matrices with eventually a tremendous speedup. But this is only going to do you any good when a multiply costs more than an add. Some chips are now doing BOTH in one cycle. -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! / \***************************************************************************/
rickert@mp.cs.niu.edu (Neil Rickert) (04/20/91)
In article <1991Apr19.191345.12504@ux1.cso.uiuc.edu> phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) writes: >UNIX does have syncronization facilities. But these facilities are different >in ways that reflect the nature of what UNIX is. For instance if you want to >make sure that you don't end up with TWO processes concurrently trying to work >on some sharable resource, you need to syncronize the processes in some way. >UNIX does in fact need to do this, and has a means to do so. More often than Yes. But the Unix mechanism is much more limited. (Don't get me wrong. I am not trying to bash Unix. I use it a lot, and am replying from a Unix system). >not (outside of the kernel) the sharable resource is a file or device. Thus But that is one of the limitations of Unix. In MVS the shareable resource need not be a file or a device. It is completely generalized. Essentially you share named resources by means of synchronizing access to the name, and the assignment of names to resources is completely outside the operating system. >it makes sense to have a mechanism to lock files (devices are accessed via the >file space in UNIX) directly. But if you need to share something else besides >a file, it's no big deal to make up a null file and lock on it anyway and this >is readily done in C (though not so readily in shell scripts I have found out). Using lock files can be a big pain when a failure leaves lock files lying around. >Channel programming is needed more than it should be needed. IBM has always >taken an approach to passing much of the detail of device control to the >application in its operating systems. Applications have to typically at >least deal with things like the block size (and you have OPEN exits in MVS >and CMS to let you do it in assembler). UNIX takes the opposite approach. >You never (very rarely anyway) need to deal with a disk blocksize just to do >I/O to a file. You need to when dealing with tape because of the nature of >the data, but even then you can get away without dealing with it when sharing >data with another UNIX application that has done so. You never deal with records either in Unix, because they don't exist. Thus a database application which wants to lock at the record level is a big pain since the record being locked is not an entity with any meaning to the system. >My point is that assembler is easier on some systems, and it is NEEDED on >some systems, and it is NO coincindence that these happen to be the SAME >systems. I agree that it is no coincidence, although I suspect we have rather different views on which is cause and which is effect. >Since we are bashing PL/1 I might mention a program a friend of mine wrote. >He wanted to take each byte in a file and reverse the order of the bits. >He did this the "obvious" way in PL/1 by defining a bit structure and taking >each bit out one by one and putting them back in another one in reverse order. >He discovered that his program ran "horribly" slow. It processed a file of Excuse me, but the "obvious" way to do this in PL/I is to use the builtin TRANSLATE function, which would probably be compiled into a TR. (I hope I got the function name right - I haven't use PL/I for a few years, and much prefer C). >It took a while to UNLEARN all the wrong things I learned in school just >because someone in the computer center was paranoid about me "learning too much" >about the system and keeping back documentation. I would really like to stamp >out that attitude. There are times when assembler is appropriate and there are I am afraid that attitude is alive and well. Just look at all the hacker investigations, and the apparent believe in security by obscurity. I agree with you - we should provide complete information, and design the security of our systems so that providing such information does not cause security problems. >The Fortran compiler is the toughest one to beat. It *IS* beatable by good >assembler programmers, but the benefits of trying to do so are reduced now >because: > > 1. The margin is getting narrower with better compilers. One place where you can easily beat it (or probably any compiler) is in fixed point numeric computations. The hardware of most machines gives you access to overflow and carry information which compilers just don't make available. When you have intense computations which require getting 64 bit products of two 32 bit integers, and the compiler only provides 32 bit results, assembler coding will win hands down. > 3. You just can't justify doing this with 1,000 to 100,000 line > Fortran applications anyway. It is pretty dumb to try programming a complete FORTRAN application in assembler anyway. But programming the innermost loops can sometimes be very useful. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
rickert@MP.CS.NIU.EDU (Neil Rickert) (04/20/91)
In article <1991Apr19.191345.12504@ux1.cso.uiuc.edu> phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) writes: >UNIX does have syncronization facilities. But these facilities are different >in ways that reflect the nature of what UNIX is. For instance if you want to >make sure that you don't end up with TWO processes concurrently trying to work >on some sharable resource, you need to syncronize the processes in some way. >UNIX does in fact need to do this, and has a means to do so. More often than Yes. But the Unix mechanism is much more limited. (Don't get me wrong. I am not trying to bash Unix. I use it a lot, and am replying from a Unix system). >not (outside of the kernel) the sharable resource is a file or device. Thus But that is one of the limitations of Unix. In MVS the shareable resource need not be a file or a device. It is completely generalized. Essentially you share named resources by means of synchronizing access to the name, and the assignment of names to resources is completely outside the operating system. >it makes sense to have a mechanism to lock files (devices are accessed via the >file space in UNIX) directly. But if you need to share something else besides >a file, it's no big deal to make up a null file and lock on it anyway and this >is readily done in C (though not so readily in shell scripts I have found out). Using lock files can be a big pain when a failure leaves lock files lying around. >Channel programming is needed more than it should be needed. IBM has always >taken an approach to passing much of the detail of device control to the >application in its operating systems. Applications have to typically at >least deal with things like the block size (and you have OPEN exits in MVS >and CMS to let you do it in assembler). UNIX takes the opposite approach. >You never (very rarely anyway) need to deal with a disk blocksize just to do >I/O to a file. You need to when dealing with tape because of the nature of >the data, but even then you can get away without dealing with it when sharing >data with another UNIX application that has done so. You never deal with records either in Unix, because they don't exist. Thus a database application which wants to lock at the record level is a big pain since the record being locked is not an entity with any meaning to the system. >My point is that assembler is easier on some systems, and it is NEEDED on >some systems, and it is NO coincindence that these happen to be the SAME >systems. I agree that it is no coincidence, although I suspect we have rather different views on which is cause and which is effect. >Since we are bashing PL/1 I might mention a program a friend of mine wrote. >He wanted to take each byte in a file and reverse the order of the bits. >He did this the "obvious" way in PL/1 by defining a bit structure and taking >each bit out one by one and putting them back in another one in reverse order. >He discovered that his program ran "horribly" slow. It processed a file of Excuse me, but the "obvious" way to do this in PL/I is to use the builtin TRANSLATE function, which would probably be compiled into a TR. (I hope I got the function name right - I haven't use PL/I for a few years, and much prefer C). >It took a while to UNLEARN all the wrong things I learned in school just >because someone in the computer center was paranoid about me "learning too much" >about the system and keeping back documentation. I would really like to stamp >out that attitude. There are times when assembler is appropriate and there are I am afraid that attitude is alive and well. Just look at all the hacker investigations, and the apparent believe in security by obscurity. I agree with you - we should provide complete information, and design the security of our systems so that providing such information does not cause security problems. >The Fortran compiler is the toughest one to beat. It *IS* beatable by good >assembler programmers, but the benefits of trying to do so are reduced now >because: > > 1. The margin is getting narrower with better compilers. One place where you can easily beat it (or probably any compiler) is in fixed point numeric computations. The hardware of most machines gives you access to overflow and carry information which compilers just don't make available. When you have intense computations which require getting 64 bit products of two 32 bit integers, and the compiler only provides 32 bit results, assembler coding will win hands down. > 3. You just can't justify doing this with 1,000 to 100,000 line > Fortran applications anyway. It is pretty dumb to try programming a complete FORTRAN application in assembler anyway. But programming the innermost loops can sometimes be very useful. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) (04/20/91)
rickert@mp.cs.niu.edu (Neil Rickert) writes: > Yes. But the Unix mechanism is much more limited. (Don't get me wrong. I >am not trying to bash Unix. I use it a lot, and am replying from a Unix >system). I am replying from UNIX, too. What is an example? > But that is one of the limitations of Unix. In MVS the shareable resource >need not be a file or a device. It is completely generalized. Essentially >you share named resources by means of synchronizing access to the name, and >the assignment of names to resources is completely outside the operating >system. You can do this in UNIX, too. But the names exist in the file space in UNIX and MVS keeps them somewhere in the operating system memory. You can make two processes lock any resource with either system. UNIX lets you do it across a network of systems with NFS. I don't know if MVS can do this in loosely coupled systems. > Using lock files can be a big pain when a failure leaves lock files lying >around. The existance of the file is not what constitutes the lock, but rather the exclusive access to the file. I does not matter if the file exists or not. You lock onto it for exclusive access. If you get access to the file, then you have exclusive access to the implied resource. > You never deal with records either in Unix, because they don't exist. Thus >a database application which wants to lock at the record level is a big pain >since the record being locked is not an entity with any meaning to the system. Sometimes we hear it is good to leave the operating system out of something, and sometimes we hear that it is good to let the operating system control it. Databases don't need to be one single giant file, either. It might be a tad bit easier to copy the whole thing if it were one file, but that is a rare activity. Many database systems are actually controlled by servers or daemons that control the locking of records or whatever other unit of access is needed. Thus with OS independence, you are again free to delve into new concepts and not have to upset the whole system. >>Since we are bashing PL/1 I might mention a program a friend of mine wrote. >>He wanted to take each byte in a file and reverse the order of the bits. >>He did this the "obvious" way in PL/1 by defining a bit structure and taking >>each bit out one by one and putting them back in another one in reverse order. >>He discovered that his program ran "horribly" slow. It processed a file of > Excuse me, but the "obvious" way to do this in PL/I is to use the builtin >TRANSLATE function, which would probably be compiled into a TR. (I hope I >got the function name right - I haven't use PL/I for a few years, and much >prefer C). That did not exist at the time. Yes, today it would be appropriate. >>It took a while to UNLEARN all the wrong things I learned in school just >>because someone in the computer center was paranoid about me "learning too much" >>about the system and keeping back documentation. I would really like to stamp >>out that attitude. There are times when assembler is appropriate and there are > I am afraid that attitude is alive and well. Just look at all the hacker >investigations, and the apparent believe in security by obscurity. I agree >with you - we should provide complete information, and design the security >of our systems so that providing such information does not cause security >problems. And apparently some major colleges and universities are guilty of this. > One place where you can easily beat it (or probably any compiler) is in >fixed point numeric computations. The hardware of most machines gives you >access to overflow and carry information which compilers just don't make >available. When you have intense computations which require getting >64 bit products of two 32 bit integers, and the compiler only provides >32 bit results, assembler coding will win hands down. True. And another case might be when you need BOTH the quotient AND the remainder from a division. It depends on how slick the compiler optimization is. >> 3. You just can't justify doing this with 1,000 to 100,000 line >> Fortran applications anyway. > It is pretty dumb to try programming a complete FORTRAN application in >assembler anyway. But programming the innermost loops can sometimes >be very useful. Yes. And they typically are found at places like "now invert this". -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! / \***************************************************************************/
news@ucf1vm.BITNET (04/20/91)
rickert@mp.cs.niu.edu (Neil Rickert) writes: > Yes. But the Unix mechanism is much more limited. (Don't get me wrong. I >am not trying to bash Unix. I use it a lot, and am replying from a Unix >system). I am replying from UNIX, too. What is an example? > But that is one of the limitations of Unix. In MVS the shareable resource >need not be a file or a device. It is completely generalized. Essentially >you share named resources by means of synchronizing access to the name, and >the assignment of names to resources is completely outside the operating >system. You can do this in UNIX, too. But the names exist in the file space in UNIX and MVS keeps them somewhere in the operating system memory. You can make two processes lock any resource with either system. UNIX lets you do it across a network of systems with NFS. I don't know if MVS can do this in loosely coupled systems. > Using lock files can be a big pain when a failure leaves lock files lying >around. The existance of the file is not what constitutes the lock, but rather the exclusive access to the file. I does not matter if the file exists or not. You lock onto it for exclusive access. If you get access to the file, then you have exclusive access to the implied resource. > You never deal with records either in Unix, because they don't exist. Thus >a database application which wants to lock at the record level is a big pain >since the record being locked is not an entity with any meaning to the system. Sometimes we hear it is good to leave the operating system out of something, and sometimes we hear that it is good to let the operating system control it. Databases don't need to be one single giant file, either. It might be a tad bit easier to copy the whole thing if it were one file, but that is a rare activity. Many database systems are actually controlled by servers or daemons that control the locking of records or whatever other unit of access is needed. Thus with OS independence, you are again free to delve into new concepts and not have to upset the whole system. >>Since we are bashing PL/1 I might mention a program a friend of mine wrote. >>He wanted to take each byte in a file and reverse the order of the bits. >>He did this the "obvious" way in PL/1 by defining a bit structure and taking >>each bit out one by one and putting them back in another one in reverse order. >>He discovered that his program ran "horribly" slow. It processed a file of > Excuse me, but the "obvious" way to do this in PL/I is to use the builtin >TRANSLATE function, which would probably be compiled into a TR. (I hope I >got the function name right - I haven't use PL/I for a few years, and much >prefer C). That did not exist at the time. Yes, today it would be appropriate. >>It took a while to UNLEARN all the wrong things I learned in school just >>because someone in the computer center was paranoid about me "learning too much" >>about the system and keeping back documentation. I would really like to stamp >>out that attitude. There are times when assembler is appropriate and there are > I am afraid that attitude is alive and well. Just look at all the hacker >investigations, and the apparent believe in security by obscurity. I agree >with you - we should provide complete information, and design the security >of our systems so that providing such information does not cause security >problems. And apparently some major colleges and universities are guilty of this. > One place where you can easily beat it (or probably any compiler) is in >fixed point numeric computations. The hardware of most machines gives you >access to overflow and carry information which compilers just don't make >available. When you have intense computations which require getting >64 bit products of two 32 bit integers, and the compiler only provides >32 bit results, assembler coding will win hands down. True. And another case might be when you need BOTH the quotient AND the remainder from a division. It depends on how slick the compiler optimization is. >> 3. You just can't justify doing this with 1,000 to 100,000 line >> Fortran applications anyway. > It is pretty dumb to try programming a complete FORTRAN application in >assembler anyway. But programming the innermost loops can sometimes >be very useful. Yes. And they typically are found at places like "now invert this". -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! / \***************************************************************************/
phil@UX1.CSO.UIUC.EDU (Phil Howard KA9WGN) (04/20/91)
In comp.lang.asm370 you write: > assembler makes it even better. Oh, the things that can be done with a few > instructions and an authorized library brings a smile to my face. Does this > mean I'm a hacker??? You can be a hacker in UNIX, too. For instance if you find a shell script anywhere that has root privileges assigned to it, you can actually run one of your OWN shell scripts with the privileges of the other one. But you are a hacker, so you can figure it out for yourself. -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! / \***************************************************************************/