|
SCOUG-Programming Mailing List ArchivesReturn to [ 01 | May | 2008 ]
176 This is a multi-part message in MIME format. ------=_NextPart_000_0065_01C8AB7F.F87347C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As we go forth (or FORTH) we will run into the "stack". Now a stack is = a preassign, contiguous block of "words" implemented in main storage, = AKA "memory". As an intrinsic, i.e. native, machine architecture = feature we owe to Burroughs in its introduction of the B500 (and later = B5000) series. With that introduction we had the implementation of the = ALGOL specification-only language previously as a programming language, = named not surprisingly as BALGOL. Just to make sure we are on the same page, let's note the three forms of = an expression: prefix (+ A B), infix (A + B), and postfix ( A B +). Now = languages like C and PL/I write source expressions in assignment = statements using infix notation. The compiler or interpreter will = optimize them by converting them to postfix or RPN (Reverse Polish = Notation--because nobody wanted to spell the Polish inventors name). If = you bought a Texas Instrument calculator you used infix notation; for an = HP, postfix. Of the languages we will consider one, LISP, we write = expressions using prefix notation, e.g. (add A B). The parenthesis here = denotes a list (LISP expression) where either A or B or both could be = lists as well. Thus LISP natively supports aggregate operations on = lists, something we want to incorporate into SL/I. I will offer two items of historical note here. Prior to the = introduction in 1964 of the IBM S/360 family I asked an mainframe = engineer attending the same conference why IBM didn't also implement a = native stack architecture. He responded that they had considered it = until someone noted that they required only existing instructions on the = then IBM 7xxx series to replicate its functionality. After the introduction of the IBM S/360 family with its 16 general = purpose registers and the introduction of the Burroughs B5000 and B3000 = incompatible series I informed a Burroughs user that on the S/360 family = a program which executed on the smallest member would do so unmodified = on the largest. This enraged the user. He cursed IBM and me, = responding "that if Burroughs couldn't do it, then certainly neither = could IBM". That kind of ignorant loyalty money cannot buy. No one argues the use of the stack and RPN for expression evaluation. = Intel takes this from expression evaluation to the realm of APIs where = parameters get entered on a stack in reverse order as well. Some of you = will remember the problem of solving the "peg solitaire" we attempted in = multiple languages. The solution requires recursion, which requires = basically an unknown limit API stacking of a module calling itself. The = biggest problem here lies in specifying the "stack depth", a finite = limit, large enough to encompass the recursive depth. I mention this because if you come from an IBM mainframe environment in = which inter-module calling sequences get maintained on a dynamic list, = the only time when you would get the equivalent of a "stack overflow" = would be when you ran out of virtual storage. When we get to that point = in our project I intend to persuade you to forego the current Intel = standard to one more akin to the IBM mainframe. In our source-only = implementation of SL/I applications in interpretive mode we eliminate = the need for a linkage editor, the specification of a stacksize, and any = need for a MAKE or BUILD, all of which we will have integrated = functionally in our tool, The Developer's Assistant. I think all of this will become clearer as we go FORTH. ------=_NextPart_000_0065_01C8AB7F.F87347C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable charset=3Diso-8859-1"> As we go forth (or FORTH) we will run into the = "stack". =20 Now a stack is a preassign, contiguous block of "words" implemented in = main=20 storage, AKA "memory". As an intrinsic, i.e. native, machine = architecture=20 feature we owe to Burroughs in its introduction of the B500 (and later = B5000)=20 series. With that introduction we had the implementation of the = ALGOL=20 specification-only language previously as a programming language, named = not=20 surprisingly as BALGOL. Just to make sure we are on the same page, let's = note the=20 three forms of an expression: prefix (+ A B), infix (A + B), and postfix = ( A B=20 +). Now languages like C and PL/I write source expressions in = assignment=20 statements using infix notation. The compiler or interpreter = will=20 optimize them by converting them to postfix or RPN (Reverse Polish=20 Notation--because nobody wanted to spell the Polish inventors = name). If=20 you bought a Texas Instrument calculator you used infix notation; for an = HP,=20 postfix. Of the languages we will consider one, LISP, we write = expressions=20 using prefix notation, e.g. (add A B). The parenthesis here = denotes a list=20 (LISP expression) where either A or B or both could be lists as = well. Thus=20 LISP natively supports aggregate operations on lists, something we want = to=20 incorporate into SL/I. I will offer two items of historical note = here. Prior to=20 the introduction in 1964 of the IBM S/360 family I asked an mainframe = engineer=20 attending the same conference why IBM didn't also implement a native = stack=20 architecture. He responded that they had considered it until = someone noted=20 that they required only existing instructions on the then IBM 7xxx = series to=20 replicate its functionality. After the introduction of the IBM S/360 family with = its 16=20 general purpose registers and the introduction of the Burroughs B5000 = and B3000=20 incompatible series I informed a Burroughs user that on the S/360 family = a=20 program which executed on the smallest member would do so unmodified on = the=20 largest. This enraged the user. He cursed IBM and me, = responding=20 "that if Burroughs couldn't do it, then certainly neither could = IBM". That=20 kind of ignorant loyalty money cannot buy. No one argues the use of the stack and RPN for = expression=20 evaluation. Intel takes this from expression evaluation to the = realm of=20 APIs where parameters get entered on a stack in reverse order as = well. =20 Some of you will remember the problem of solving the "peg solitaire" we=20 attempted in multiple languages. The solution requires recursion, = which=20 requires basically an unknown limit API stacking of a module = calling=20 itself. The biggest problem here lies in specifying the "stack = depth", a=20 finite limit, large enough to encompass the recursive = depth. I mention this because if you come from an IBM = mainframe=20 environment in which inter-module calling sequences get maintained on a = dynamic=20 list, the only time when you would get the equivalent of a "stack = overflow"=20 would be when you ran out of virtual storage. When we get to that = point in=20 our project I intend to persuade you to forego the current Intel = standard to one=20 more akin to the IBM mainframe. In our source-only implementation = of SL/I=20 applications in interpretive mode we eliminate the need for a linkage = editor,=20 the specification of a stacksize, and any need for a MAKE or BUILD, all = of which=20 we will have integrated functionally in our tool, The Developer's=20 Assistant. I think all of this will become clearer as we go=20 FORTH. ------=_NextPart_000_0065_01C8AB7F.F87347C0-- ===================================================== To unsubscribe from this list, send an email message to "steward@scoug.com". In the body of the message, put the command "unsubscribe scoug-programming". For problems, contact the list owner at "postmaster@scoug.com". =====================================================
P.O. Box 26904 Santa Ana, CA 92799-6904, USA Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS RESERVED. SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners. |