matt@mtu.edu (Matthew T. Kromer) (04/17/91)
Doug Schales said it: 370 is fun. You can do so much more by going directly to 370... all of the SVCs and DIAGs are available directly, and the macro facility in assemblers XF and H is quite powerful. Once you develop a good set of subroutines, it is quite easy to whip off a fast, small executable. One of the problems with IBM's newer releases of higher level languages (at least under VM, the environment I use) is the neutering of the language libaries to produce a stand-alone module. You now have to go through gyrations with PRELOAD to suck in all of the libraries before you can GENMOD an executable, and the resulting object file may be well over half a megabyte in size. This is extremely slow to load and often slow to execute. Plus, you get run-time libraries that want to run away with your program. PL/I for example, tries it's hardest to convert what ever you have into what ever it thinks you want. This may be great if you want to write something entirely in PL/I, but if you want to get to the guts of VM, you have to begin making direct calls to CMS or CP services. At this point, I find writing a small set of assembler interfaces to these routines to be called by a higher level language (take your pick which one) is a pain in the ass when I can do the whole thing in assembly and get a small, stand-alone, and fast object file. I also suppose it depends on your perspective. Most Unix systems programmers never touch assembler except when they have to, Unix being coded mostly in C. CP is coded in 370 assembler, and CMS is coded in PL/AS. Thus I have quite a bit of incentive to use 370 if I want to generate a new CP command, rather than try to convince CP that it should load some run-time support library. I really find that the 370 instruction set is rich enough that I never miss higher level languages. (The exception being Rexx--and the Rexx EXECCOMM interface to assembler is quite easy to use and very powerful.) In general, I find the prevailing attitudes toward IBM System 370/System 390 architecture to be quite uninformed. Granted, the 360s *are* dinosaurs in the 90s... which is the reason IBM has evolved the line though to 370s to XA to ESA. I see many examples in modern CS textbooks that compare state of the art microprocessors to an IBM 360. Given the 25 year difference, it's not surprising that a PC can outperform a 360. I haven't seen a workstation yet that comes close to running circles around a 3090. Certainly one can obtain faster calculations with less expense on a smaller machine, but to assume micro technology is growing in leaps and bounds while mainframe technology is stagnant is rather ignorant. It reminds me of the CS faculty at a certain university which, upon seeing the two 5 1/4" microcode diskette drives on a 3092 processor control unit, said: "Oh, your computer boots off floppy too!" (These same faculty later commented on the difficult learning curve of a Macintosh... but their approach to IBM mainframes is common.) Matthew T. Kromer Discussion in private is welcomed to: MATT@MTUS5.cts.mtu.edu
matt@MTU.EDU ("Matthew T. Kromer") (04/17/91)
Doug Schales said it: 370 is fun. You can do so much more by going directly
to 370... all of the SVCs and DIAGs are available directly, and the macro
facility in assemblers XF and H is quite powerful. Once you develop a good
set of subroutines, it is quite easy to whip off a fast, small executable.
One of the problems with IBM's newer releases of higher level languages (at
least under VM, the environment I use) is the neutering of the language libaries
to produce a stand-alone module. You now have to go through gyrations with
PRELOAD to suck in all of the libraries before you can GENMOD an executable,
and the resulting object file may be well over half a megabyte in size. This
is extremely slow to load and often slow to execute. Plus, you get run-time
libraries that want to run away with your program. PL/I for example, tries
it's hardest to convert what ever you have into what ever it thinks you want.
This may be great if you want to write something entirely in PL/I, but if you
want to get to the guts of VM, you have to begin making direct calls to CMS
or CP services. At this point, I find writing a small set of assembler
interfaces to these routines to be called by a higher level language (take
your pick which one) is a pain in the ass when I can do the whole thing in
assembly and get a small, stand-alone, and fast object file.
I also suppose it depends on your perspective. Most Unix systems programmers
never touch assembler except when they have to, Unix being coded mostly in C.
CP is coded in 370 assembler, and CMS is coded in PL/AS. Thus I have quite
a bit of incentive to use 370 if I want to generate a new CP command, rather
than try to convince CP that it should load some run-time support library.
I really find that the 370 instruction set is rich enough that I never miss
higher level languages. (The exception being Rexx--and the Rexx EXECCOMM
interface to assembler is quite easy to use and very powerful.)
In general, I find the prevailing attitudes toward IBM System 370/System 390
architecture to be quite uninformed. Granted, the 360s *are* dinosaurs in the
90s... which is the reason IBM has evolved the line though to 370s to XA to ESA.
I see many examples in modern CS textbooks that compare state of the art
microprocessors to an IBM 360. Given the 25 year difference, it's not
surprising
that a PC can outperform a 360. I haven't seen a workstation yet that comes
close to running circles around a 3090. Certainly one can obtain faster
calculations with less expense on a smaller machine, but to assume micro
technology is growing in leaps and bounds while mainframe technology is stagnant
is rather ignorant. It reminds me of the CS faculty at a certain university
which, upon seeing the two 5 1/4" microcode diskette drives on a 3092 processor
control unit, said: "Oh, your computer boots off floppy too!" (These same
faculty later commented on the difficult learning curve of a Macintosh... but
their approach to IBM mainframes is common.)
Matthew T. Kromer
Discussion in private is welcomed to: MATT@MTUS5.cts.mtu.edukevin@msa3b.UUCP (Kevin P. Kleinfelter) (04/22/91)
matt@mtu.edu (Matthew T. Kromer) writes: ... >I really find that the 370 instruction set is rich enough that I never miss >higher level languages.... In fact, I believe C to be a LOWER level language than 370 BAL. After all, BAL has a block move instruction (MVC or MVCL) where C has to call a SUBROUTINE to move a block (movemem or strcpy). Pre-ANSI C and BAL do about the same level of error checking. :-) -- Kevin Kleinfelter @ Dun and Bradstreet Software, Inc (404) 239-2347 ...gatech!nanovx!msa3b!kevin Warning: There seem to be multiple 'msa3b' nodes on Usenet, and it is nanoVX, not nanovAx.
news@ucf1vm.BITNET (04/22/91)
matt@mtu.edu (Matthew T. Kromer) writes: ... >I really find that the 370 instruction set is rich enough that I never miss >higher level languages.... In fact, I believe C to be a LOWER level language than 370 BAL. After all, BAL has a block move instruction (MVC or MVCL) where C has to call a SUBROUTINE to move a block (movemem or strcpy). Pre-ANSI C and BAL do about the same level of error checking. :-) -- Kevin Kleinfelter @ Dun and Bradstreet Software, Inc (404) 239-2347 ...gatech!nanovx!msa3b!kevin Warning: There seem to be multiple 'msa3b' nodes on Usenet, and it is nanoVX, not nanovAx.
phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) (04/24/91)
kevin@msa3b.UUCP (Kevin P. Kleinfelter) writes: >matt@mtu.edu (Matthew T. Kromer) writes: >... >>I really find that the 370 instruction set is rich enough that I never miss >>higher level languages.... >In fact, I believe C to be a LOWER level language than 370 BAL. After all, >BAL has a block move instruction (MVC or MVCL) where C has to call a >SUBROUTINE to move a block (movemem or strcpy). Pre-ANSI C and BAL do about >the same level of error checking. :-) But that makes C fit my definition of a HIGH level language. You see, the difference between low level and high level, as I think of it anyway, is NOT how much you can do in one instruction, but rather how much control you have over HOW things are done. C gives you LESS control because you don't get to choose the precise instruction. Higher languages like Pascal and ADA give you even less control and that lack of control starts to span over into things like data representation itself. To me, a high level language is a tradeoff of control for other things that are supposed to be the advantage in high level languages (whether they actually succeed or not). -- /***************************************************************************\ / 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/24/91)
kevin@msa3b.UUCP (Kevin P. Kleinfelter) writes: >matt@mtu.edu (Matthew T. Kromer) writes: >... >>I really find that the 370 instruction set is rich enough that I never miss >>higher level languages.... >In fact, I believe C to be a LOWER level language than 370 BAL. After all, >BAL has a block move instruction (MVC or MVCL) where C has to call a >SUBROUTINE to move a block (movemem or strcpy). Pre-ANSI C and BAL do about >the same level of error checking. :-) But that makes C fit my definition of a HIGH level language. You see, the difference between low level and high level, as I think of it anyway, is NOT how much you can do in one instruction, but rather how much control you have over HOW things are done. C gives you LESS control because you don't get to choose the precise instruction. Higher languages like Pascal and ADA give you even less control and that lack of control starts to span over into things like data representation itself. To me, a high level language is a tradeoff of control for other things that are supposed to be the advantage in high level languages (whether they actually succeed or not). -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! / \***************************************************************************/
chip@osh3.OSHA.GOV (Chip Yamasaki) (04/24/91)
In <1991Apr23.190810.16593@ux1.cso.uiuc.edu> phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) writes: >kevin@msa3b.UUCP (Kevin P. Kleinfelter) writes: >>matt@mtu.edu (Matthew T. Kromer) writes: >>In fact, I believe C to be a LOWER level language than 370 BAL. After all, >>BAL has a block move instruction (MVC or MVCL) where C has to call a >>SUBROUTINE to move a block (movemem or strcpy). Pre-ANSI C and BAL do about >>the same level of error checking. :-) >But that makes C fit my definition of a HIGH level language. >You see, the difference between low level and high level, as I think of >it anyway, is NOT how much you can do in one instruction, but rather >how much control you have over HOW things are done. C gives you LESS >control because you don't get to choose the precise instruction. Higher >languages like Pascal and ADA give you even less control and that lack >of control starts to span over into things like data representation itself. One question though. It has been a long time since I took a 370 ALC course in school (and I didn't know then either), but does that MVC/MVCL instruction resolve to 1 machine code instruction? If so, then I suppose you're right. If not then you're back to square one. In C your could code your own routine to move int's or unsigned chars to do something very similar, but why would you want to. Also the one programmer here who does write ALC always uses a huge library of ALC routines and macros. Isn't that about the same as calling a function in C? Don't get me wrong, the programs I wrote in class were very rudimentary, but I do remember the assignments as being fun. I also enjoy ASM on the PC. I just think that any language, HL or LL, can be fun if you just get into the "spirit" of it (even BASIC or COBOL). As far as human languages are concerned I am not multi-lingual, but I understand that it is not "easy" or "fun" to speak French without first thinking like a Frenchman. ;-) -- -- Charles "Chip" Yamasaki chip@oshcomm.osha.gov -- -- Charles "Chip" Yamasaki chip@oshcomm.osha.gov
chip@UUNET.UU.NET (Chip Yamasaki) (04/24/91)
In <1991Apr23.190810.16593@ux1.cso.uiuc.edu> phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) writes: >kevin@msa3b.UUCP (Kevin P. Kleinfelter) writes: >>matt@mtu.edu (Matthew T. Kromer) writes: >>In fact, I believe C to be a LOWER level language than 370 BAL. After all, >>BAL has a block move instruction (MVC or MVCL) where C has to call a >>SUBROUTINE to move a block (movemem or strcpy). Pre-ANSI C and BAL do about >>the same level of error checking. :-) >But that makes C fit my definition of a HIGH level language. >You see, the difference between low level and high level, as I think of >it anyway, is NOT how much you can do in one instruction, but rather >how much control you have over HOW things are done. C gives you LESS >control because you don't get to choose the precise instruction. Higher >languages like Pascal and ADA give you even less control and that lack >of control starts to span over into things like data representation itself. One question though. It has been a long time since I took a 370 ALC course in school (and I didn't know then either), but does that MVC/MVCL instruction resolve to 1 machine code instruction? If so, then I suppose you're right. If not then you're back to square one. In C your could code your own routine to move int's or unsigned chars to do something very similar, but why would you want to. Also the one programmer here who does write ALC always uses a huge library of ALC routines and macros. Isn't that about the same as calling a function in C? Don't get me wrong, the programs I wrote in class were very rudimentary, but I do remember the assignments as being fun. I also enjoy ASM on the PC. I just think that any language, HL or LL, can be fun if you just get into the "spirit" of it (even BASIC or COBOL). As far as human languages are concerned I am not multi-lingual, but I understand that it is not "easy" or "fun" to speak French without first thinking like a Frenchman. ;-) -- -- Charles "Chip" Yamasaki chip@oshcomm.osha.gov -- -- Charles "Chip" Yamasaki chip@oshcomm.osha.gov
RKOGUT@BROWNVM.BITNET ("R. Kogut") (04/24/91)
I think the point about the MVC instructions is being missed. The point is
that to copy a fixed length character string (assuming that all definitions
are properly made), then:
MVC TO,FROM in BAL is clear
TO = FROM; in various HLL's is clearer and machine independent
memcpy(TO,FROM,sizeof(TO)); in C is very ugly and hard to read
The C compiler may generate a single MVC, but it's harder to write and read
then assembler in this case. Many other things in C require jumping thru
hoops to accomplish simple tasks and therefore make programs hard to read.
This is not a wholesale condemnation of C, just to point out that in some
areas it has weaknesses compared to assembler.EGC4MV2@UCLAMVS.BITNET (2 Michael Van Norman) (04/24/91)
> I think the point about the MVC instructions is being missed. The point is > that to copy a fixed length character string (assuming that all definitions > are properly made), then: > MVC TO,FROM in BAL is clear > TO = FROM; in various HLL's is clearer and machine independent > memcpy(TO,FROM,sizeof(TO)); in C is very ugly and hard to read On the contrary I find this very easy to read. In fact the memcpy statement is no different from the MVC statement except for the addition of the length parameter. The only real addition is the parenthesis. Take the ()'s out and you have MVC TO,FROM memcpy TO,FROM,LENGTH This looks the same to me :) As for TO = FROM, if the memory to be copied is a structure the TO = FROM will work in ANSI C. > The C compiler may generate a single MVC, but it's harder to write and read > then assembler in this case. Many other things in C require jumping thru > hoops to accomplish simple tasks and therefore make programs hard to read. You could always just #define MVC(x,y) memcpy(x,y,sizeof(x)) Then you could write MVC(TO,FROM) all you want! Michael Van Norman 11334 University Research Library Programmer/Analyst 405 Hilgard Avenue Library Administrative Computing Los Angeles, CA 90024-1575 EGC4MVN@mvs.oac.ucla.edu (213)825-1206
icking@gmdzi.gmd.de (Werner Icking) (04/25/91)
chip@osh3.OSHA.GOV (Chip Yamasaki) writes: >In <1991Apr23.190810.16593@ux1.cso.uiuc.edu> phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) writes: <>kevin@msa3b.UUCP (Kevin P. Kleinfelter) writes: [...] <>You see, the difference between low level and high level, as I think of <>it anyway, is NOT how much you can do in one instruction, but rather <>how much control you have over HOW things are done. C gives you LESS <>control because you don't get to choose the precise instruction. Higher <>languages like Pascal and ADA give you even less control and that lack <>of control starts to span over into things like data representation itself. >One question though. It has been a long time since I took a 370 ALC >course in school (and I didn't know then either), but does that MVC/MVCL >instruction resolve to 1 machine code instruction? If so, then I >suppose you're right. If not then you're back to square one. Yes AND no: MVCL is one machine code instruction for the assembler. But the machine instruction is interruptible e.g. to handle page-faults and paging-in the required pages. So it is a low-level language and a high-level machine? :-) -- Werner Icking icking@gmdzi.gmd.de (+49 2241) 14-2443 Gesellschaft fuer Mathematik und Datenverarbeitung mbH (GMD) Schloss Birlinghoven, P.O.Box 1240, D-5205 Sankt Augustin 1, FRGermany "Der Dativ ist dem Genitiv sein Tod."
icking@UUNET.UU.NET (Werner Icking) (04/25/91)
chip@osh3.OSHA.GOV (Chip Yamasaki) writes: >In <1991Apr23.190810.16593@ux1.cso.uiuc.edu> phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) writes: <>kevin@msa3b.UUCP (Kevin P. Kleinfelter) writes: [...] <>You see, the difference between low level and high level, as I think of <>it anyway, is NOT how much you can do in one instruction, but rather <>how much control you have over HOW things are done. C gives you LESS <>control because you don't get to choose the precise instruction. Higher <>languages like Pascal and ADA give you even less control and that lack <>of control starts to span over into things like data representation itself. >One question though. It has been a long time since I took a 370 ALC >course in school (and I didn't know then either), but does that MVC/MVCL >instruction resolve to 1 machine code instruction? If so, then I >suppose you're right. If not then you're back to square one. Yes AND no: MVCL is one machine code instruction for the assembler. But the machine instruction is interruptible e.g. to handle page-faults and paging-in the required pages. So it is a low-level language and a high-level machine? :-) -- Werner Icking icking@gmdzi.gmd.de (+49 2241) 14-2443 Gesellschaft fuer Mathematik und Datenverarbeitung mbH (GMD) Schloss Birlinghoven, P.O.Box 1240, D-5205 Sankt Augustin 1, FRGermany "Der Dativ ist dem Genitiv sein Tod."
phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) (04/26/91)
chip@osh3.OSHA.GOV (Chip Yamasaki) writes: >One question though. It has been a long time since I took a 370 ALC >course in school (and I didn't know then either), but does that MVC/MVCL >instruction resolve to 1 machine code instruction? If so, then I >suppose you're right. If not then you're back to square one. Does it really matter? You code one instruction. It actually is one instruction in binary though the machine might have to refetch it if there are page faults during the copy (MVCL ONLY). >In C your could code your own routine to move int's or unsigned chars to >do something very similar, but why would you want to. The goal is programming convenience. MVC and MVCL are convenient. They do not justify using assembler; just reduce the difficulty. >Also the one programmer here who does write ALC always uses a huge >library of ALC routines and macros. Isn't that about the same as >calling a function in C? That depends. >Don't get me wrong, the programs I wrote in class were very rudimentary, >but I do remember the assignments as being fun. I also enjoy ASM on the >PC. I just think that any language, HL or LL, can be fun if you just >get into the "spirit" of it (even BASIC or COBOL). Unfortunately, typical assembler class assignments were things usually NOT appropriate for assembler. But you can't learn system interfaces AND a new language as easily at the same time. >As far as human languages are concerned I am not multi-lingual, but I >understand that it is not "easy" or "fun" to speak French without first >thinking like a Frenchman. ;-) That is why they teach the culture with it. -- /***************************************************************************\ / 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/26/91)
chip@osh3.OSHA.GOV (Chip Yamasaki) writes: >One question though. It has been a long time since I took a 370 ALC >course in school (and I didn't know then either), but does that MVC/MVCL >instruction resolve to 1 machine code instruction? If so, then I >suppose you're right. If not then you're back to square one. Does it really matter? You code one instruction. It actually is one instruction in binary though the machine might have to refetch it if there are page faults during the copy (MVCL ONLY). >In C your could code your own routine to move int's or unsigned chars to >do something very similar, but why would you want to. The goal is programming convenience. MVC and MVCL are convenient. They do not justify using assembler; just reduce the difficulty. >Also the one programmer here who does write ALC always uses a huge >library of ALC routines and macros. Isn't that about the same as >calling a function in C? That depends. >Don't get me wrong, the programs I wrote in class were very rudimentary, >but I do remember the assignments as being fun. I also enjoy ASM on the >PC. I just think that any language, HL or LL, can be fun if you just >get into the "spirit" of it (even BASIC or COBOL). Unfortunately, typical assembler class assignments were things usually NOT appropriate for assembler. But you can't learn system interfaces AND a new language as easily at the same time. >As far as human languages are concerned I am not multi-lingual, but I >understand that it is not "easy" or "fun" to speak French without first >thinking like a Frenchman. ;-) That is why they teach the culture with it. -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! / \***************************************************************************/
mgphl@msa3b.UUCP (Michael Phillips) (04/28/91)
chip@osh3.OSHA.GOV (Chip Yamasaki) writes: >course in school (and I didn't know then either), but does that MVC/MVCL >instruction resolve to 1 machine code instruction? If so, then I >suppose you're right. If not then you're back to square one. MVC and MVCL are single machine code instructions. However, the MVCL is implemented in micro code in such a way as to allow the task to be interrupted and restarted. You also have to load 4 registers prior to executing an MVCL. >Also the one programmer here who does write ALC always uses a huge >library of ALC routines and macros. Isn't that about the same as >calling a function in C? Not at all! A *well* coded assembler macro generates exactly the object code needed and nothing else. The conditional assembly language of the 360/370 world allows one to create quite powerfull macros ( of course the SYNTAX of that stuff will drive you crazy ;-) ). ****************************************************************************** | Michael G. Phillips | "Only two things are infinite, the universe | | Dun & Bradstreet Software | and human stupidity, and I'm not sure about | | ..!gatech!nanovx!msa3b!mgphl | the former" -- Albert Einstein | ******************************************************************************
news@ucf1vm.BITNET (04/28/91)
chip@osh3.OSHA.GOV (Chip Yamasaki) writes: >course in school (and I didn't know then either), but does that MVC/MVCL >instruction resolve to 1 machine code instruction? If so, then I >suppose you're right. If not then you're back to square one. MVC and MVCL are single machine code instructions. However, the MVCL is implemented in micro code in such a way as to allow the task to be interrupted and restarted. You also have to load 4 registers prior to executing an MVCL. >Also the one programmer here who does write ALC always uses a huge >library of ALC routines and macros. Isn't that about the same as >calling a function in C? Not at all! A *well* coded assembler macro generates exactly the object code needed and nothing else. The conditional assembly language of the 360/370 world allows one to create quite powerfull macros ( of course the SYNTAX of that stuff will drive you crazy ;-) ). ****************************************************************************** | Michael G. Phillips | "Only two things are infinite, the universe | | Dun & Bradstreet Software | and human stupidity, and I'm not sure about | | ..!gatech!nanovx!msa3b!mgphl | the former" -- Albert Einstein | ******************************************************************************