Have programming languages driven hardware development?












9















Programming language development has been influenced by hardware design. One example from this answer mentions how C pointers were, at least in part, influenced by the design of the PDP-11. Has the reverse taken place, where a construct provided by a language drove the development of hardware?



To be clear, I'm wondering about core language constructs, like pointers for example, rather than industry consortiums coming up with something like OpenGL then being implemented in hardware. Perhaps hardware floating-point support?










share|improve this question







New contributor




Nathan is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





















  • Welcome to Retrocomputing. Nice question!

    – Dr Sheldon
    6 hours ago











  • Similar question is also true for operating systems: inter process protection & security, paging & virtual memory, fast context switching, etc..

    – Erik Eidt
    6 hours ago








  • 1





    As a cautionary tale we should perhaps mention the iAPX 432

    – another-dave
    5 hours ago











  • I'm pretty sure that many of the RISC processors were designed specifically to be good targets for compilers; I'm seeking a source.

    – Tommy
    4 hours ago











  • @Tommy RISC CPUs are interesting case. They were designed in era where it was obvious that they'd be almost exclusively running compiled code, so were designed with compilers in mind. On the other hand, many RISC CPUs were designed with certain features and limitations that required compilers implement things they didn't have to previously. For example, branch delay slots and pipelining required that the compiler to reorder instructions in order to generate the most efficient code. (In the end it proved CPUs can do a better job of reordering instructions than compilers.)

    – Ross Ridge
    4 hours ago
















9















Programming language development has been influenced by hardware design. One example from this answer mentions how C pointers were, at least in part, influenced by the design of the PDP-11. Has the reverse taken place, where a construct provided by a language drove the development of hardware?



To be clear, I'm wondering about core language constructs, like pointers for example, rather than industry consortiums coming up with something like OpenGL then being implemented in hardware. Perhaps hardware floating-point support?










share|improve this question







New contributor




Nathan is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





















  • Welcome to Retrocomputing. Nice question!

    – Dr Sheldon
    6 hours ago











  • Similar question is also true for operating systems: inter process protection & security, paging & virtual memory, fast context switching, etc..

    – Erik Eidt
    6 hours ago








  • 1





    As a cautionary tale we should perhaps mention the iAPX 432

    – another-dave
    5 hours ago











  • I'm pretty sure that many of the RISC processors were designed specifically to be good targets for compilers; I'm seeking a source.

    – Tommy
    4 hours ago











  • @Tommy RISC CPUs are interesting case. They were designed in era where it was obvious that they'd be almost exclusively running compiled code, so were designed with compilers in mind. On the other hand, many RISC CPUs were designed with certain features and limitations that required compilers implement things they didn't have to previously. For example, branch delay slots and pipelining required that the compiler to reorder instructions in order to generate the most efficient code. (In the end it proved CPUs can do a better job of reordering instructions than compilers.)

    – Ross Ridge
    4 hours ago














9












9








9


1






Programming language development has been influenced by hardware design. One example from this answer mentions how C pointers were, at least in part, influenced by the design of the PDP-11. Has the reverse taken place, where a construct provided by a language drove the development of hardware?



To be clear, I'm wondering about core language constructs, like pointers for example, rather than industry consortiums coming up with something like OpenGL then being implemented in hardware. Perhaps hardware floating-point support?










share|improve this question







New contributor




Nathan is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












Programming language development has been influenced by hardware design. One example from this answer mentions how C pointers were, at least in part, influenced by the design of the PDP-11. Has the reverse taken place, where a construct provided by a language drove the development of hardware?



To be clear, I'm wondering about core language constructs, like pointers for example, rather than industry consortiums coming up with something like OpenGL then being implemented in hardware. Perhaps hardware floating-point support?







hardware software c






share|improve this question







New contributor




Nathan is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question







New contributor




Nathan is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question






New contributor




Nathan is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked 7 hours ago









NathanNathan

461




461




New contributor




Nathan is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





Nathan is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






Nathan is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.













  • Welcome to Retrocomputing. Nice question!

    – Dr Sheldon
    6 hours ago











  • Similar question is also true for operating systems: inter process protection & security, paging & virtual memory, fast context switching, etc..

    – Erik Eidt
    6 hours ago








  • 1





    As a cautionary tale we should perhaps mention the iAPX 432

    – another-dave
    5 hours ago











  • I'm pretty sure that many of the RISC processors were designed specifically to be good targets for compilers; I'm seeking a source.

    – Tommy
    4 hours ago











  • @Tommy RISC CPUs are interesting case. They were designed in era where it was obvious that they'd be almost exclusively running compiled code, so were designed with compilers in mind. On the other hand, many RISC CPUs were designed with certain features and limitations that required compilers implement things they didn't have to previously. For example, branch delay slots and pipelining required that the compiler to reorder instructions in order to generate the most efficient code. (In the end it proved CPUs can do a better job of reordering instructions than compilers.)

    – Ross Ridge
    4 hours ago



















  • Welcome to Retrocomputing. Nice question!

    – Dr Sheldon
    6 hours ago











  • Similar question is also true for operating systems: inter process protection & security, paging & virtual memory, fast context switching, etc..

    – Erik Eidt
    6 hours ago








  • 1





    As a cautionary tale we should perhaps mention the iAPX 432

    – another-dave
    5 hours ago











  • I'm pretty sure that many of the RISC processors were designed specifically to be good targets for compilers; I'm seeking a source.

    – Tommy
    4 hours ago











  • @Tommy RISC CPUs are interesting case. They were designed in era where it was obvious that they'd be almost exclusively running compiled code, so were designed with compilers in mind. On the other hand, many RISC CPUs were designed with certain features and limitations that required compilers implement things they didn't have to previously. For example, branch delay slots and pipelining required that the compiler to reorder instructions in order to generate the most efficient code. (In the end it proved CPUs can do a better job of reordering instructions than compilers.)

    – Ross Ridge
    4 hours ago

















Welcome to Retrocomputing. Nice question!

– Dr Sheldon
6 hours ago





Welcome to Retrocomputing. Nice question!

– Dr Sheldon
6 hours ago













Similar question is also true for operating systems: inter process protection & security, paging & virtual memory, fast context switching, etc..

– Erik Eidt
6 hours ago







Similar question is also true for operating systems: inter process protection & security, paging & virtual memory, fast context switching, etc..

– Erik Eidt
6 hours ago






1




1





As a cautionary tale we should perhaps mention the iAPX 432

– another-dave
5 hours ago





As a cautionary tale we should perhaps mention the iAPX 432

– another-dave
5 hours ago













I'm pretty sure that many of the RISC processors were designed specifically to be good targets for compilers; I'm seeking a source.

– Tommy
4 hours ago





I'm pretty sure that many of the RISC processors were designed specifically to be good targets for compilers; I'm seeking a source.

– Tommy
4 hours ago













@Tommy RISC CPUs are interesting case. They were designed in era where it was obvious that they'd be almost exclusively running compiled code, so were designed with compilers in mind. On the other hand, many RISC CPUs were designed with certain features and limitations that required compilers implement things they didn't have to previously. For example, branch delay slots and pipelining required that the compiler to reorder instructions in order to generate the most efficient code. (In the end it proved CPUs can do a better job of reordering instructions than compilers.)

– Ross Ridge
4 hours ago





@Tommy RISC CPUs are interesting case. They were designed in era where it was obvious that they'd be almost exclusively running compiled code, so were designed with compilers in mind. On the other hand, many RISC CPUs were designed with certain features and limitations that required compilers implement things they didn't have to previously. For example, branch delay slots and pipelining required that the compiler to reorder instructions in order to generate the most efficient code. (In the end it proved CPUs can do a better job of reordering instructions than compilers.)

– Ross Ridge
4 hours ago










6 Answers
6






active

oldest

votes


















2














Simply yes.



And not just a few instructions, but whole CPUs have been developed with languages in mind. Most prominent maybe Intel's 8086. Already the basic CPU was designed to support the way high level languages handle memory management, especially stack allocation and usage. With BP a separate register for stack frames and addressing was added in conjunction with short encodings for stack related addressing to make HLL programs perform. The 80186/286 went further in this direction by adding Enter/Leave instructions for stack frame handling.



While it can be said that the base 8086 was more geared toward languages like Pascal or PL/M (*1,2), later incarnations added many ways to support the now prevalent C primitives - not at least scaling factors for indices.





*1 - Most remarkable here the string functions which make only sense in languages supporting strings as discrete data type.



*2 - Stephen Morse's 8086 primer is still a good read - especially when he talks about the finer details. Similar and quite recommended his 2008 interview about the 8086 creation where he describes his approach as mostly HLL driven.






share|improve this answer































    2














    Yes. Case in point, the VAX. The instruction set design was influenced by the requirements of the compiled languages of the day. For example, the orthogonality of the ISA; the provision of instructions that map to language constructs such as 'case' statements (in the numbered-case sense of Hoare's original formulation, not the labelled-case of C), loop statements, and so on.



    VAX Architecture Ref - see the Introduction.



    I am not claiming the VAX is unique in this respect, just an example I know a little about. As a second example, I'll mention the Burroughs B6500 'display' registers. A display, in 1960s speak, is a mechanism for efficient uplevel references. If your language, such as Algol60, permits declaration of nested procedures to any depth, then arbitrary references to the local variables of different levels of enclosing procedure require special handling. The mechanism used (the 'display') was invented for KDF9 Whetstone Algol by Randell and Russell, and described in their book Algol 60 Implementation. The B6500 incorporates that into hardware:




    The B6500/B7500 contains a network of Display Registers (D0 through
    D31) which are caused to point at the appropriate MSCW (Fig. 5). The
    local variables of all procedures global to the current procedure are
    addressed in the B6500/B7500 relative to the Display Registers.







    share|improve this answer


























    • as well as more registers for local variables, and large, regular address space rather than smaller banks that can be activated one at a time..

      – Erik Eidt
      6 hours ago





















    2














    The first page of the Intel 8086 data sheet lists the processor's features, which include





    • Architecture Designed for Powerful Assembly Language and Efficient High Level Languages




    In particular, C and other high-level languages use the stack for arguments and local variables. The 8086 has both a stack pointer (SP) and a frame pointer (BP) which address memory using the stack segment (SS) rather than other segments (CS, DS, ES).



    The datasheet for the 8087 co-processor has the following section:




    PROGRAMMING LANGUAGE SUPPORT



    Programs for the 8087 can be written in Intel's high-level languages for 8086/8088 and 80186/80188 systems; ASM-86 (the 8086, 8088 assembly language), PL/M-86, FORTRAN-86, and PASCAL-86.




    The 80286 added several instructions to the architecture to aid high-level languages. PUSHA, POPA, ENTER, and LEAVE help with subroutine calls. The BOUND instruction was useful for array bounds checking and switch-style control statements. Other instructions unrelated to high-level languages were added as well.



    The 80386 added bitfield instructions, which are used in C.





    The Motorola MC68000 Microprocessor User's Manual states:




    2.2.2 Structured Modular Programming



    [...]
    The availability of advanced, structured assemblers and block-structured high-level languages such as Pascal simplifies modular programming. Such concepts are virtually useless, however, unless parameters are easily transferred between and within software modules that operate on a re-entrant and recursive basis.
    [...]
    The MC68000 provides architectural features that allow efficient re-entrant modular programming. Two complementary instructions, link and allocate (LINK) and unlink (UNLK), reduce subroutine call overhead by manipulating linked lists of data areas on the stack. The move multiple register instruction (MOVEM) also reduces subroutine call programming overhead.
    [...]
    Other instructions that support modern structured programming techniques are push effective address (PEA), load effective address (LEA), return and restore (RTR), return from exception (RTE), jump to subroutine (JSR), branch to subroutine (BSR), and return from subroutine (RTS).




    The 68020 added bitfield instructions, which are used in C.





    Whereas the above processors added instructions to support programming languages, Reduced Instruction-Set Computers (RISC) took the opposite approach. By analyzing which instructions compilers actually used, they were able to discard many complex instructions that weren't being used. This allowed the architecture to be simplified, shorten the instruction cycle length, and reduce instructions to one cycle, speeding up processors significantly.






    share|improve this answer































      1














      Arguably, the relatively simple logical structure of DO loops in Fortran motivated the development of vector hardware on the early Cray and Cyber supercomputers. There may be some "chicken and egg" between hardware and software development though, since CDC Fortran included array slicing operations to encourage programmers to write "logic-free" loops long before that syntax became standardized in Fortran 90.



      Certainly the Cray XMP hardware enhancements compared with the Cray 1, such as improved "chaining" (i.e. overlapping in time) of vector operations, vector mask instructions, and gather/scatter vector addressing, were aimed at improving the performance of typical code written in "idiomatic" Fortran.



      The need to find a way to overcome the I/O bottlenecks caused by faster computation, without the prohibitive expense of large fast memory, led to the development of the early Cray SSD storage devices as an intermediate level between main memory conventional disk and tape storage devices. Fortran I/O statements made it easy to read and write a random-access file as if it were a large two-dimensional array of data.



      See section 2 of http://www.chilton-computing.org.uk/ccd/supercomputers/p005.htm for an 1988 paper by the head of the Cray XMP design team.



      There was a downside to this, in that the performance of the first Cray C compilers (and hence the first implementation of the Unix-like Cray operating system UNICOS) was abysmal, since the hardware had no native character-at-a-time instructions, and there was little computer science theory available to attempt to vectorize idiomatic "C-style" loops with a relatively unstructured combination of pointer manipulation and logical tests, compared with Fortran's more rigidly structured DO loops.






      share|improve this answer

































        1














        I recall, back in the 80’s, and referenced in the Wikipedia article, Bellmac 32 CPU, which became the AT&T Western Electric WE32100 CPU was supposedly designed for the C programming language.



        This CPU was used by AT&T in their 3B2 line of Unix systems. There was also a single board VME bus version of it that some third parties used. Zilog also came out with a line of Unix systems using this chip - I think they were a second source for it for AT&T.



        I did a lot of work with these in the 80’s and probably early 90’s. It was pretty much a dog in terms of performance, if I remember.






        share|improve this answer































          0














          One interesting example of programming languages driving hardware development is the LISP machine. Since "normal" computers of the time period couldn't execute lisp code efficiently, and there was a high demand for the language, dedicated hardware was built with the sole purpose of executing lisp code.



          These computers provided increased speed by using a stack machine instead of the typical register based design, and had native support for type checking lisp types. Some other important hardware features aided in garbage collection and closures. Here's a series of slides that go into more detail on the design: Architecture of Lisp Machines (PDF).



          The architecture of these computers are specialized enough that in order to run c code, the c source is transpiled into lisp, and then run normally. The Vacietis compiler is an example of such a system.





          share








          New contributor




          Soupy is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.




















            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "648"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            noCode: true, onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });






            Nathan is a new contributor. Be nice, and check out our Code of Conduct.










            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f8869%2fhave-programming-languages-driven-hardware-development%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            6 Answers
            6






            active

            oldest

            votes








            6 Answers
            6






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            2














            Simply yes.



            And not just a few instructions, but whole CPUs have been developed with languages in mind. Most prominent maybe Intel's 8086. Already the basic CPU was designed to support the way high level languages handle memory management, especially stack allocation and usage. With BP a separate register for stack frames and addressing was added in conjunction with short encodings for stack related addressing to make HLL programs perform. The 80186/286 went further in this direction by adding Enter/Leave instructions for stack frame handling.



            While it can be said that the base 8086 was more geared toward languages like Pascal or PL/M (*1,2), later incarnations added many ways to support the now prevalent C primitives - not at least scaling factors for indices.





            *1 - Most remarkable here the string functions which make only sense in languages supporting strings as discrete data type.



            *2 - Stephen Morse's 8086 primer is still a good read - especially when he talks about the finer details. Similar and quite recommended his 2008 interview about the 8086 creation where he describes his approach as mostly HLL driven.






            share|improve this answer




























              2














              Simply yes.



              And not just a few instructions, but whole CPUs have been developed with languages in mind. Most prominent maybe Intel's 8086. Already the basic CPU was designed to support the way high level languages handle memory management, especially stack allocation and usage. With BP a separate register for stack frames and addressing was added in conjunction with short encodings for stack related addressing to make HLL programs perform. The 80186/286 went further in this direction by adding Enter/Leave instructions for stack frame handling.



              While it can be said that the base 8086 was more geared toward languages like Pascal or PL/M (*1,2), later incarnations added many ways to support the now prevalent C primitives - not at least scaling factors for indices.





              *1 - Most remarkable here the string functions which make only sense in languages supporting strings as discrete data type.



              *2 - Stephen Morse's 8086 primer is still a good read - especially when he talks about the finer details. Similar and quite recommended his 2008 interview about the 8086 creation where he describes his approach as mostly HLL driven.






              share|improve this answer


























                2












                2








                2







                Simply yes.



                And not just a few instructions, but whole CPUs have been developed with languages in mind. Most prominent maybe Intel's 8086. Already the basic CPU was designed to support the way high level languages handle memory management, especially stack allocation and usage. With BP a separate register for stack frames and addressing was added in conjunction with short encodings for stack related addressing to make HLL programs perform. The 80186/286 went further in this direction by adding Enter/Leave instructions for stack frame handling.



                While it can be said that the base 8086 was more geared toward languages like Pascal or PL/M (*1,2), later incarnations added many ways to support the now prevalent C primitives - not at least scaling factors for indices.





                *1 - Most remarkable here the string functions which make only sense in languages supporting strings as discrete data type.



                *2 - Stephen Morse's 8086 primer is still a good read - especially when he talks about the finer details. Similar and quite recommended his 2008 interview about the 8086 creation where he describes his approach as mostly HLL driven.






                share|improve this answer













                Simply yes.



                And not just a few instructions, but whole CPUs have been developed with languages in mind. Most prominent maybe Intel's 8086. Already the basic CPU was designed to support the way high level languages handle memory management, especially stack allocation and usage. With BP a separate register for stack frames and addressing was added in conjunction with short encodings for stack related addressing to make HLL programs perform. The 80186/286 went further in this direction by adding Enter/Leave instructions for stack frame handling.



                While it can be said that the base 8086 was more geared toward languages like Pascal or PL/M (*1,2), later incarnations added many ways to support the now prevalent C primitives - not at least scaling factors for indices.





                *1 - Most remarkable here the string functions which make only sense in languages supporting strings as discrete data type.



                *2 - Stephen Morse's 8086 primer is still a good read - especially when he talks about the finer details. Similar and quite recommended his 2008 interview about the 8086 creation where he describes his approach as mostly HLL driven.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered 5 hours ago









                RaffzahnRaffzahn

                48k5108193




                48k5108193























                    2














                    Yes. Case in point, the VAX. The instruction set design was influenced by the requirements of the compiled languages of the day. For example, the orthogonality of the ISA; the provision of instructions that map to language constructs such as 'case' statements (in the numbered-case sense of Hoare's original formulation, not the labelled-case of C), loop statements, and so on.



                    VAX Architecture Ref - see the Introduction.



                    I am not claiming the VAX is unique in this respect, just an example I know a little about. As a second example, I'll mention the Burroughs B6500 'display' registers. A display, in 1960s speak, is a mechanism for efficient uplevel references. If your language, such as Algol60, permits declaration of nested procedures to any depth, then arbitrary references to the local variables of different levels of enclosing procedure require special handling. The mechanism used (the 'display') was invented for KDF9 Whetstone Algol by Randell and Russell, and described in their book Algol 60 Implementation. The B6500 incorporates that into hardware:




                    The B6500/B7500 contains a network of Display Registers (D0 through
                    D31) which are caused to point at the appropriate MSCW (Fig. 5). The
                    local variables of all procedures global to the current procedure are
                    addressed in the B6500/B7500 relative to the Display Registers.







                    share|improve this answer


























                    • as well as more registers for local variables, and large, regular address space rather than smaller banks that can be activated one at a time..

                      – Erik Eidt
                      6 hours ago


















                    2














                    Yes. Case in point, the VAX. The instruction set design was influenced by the requirements of the compiled languages of the day. For example, the orthogonality of the ISA; the provision of instructions that map to language constructs such as 'case' statements (in the numbered-case sense of Hoare's original formulation, not the labelled-case of C), loop statements, and so on.



                    VAX Architecture Ref - see the Introduction.



                    I am not claiming the VAX is unique in this respect, just an example I know a little about. As a second example, I'll mention the Burroughs B6500 'display' registers. A display, in 1960s speak, is a mechanism for efficient uplevel references. If your language, such as Algol60, permits declaration of nested procedures to any depth, then arbitrary references to the local variables of different levels of enclosing procedure require special handling. The mechanism used (the 'display') was invented for KDF9 Whetstone Algol by Randell and Russell, and described in their book Algol 60 Implementation. The B6500 incorporates that into hardware:




                    The B6500/B7500 contains a network of Display Registers (D0 through
                    D31) which are caused to point at the appropriate MSCW (Fig. 5). The
                    local variables of all procedures global to the current procedure are
                    addressed in the B6500/B7500 relative to the Display Registers.







                    share|improve this answer


























                    • as well as more registers for local variables, and large, regular address space rather than smaller banks that can be activated one at a time..

                      – Erik Eidt
                      6 hours ago
















                    2












                    2








                    2







                    Yes. Case in point, the VAX. The instruction set design was influenced by the requirements of the compiled languages of the day. For example, the orthogonality of the ISA; the provision of instructions that map to language constructs such as 'case' statements (in the numbered-case sense of Hoare's original formulation, not the labelled-case of C), loop statements, and so on.



                    VAX Architecture Ref - see the Introduction.



                    I am not claiming the VAX is unique in this respect, just an example I know a little about. As a second example, I'll mention the Burroughs B6500 'display' registers. A display, in 1960s speak, is a mechanism for efficient uplevel references. If your language, such as Algol60, permits declaration of nested procedures to any depth, then arbitrary references to the local variables of different levels of enclosing procedure require special handling. The mechanism used (the 'display') was invented for KDF9 Whetstone Algol by Randell and Russell, and described in their book Algol 60 Implementation. The B6500 incorporates that into hardware:




                    The B6500/B7500 contains a network of Display Registers (D0 through
                    D31) which are caused to point at the appropriate MSCW (Fig. 5). The
                    local variables of all procedures global to the current procedure are
                    addressed in the B6500/B7500 relative to the Display Registers.







                    share|improve this answer















                    Yes. Case in point, the VAX. The instruction set design was influenced by the requirements of the compiled languages of the day. For example, the orthogonality of the ISA; the provision of instructions that map to language constructs such as 'case' statements (in the numbered-case sense of Hoare's original formulation, not the labelled-case of C), loop statements, and so on.



                    VAX Architecture Ref - see the Introduction.



                    I am not claiming the VAX is unique in this respect, just an example I know a little about. As a second example, I'll mention the Burroughs B6500 'display' registers. A display, in 1960s speak, is a mechanism for efficient uplevel references. If your language, such as Algol60, permits declaration of nested procedures to any depth, then arbitrary references to the local variables of different levels of enclosing procedure require special handling. The mechanism used (the 'display') was invented for KDF9 Whetstone Algol by Randell and Russell, and described in their book Algol 60 Implementation. The B6500 incorporates that into hardware:




                    The B6500/B7500 contains a network of Display Registers (D0 through
                    D31) which are caused to point at the appropriate MSCW (Fig. 5). The
                    local variables of all procedures global to the current procedure are
                    addressed in the B6500/B7500 relative to the Display Registers.








                    share|improve this answer














                    share|improve this answer



                    share|improve this answer








                    edited 5 hours ago

























                    answered 6 hours ago









                    another-daveanother-dave

                    65718




                    65718













                    • as well as more registers for local variables, and large, regular address space rather than smaller banks that can be activated one at a time..

                      – Erik Eidt
                      6 hours ago





















                    • as well as more registers for local variables, and large, regular address space rather than smaller banks that can be activated one at a time..

                      – Erik Eidt
                      6 hours ago



















                    as well as more registers for local variables, and large, regular address space rather than smaller banks that can be activated one at a time..

                    – Erik Eidt
                    6 hours ago







                    as well as more registers for local variables, and large, regular address space rather than smaller banks that can be activated one at a time..

                    – Erik Eidt
                    6 hours ago













                    2














                    The first page of the Intel 8086 data sheet lists the processor's features, which include





                    • Architecture Designed for Powerful Assembly Language and Efficient High Level Languages




                    In particular, C and other high-level languages use the stack for arguments and local variables. The 8086 has both a stack pointer (SP) and a frame pointer (BP) which address memory using the stack segment (SS) rather than other segments (CS, DS, ES).



                    The datasheet for the 8087 co-processor has the following section:




                    PROGRAMMING LANGUAGE SUPPORT



                    Programs for the 8087 can be written in Intel's high-level languages for 8086/8088 and 80186/80188 systems; ASM-86 (the 8086, 8088 assembly language), PL/M-86, FORTRAN-86, and PASCAL-86.




                    The 80286 added several instructions to the architecture to aid high-level languages. PUSHA, POPA, ENTER, and LEAVE help with subroutine calls. The BOUND instruction was useful for array bounds checking and switch-style control statements. Other instructions unrelated to high-level languages were added as well.



                    The 80386 added bitfield instructions, which are used in C.





                    The Motorola MC68000 Microprocessor User's Manual states:




                    2.2.2 Structured Modular Programming



                    [...]
                    The availability of advanced, structured assemblers and block-structured high-level languages such as Pascal simplifies modular programming. Such concepts are virtually useless, however, unless parameters are easily transferred between and within software modules that operate on a re-entrant and recursive basis.
                    [...]
                    The MC68000 provides architectural features that allow efficient re-entrant modular programming. Two complementary instructions, link and allocate (LINK) and unlink (UNLK), reduce subroutine call overhead by manipulating linked lists of data areas on the stack. The move multiple register instruction (MOVEM) also reduces subroutine call programming overhead.
                    [...]
                    Other instructions that support modern structured programming techniques are push effective address (PEA), load effective address (LEA), return and restore (RTR), return from exception (RTE), jump to subroutine (JSR), branch to subroutine (BSR), and return from subroutine (RTS).




                    The 68020 added bitfield instructions, which are used in C.





                    Whereas the above processors added instructions to support programming languages, Reduced Instruction-Set Computers (RISC) took the opposite approach. By analyzing which instructions compilers actually used, they were able to discard many complex instructions that weren't being used. This allowed the architecture to be simplified, shorten the instruction cycle length, and reduce instructions to one cycle, speeding up processors significantly.






                    share|improve this answer




























                      2














                      The first page of the Intel 8086 data sheet lists the processor's features, which include





                      • Architecture Designed for Powerful Assembly Language and Efficient High Level Languages




                      In particular, C and other high-level languages use the stack for arguments and local variables. The 8086 has both a stack pointer (SP) and a frame pointer (BP) which address memory using the stack segment (SS) rather than other segments (CS, DS, ES).



                      The datasheet for the 8087 co-processor has the following section:




                      PROGRAMMING LANGUAGE SUPPORT



                      Programs for the 8087 can be written in Intel's high-level languages for 8086/8088 and 80186/80188 systems; ASM-86 (the 8086, 8088 assembly language), PL/M-86, FORTRAN-86, and PASCAL-86.




                      The 80286 added several instructions to the architecture to aid high-level languages. PUSHA, POPA, ENTER, and LEAVE help with subroutine calls. The BOUND instruction was useful for array bounds checking and switch-style control statements. Other instructions unrelated to high-level languages were added as well.



                      The 80386 added bitfield instructions, which are used in C.





                      The Motorola MC68000 Microprocessor User's Manual states:




                      2.2.2 Structured Modular Programming



                      [...]
                      The availability of advanced, structured assemblers and block-structured high-level languages such as Pascal simplifies modular programming. Such concepts are virtually useless, however, unless parameters are easily transferred between and within software modules that operate on a re-entrant and recursive basis.
                      [...]
                      The MC68000 provides architectural features that allow efficient re-entrant modular programming. Two complementary instructions, link and allocate (LINK) and unlink (UNLK), reduce subroutine call overhead by manipulating linked lists of data areas on the stack. The move multiple register instruction (MOVEM) also reduces subroutine call programming overhead.
                      [...]
                      Other instructions that support modern structured programming techniques are push effective address (PEA), load effective address (LEA), return and restore (RTR), return from exception (RTE), jump to subroutine (JSR), branch to subroutine (BSR), and return from subroutine (RTS).




                      The 68020 added bitfield instructions, which are used in C.





                      Whereas the above processors added instructions to support programming languages, Reduced Instruction-Set Computers (RISC) took the opposite approach. By analyzing which instructions compilers actually used, they were able to discard many complex instructions that weren't being used. This allowed the architecture to be simplified, shorten the instruction cycle length, and reduce instructions to one cycle, speeding up processors significantly.






                      share|improve this answer


























                        2












                        2








                        2







                        The first page of the Intel 8086 data sheet lists the processor's features, which include





                        • Architecture Designed for Powerful Assembly Language and Efficient High Level Languages




                        In particular, C and other high-level languages use the stack for arguments and local variables. The 8086 has both a stack pointer (SP) and a frame pointer (BP) which address memory using the stack segment (SS) rather than other segments (CS, DS, ES).



                        The datasheet for the 8087 co-processor has the following section:




                        PROGRAMMING LANGUAGE SUPPORT



                        Programs for the 8087 can be written in Intel's high-level languages for 8086/8088 and 80186/80188 systems; ASM-86 (the 8086, 8088 assembly language), PL/M-86, FORTRAN-86, and PASCAL-86.




                        The 80286 added several instructions to the architecture to aid high-level languages. PUSHA, POPA, ENTER, and LEAVE help with subroutine calls. The BOUND instruction was useful for array bounds checking and switch-style control statements. Other instructions unrelated to high-level languages were added as well.



                        The 80386 added bitfield instructions, which are used in C.





                        The Motorola MC68000 Microprocessor User's Manual states:




                        2.2.2 Structured Modular Programming



                        [...]
                        The availability of advanced, structured assemblers and block-structured high-level languages such as Pascal simplifies modular programming. Such concepts are virtually useless, however, unless parameters are easily transferred between and within software modules that operate on a re-entrant and recursive basis.
                        [...]
                        The MC68000 provides architectural features that allow efficient re-entrant modular programming. Two complementary instructions, link and allocate (LINK) and unlink (UNLK), reduce subroutine call overhead by manipulating linked lists of data areas on the stack. The move multiple register instruction (MOVEM) also reduces subroutine call programming overhead.
                        [...]
                        Other instructions that support modern structured programming techniques are push effective address (PEA), load effective address (LEA), return and restore (RTR), return from exception (RTE), jump to subroutine (JSR), branch to subroutine (BSR), and return from subroutine (RTS).




                        The 68020 added bitfield instructions, which are used in C.





                        Whereas the above processors added instructions to support programming languages, Reduced Instruction-Set Computers (RISC) took the opposite approach. By analyzing which instructions compilers actually used, they were able to discard many complex instructions that weren't being used. This allowed the architecture to be simplified, shorten the instruction cycle length, and reduce instructions to one cycle, speeding up processors significantly.






                        share|improve this answer













                        The first page of the Intel 8086 data sheet lists the processor's features, which include





                        • Architecture Designed for Powerful Assembly Language and Efficient High Level Languages




                        In particular, C and other high-level languages use the stack for arguments and local variables. The 8086 has both a stack pointer (SP) and a frame pointer (BP) which address memory using the stack segment (SS) rather than other segments (CS, DS, ES).



                        The datasheet for the 8087 co-processor has the following section:




                        PROGRAMMING LANGUAGE SUPPORT



                        Programs for the 8087 can be written in Intel's high-level languages for 8086/8088 and 80186/80188 systems; ASM-86 (the 8086, 8088 assembly language), PL/M-86, FORTRAN-86, and PASCAL-86.




                        The 80286 added several instructions to the architecture to aid high-level languages. PUSHA, POPA, ENTER, and LEAVE help with subroutine calls. The BOUND instruction was useful for array bounds checking and switch-style control statements. Other instructions unrelated to high-level languages were added as well.



                        The 80386 added bitfield instructions, which are used in C.





                        The Motorola MC68000 Microprocessor User's Manual states:




                        2.2.2 Structured Modular Programming



                        [...]
                        The availability of advanced, structured assemblers and block-structured high-level languages such as Pascal simplifies modular programming. Such concepts are virtually useless, however, unless parameters are easily transferred between and within software modules that operate on a re-entrant and recursive basis.
                        [...]
                        The MC68000 provides architectural features that allow efficient re-entrant modular programming. Two complementary instructions, link and allocate (LINK) and unlink (UNLK), reduce subroutine call overhead by manipulating linked lists of data areas on the stack. The move multiple register instruction (MOVEM) also reduces subroutine call programming overhead.
                        [...]
                        Other instructions that support modern structured programming techniques are push effective address (PEA), load effective address (LEA), return and restore (RTR), return from exception (RTE), jump to subroutine (JSR), branch to subroutine (BSR), and return from subroutine (RTS).




                        The 68020 added bitfield instructions, which are used in C.





                        Whereas the above processors added instructions to support programming languages, Reduced Instruction-Set Computers (RISC) took the opposite approach. By analyzing which instructions compilers actually used, they were able to discard many complex instructions that weren't being used. This allowed the architecture to be simplified, shorten the instruction cycle length, and reduce instructions to one cycle, speeding up processors significantly.







                        share|improve this answer












                        share|improve this answer



                        share|improve this answer










                        answered 3 hours ago









                        Dr SheldonDr Sheldon

                        1,0311623




                        1,0311623























                            1














                            Arguably, the relatively simple logical structure of DO loops in Fortran motivated the development of vector hardware on the early Cray and Cyber supercomputers. There may be some "chicken and egg" between hardware and software development though, since CDC Fortran included array slicing operations to encourage programmers to write "logic-free" loops long before that syntax became standardized in Fortran 90.



                            Certainly the Cray XMP hardware enhancements compared with the Cray 1, such as improved "chaining" (i.e. overlapping in time) of vector operations, vector mask instructions, and gather/scatter vector addressing, were aimed at improving the performance of typical code written in "idiomatic" Fortran.



                            The need to find a way to overcome the I/O bottlenecks caused by faster computation, without the prohibitive expense of large fast memory, led to the development of the early Cray SSD storage devices as an intermediate level between main memory conventional disk and tape storage devices. Fortran I/O statements made it easy to read and write a random-access file as if it were a large two-dimensional array of data.



                            See section 2 of http://www.chilton-computing.org.uk/ccd/supercomputers/p005.htm for an 1988 paper by the head of the Cray XMP design team.



                            There was a downside to this, in that the performance of the first Cray C compilers (and hence the first implementation of the Unix-like Cray operating system UNICOS) was abysmal, since the hardware had no native character-at-a-time instructions, and there was little computer science theory available to attempt to vectorize idiomatic "C-style" loops with a relatively unstructured combination of pointer manipulation and logical tests, compared with Fortran's more rigidly structured DO loops.






                            share|improve this answer






























                              1














                              Arguably, the relatively simple logical structure of DO loops in Fortran motivated the development of vector hardware on the early Cray and Cyber supercomputers. There may be some "chicken and egg" between hardware and software development though, since CDC Fortran included array slicing operations to encourage programmers to write "logic-free" loops long before that syntax became standardized in Fortran 90.



                              Certainly the Cray XMP hardware enhancements compared with the Cray 1, such as improved "chaining" (i.e. overlapping in time) of vector operations, vector mask instructions, and gather/scatter vector addressing, were aimed at improving the performance of typical code written in "idiomatic" Fortran.



                              The need to find a way to overcome the I/O bottlenecks caused by faster computation, without the prohibitive expense of large fast memory, led to the development of the early Cray SSD storage devices as an intermediate level between main memory conventional disk and tape storage devices. Fortran I/O statements made it easy to read and write a random-access file as if it were a large two-dimensional array of data.



                              See section 2 of http://www.chilton-computing.org.uk/ccd/supercomputers/p005.htm for an 1988 paper by the head of the Cray XMP design team.



                              There was a downside to this, in that the performance of the first Cray C compilers (and hence the first implementation of the Unix-like Cray operating system UNICOS) was abysmal, since the hardware had no native character-at-a-time instructions, and there was little computer science theory available to attempt to vectorize idiomatic "C-style" loops with a relatively unstructured combination of pointer manipulation and logical tests, compared with Fortran's more rigidly structured DO loops.






                              share|improve this answer




























                                1












                                1








                                1







                                Arguably, the relatively simple logical structure of DO loops in Fortran motivated the development of vector hardware on the early Cray and Cyber supercomputers. There may be some "chicken and egg" between hardware and software development though, since CDC Fortran included array slicing operations to encourage programmers to write "logic-free" loops long before that syntax became standardized in Fortran 90.



                                Certainly the Cray XMP hardware enhancements compared with the Cray 1, such as improved "chaining" (i.e. overlapping in time) of vector operations, vector mask instructions, and gather/scatter vector addressing, were aimed at improving the performance of typical code written in "idiomatic" Fortran.



                                The need to find a way to overcome the I/O bottlenecks caused by faster computation, without the prohibitive expense of large fast memory, led to the development of the early Cray SSD storage devices as an intermediate level between main memory conventional disk and tape storage devices. Fortran I/O statements made it easy to read and write a random-access file as if it were a large two-dimensional array of data.



                                See section 2 of http://www.chilton-computing.org.uk/ccd/supercomputers/p005.htm for an 1988 paper by the head of the Cray XMP design team.



                                There was a downside to this, in that the performance of the first Cray C compilers (and hence the first implementation of the Unix-like Cray operating system UNICOS) was abysmal, since the hardware had no native character-at-a-time instructions, and there was little computer science theory available to attempt to vectorize idiomatic "C-style" loops with a relatively unstructured combination of pointer manipulation and logical tests, compared with Fortran's more rigidly structured DO loops.






                                share|improve this answer















                                Arguably, the relatively simple logical structure of DO loops in Fortran motivated the development of vector hardware on the early Cray and Cyber supercomputers. There may be some "chicken and egg" between hardware and software development though, since CDC Fortran included array slicing operations to encourage programmers to write "logic-free" loops long before that syntax became standardized in Fortran 90.



                                Certainly the Cray XMP hardware enhancements compared with the Cray 1, such as improved "chaining" (i.e. overlapping in time) of vector operations, vector mask instructions, and gather/scatter vector addressing, were aimed at improving the performance of typical code written in "idiomatic" Fortran.



                                The need to find a way to overcome the I/O bottlenecks caused by faster computation, without the prohibitive expense of large fast memory, led to the development of the early Cray SSD storage devices as an intermediate level between main memory conventional disk and tape storage devices. Fortran I/O statements made it easy to read and write a random-access file as if it were a large two-dimensional array of data.



                                See section 2 of http://www.chilton-computing.org.uk/ccd/supercomputers/p005.htm for an 1988 paper by the head of the Cray XMP design team.



                                There was a downside to this, in that the performance of the first Cray C compilers (and hence the first implementation of the Unix-like Cray operating system UNICOS) was abysmal, since the hardware had no native character-at-a-time instructions, and there was little computer science theory available to attempt to vectorize idiomatic "C-style" loops with a relatively unstructured combination of pointer manipulation and logical tests, compared with Fortran's more rigidly structured DO loops.







                                share|improve this answer














                                share|improve this answer



                                share|improve this answer








                                edited 6 hours ago

























                                answered 6 hours ago









                                alephzeroalephzero

                                1,6281613




                                1,6281613























                                    1














                                    I recall, back in the 80’s, and referenced in the Wikipedia article, Bellmac 32 CPU, which became the AT&T Western Electric WE32100 CPU was supposedly designed for the C programming language.



                                    This CPU was used by AT&T in their 3B2 line of Unix systems. There was also a single board VME bus version of it that some third parties used. Zilog also came out with a line of Unix systems using this chip - I think they were a second source for it for AT&T.



                                    I did a lot of work with these in the 80’s and probably early 90’s. It was pretty much a dog in terms of performance, if I remember.






                                    share|improve this answer




























                                      1














                                      I recall, back in the 80’s, and referenced in the Wikipedia article, Bellmac 32 CPU, which became the AT&T Western Electric WE32100 CPU was supposedly designed for the C programming language.



                                      This CPU was used by AT&T in their 3B2 line of Unix systems. There was also a single board VME bus version of it that some third parties used. Zilog also came out with a line of Unix systems using this chip - I think they were a second source for it for AT&T.



                                      I did a lot of work with these in the 80’s and probably early 90’s. It was pretty much a dog in terms of performance, if I remember.






                                      share|improve this answer


























                                        1












                                        1








                                        1







                                        I recall, back in the 80’s, and referenced in the Wikipedia article, Bellmac 32 CPU, which became the AT&T Western Electric WE32100 CPU was supposedly designed for the C programming language.



                                        This CPU was used by AT&T in their 3B2 line of Unix systems. There was also a single board VME bus version of it that some third parties used. Zilog also came out with a line of Unix systems using this chip - I think they were a second source for it for AT&T.



                                        I did a lot of work with these in the 80’s and probably early 90’s. It was pretty much a dog in terms of performance, if I remember.






                                        share|improve this answer













                                        I recall, back in the 80’s, and referenced in the Wikipedia article, Bellmac 32 CPU, which became the AT&T Western Electric WE32100 CPU was supposedly designed for the C programming language.



                                        This CPU was used by AT&T in their 3B2 line of Unix systems. There was also a single board VME bus version of it that some third parties used. Zilog also came out with a line of Unix systems using this chip - I think they were a second source for it for AT&T.



                                        I did a lot of work with these in the 80’s and probably early 90’s. It was pretty much a dog in terms of performance, if I remember.







                                        share|improve this answer












                                        share|improve this answer



                                        share|improve this answer










                                        answered 5 hours ago









                                        mannaggiamannaggia

                                        1,111157




                                        1,111157























                                            0














                                            One interesting example of programming languages driving hardware development is the LISP machine. Since "normal" computers of the time period couldn't execute lisp code efficiently, and there was a high demand for the language, dedicated hardware was built with the sole purpose of executing lisp code.



                                            These computers provided increased speed by using a stack machine instead of the typical register based design, and had native support for type checking lisp types. Some other important hardware features aided in garbage collection and closures. Here's a series of slides that go into more detail on the design: Architecture of Lisp Machines (PDF).



                                            The architecture of these computers are specialized enough that in order to run c code, the c source is transpiled into lisp, and then run normally. The Vacietis compiler is an example of such a system.





                                            share








                                            New contributor




                                            Soupy is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                            Check out our Code of Conduct.

























                                              0














                                              One interesting example of programming languages driving hardware development is the LISP machine. Since "normal" computers of the time period couldn't execute lisp code efficiently, and there was a high demand for the language, dedicated hardware was built with the sole purpose of executing lisp code.



                                              These computers provided increased speed by using a stack machine instead of the typical register based design, and had native support for type checking lisp types. Some other important hardware features aided in garbage collection and closures. Here's a series of slides that go into more detail on the design: Architecture of Lisp Machines (PDF).



                                              The architecture of these computers are specialized enough that in order to run c code, the c source is transpiled into lisp, and then run normally. The Vacietis compiler is an example of such a system.





                                              share








                                              New contributor




                                              Soupy is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                              Check out our Code of Conduct.























                                                0












                                                0








                                                0







                                                One interesting example of programming languages driving hardware development is the LISP machine. Since "normal" computers of the time period couldn't execute lisp code efficiently, and there was a high demand for the language, dedicated hardware was built with the sole purpose of executing lisp code.



                                                These computers provided increased speed by using a stack machine instead of the typical register based design, and had native support for type checking lisp types. Some other important hardware features aided in garbage collection and closures. Here's a series of slides that go into more detail on the design: Architecture of Lisp Machines (PDF).



                                                The architecture of these computers are specialized enough that in order to run c code, the c source is transpiled into lisp, and then run normally. The Vacietis compiler is an example of such a system.





                                                share








                                                New contributor




                                                Soupy is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                Check out our Code of Conduct.










                                                One interesting example of programming languages driving hardware development is the LISP machine. Since "normal" computers of the time period couldn't execute lisp code efficiently, and there was a high demand for the language, dedicated hardware was built with the sole purpose of executing lisp code.



                                                These computers provided increased speed by using a stack machine instead of the typical register based design, and had native support for type checking lisp types. Some other important hardware features aided in garbage collection and closures. Here's a series of slides that go into more detail on the design: Architecture of Lisp Machines (PDF).



                                                The architecture of these computers are specialized enough that in order to run c code, the c source is transpiled into lisp, and then run normally. The Vacietis compiler is an example of such a system.






                                                share








                                                New contributor




                                                Soupy is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                Check out our Code of Conduct.








                                                share


                                                share






                                                New contributor




                                                Soupy is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                Check out our Code of Conduct.









                                                answered 25 secs ago









                                                SoupySoupy

                                                1




                                                1




                                                New contributor




                                                Soupy is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                Check out our Code of Conduct.





                                                New contributor





                                                Soupy is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                Check out our Code of Conduct.






                                                Soupy is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                Check out our Code of Conduct.






















                                                    Nathan is a new contributor. Be nice, and check out our Code of Conduct.










                                                    draft saved

                                                    draft discarded


















                                                    Nathan is a new contributor. Be nice, and check out our Code of Conduct.













                                                    Nathan is a new contributor. Be nice, and check out our Code of Conduct.












                                                    Nathan is a new contributor. Be nice, and check out our Code of Conduct.
















                                                    Thanks for contributing an answer to Retrocomputing Stack Exchange!


                                                    • Please be sure to answer the question. Provide details and share your research!

                                                    But avoid



                                                    • Asking for help, clarification, or responding to other answers.

                                                    • Making statements based on opinion; back them up with references or personal experience.


                                                    To learn more, see our tips on writing great answers.




                                                    draft saved


                                                    draft discarded














                                                    StackExchange.ready(
                                                    function () {
                                                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f8869%2fhave-programming-languages-driven-hardware-development%23new-answer', 'question_page');
                                                    }
                                                    );

                                                    Post as a guest















                                                    Required, but never shown





















































                                                    Required, but never shown














                                                    Required, but never shown












                                                    Required, but never shown







                                                    Required, but never shown

































                                                    Required, but never shown














                                                    Required, but never shown












                                                    Required, but never shown







                                                    Required, but never shown







                                                    Popular posts from this blog

                                                    GameSpot

                                                    日野市

                                                    Tu-95轟炸機