music

OSdata.com

design goals

summary

    I am building the world’s most bizarre lessons on assembly language programming.

    I will provide the student with free PHP source code for an emulator for a computer that doesn’t even exist.

    I will challenge the student to build an assembly language emulator in any other programming language.

    And I will challenge the student to use their own emulator to build their own Forth-like personal threaded interpretative language.

    Then I will challenge the student to use their threaded interpretative language to build translators (both compiler and decompiler) for their favorite high level programming language (either an existing language or a new one of the student’s invention).

    And finally I will challenge the student to use their own tools to coordinate with others to build language-independent projects superior to anything that Google can achieve by spending huge amounts of money on lobbyists.

language independence

    The three big problems facing large businesses like Google are:

1. Slow turn around time caused by dependencies involving large programs maintained by large teams.
2. Poor tools for efficient distributed and parallel programming.
3. The Babel of different programming languages.

    No single programming language is superior for all purposes, but most modern programming languages are reasonably capable for most kinds of single processor small scale projects.

    Language preference today is mostly psychological.

    If every programmer on a team can program in their own favorite programming language (even a personal one that only they know), then each individual programmer will be most productive.

    A good set of translators will allow programmers coding in different programming languages to work together on common projects and share source code. Each programmer will see all of the work in his or her own preferred programming language.

simplified discussion for Jimmy and other business persons

assembly language

    This chapter explains the amazing goals for an assembly language teaching machine.

    I will briefly explain the design decisions.

PHP

    This project is written in PHP. Not because of any possible advantages of PHP, but rather because PHP is available for free.

    I will heavily comment the code so that students can follow along without any need to actually understand PHP.

quick and dirty

    I am unfortunately going to have to code in a quick and dirty manner. This is very bad programming practice and makes it very difficult for anyone to maintain my code.

    I am doing this because as a homeless person I am in a race against the clock for how long I can live. The lack of adequate food and shelter dramatically shortens a person’s life. Given my short life expectancy, I can only complete this project by using clever shortcuts.

    Even so, I do need help. It is vital that I find a way to work indoors. Soon. If anyone in Costa Mesa has a business or charity that can provide office space (with a lock), electricity, internet connections, desk, and chair, please contact me immediately. Note that it is vital that I be able to program very long hours seven days a week. I am in a race against time before death and need the maximum amount of effective work time possible.

emulator

    At the core of this project is a free open source emulator for a non-existent processor.

    When assembly language was used in the real world, it made sense to learn a specific processor that was in common use.

    Assembly language is almost never used anymore. The main reason that assembly language is still used as a teaching tool is because it is a great way to learn how processors (computers) work internally.

    Real processors have various levels of weirdness to them. These special cases make real processors difficult to learn.

    An artificial processor designed for learning will be easier to learn. Once the student has mastered the principles of assembly language programming, it is much easier to deal with the strangeness of any specific processor.

    But there is another reason for this design decision.

    Eventually we are going to use this artificial processor as an intermediate internal language for compiling high level languages.

    We will be able to map any construct of any high level language to our intermediate assembly language, and then translate from the intermediate language to any specific real processor.

assembler

    Any software emulator is going to be very slow because of how many different things that hardware normally does “simultaneously”.

    A software emulator is fine for small programs, but becomes unacceptably slow with any decent sized program.

    The intermediate language is written with the specific intent that it be easy to map it to almost any hardware using a simple block substitution system augmented by register coloring and a few other simple techniques.

    While each student is encouraged to create their own mapping to a specific processor or computer, I will create a few mappings for some famous processors (probably including IBM 704, IBM 360, DEC VAX, Motorola 680x0, National Semiconductor 32000, Acorn ARM, and Sun SPARC/UltraSPARC.

    Pretty much any computer or processor manufacturer is welcome to pay for a mapping for any of their hardware.

threaded interpretative language (TIL)

    In the past it was typical to teach assembly language programming using very simple programming problems.

    The assumption was that a student simply couldn’t handle the complexity of learning assembly language and the complexity of a real world programming problem at the same time.

    I am going to use the construction of a threaded interpreative language (TIL), similar to and based on Forth, as the primary programming example.

    A TIL can include all of the ideas of assembly language., meaning that all topics will be covered in a real world setting.

    Each student will end up with his or her own customized TIL, which the student can then use for any purpose.

    A TIL is an inherently efficient design for building low loevel software, including a monitor. We will be able to use the reuslting TILs for many useful aspects of this project.

compilers

    The most common technique in translating high level source code into object (machine) code or some intermediate postfix code.

    A TIL is by its nature postfix and can easily be extended to include any postfix intermediate language.

    This will be used to give every student both a compiler and an interpretter for the high level programming language of his or her choice.

    it is also possible for those who build their own custom TILs to then share each others compilers.

    This will set us free from the current problem of a large number of programming languages in use (especially if we include the larger number of domain specific languages).

    if well designed, we can translate from any high level language into the intermediate code and then back up to any other high level language, allowing programmers on a large team to write in a multitude of languages on the same project.

monitors

    A TIL is a particularly good method for implementing a system monitor.

    By adding communications routines, it becomes possible to run copies of the TIL on multiple cores in a single processor or on many processors distributed over a large scale system.

    This helps us address two of the biggest problems facing Google and other very large companies: speed of compilation and making effective use of distributed systems.

dependency bottleneck

    One of the reasons that Google developed the Go programming language was to speed up compilation of large projects.

    The bottleneck was checking the dependencies of code over a very large set of source code files spread over many computers and worked on by many different programmers.

    This project will make it possible to solve this problem.

    While some members of a large team may choose programming languages that don’t lend themselves to eliminating this bottleneck, some will make an appropriate choice.

    And those programmers who create their own language can make sure that their custom language meets this criteria.

parallel processing

    One of the great problems in large systems is making efficient use of the large number of processors.

    Few traditional programming languages have mechanisms for distributed or parallel processing.

    As above, programmers using a custom programming language can simply make sure that they include support for parallel processing.

    Additionally, because of the design of the intermediate programming language, it will be possible to identify at least some possibilities for efficient parallel processing once the original high level language source code (for any arbitrary existing language) is translated into the intermediate programming language. This will be done by using techniques similar to those used by optimizing compilers.

contact

    If you find this interesting and want to contact me, write to Milo, PO Box 5237, Balboa Island, California, 92662, USA.

if you want to make a tax-deductible donation to the StarTree107 Foundation to support this educational work, contact Dr. Barry at 949-675-5778

    Challenge: Homeless or Facebook