From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 107f24,6f568a2e6507575 X-Google-Attributes: gid107f24,public X-Google-Thread: f891f,6f568a2e6507575 X-Google-Attributes: gidf891f,public X-Google-Thread: 103376,6f568a2e6507575 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-04-24 16:32:30 PST Path: newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!212.74.64.35!colt.net!newspeer.clara.net!news.clara.net!news5-gui.server.ntli.net!ntli.net!news6-win.server.ntlworld.com.POSTED!not-for-mail From: "chris.danx" Newsgroups: comp.lang.ada,comp.lang.functional,comp.lang.misc References: Subject: Re: Thoughts and Opinions or something like that X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: Date: Wed, 25 Apr 2001 00:27:47 +0100 NNTP-Posting-Host: 62.253.9.118 X-Complaints-To: abuse@ntlworld.com X-Trace: news6-win.server.ntlworld.com 988154838 62.253.9.118 (Wed, 25 Apr 2001 00:27:18 BST) NNTP-Posting-Date: Wed, 25 Apr 2001 00:27:18 BST Organization: ntlworld News Service Xref: newsfeed.google.com comp.lang.ada:6904 comp.lang.functional:5269 comp.lang.misc:1121 Date: 2001-04-25T00:27:47+01:00 List-Id: Hi Ted, > says... > >will complete this soon, but i've been thinking my approach is flawed. Not to > >say RISC is bad, but maybe it's too simplistic or lacks specific support for > >features that'd make it A:more efficient and B:easier to program. > > My memory from my architecture courses in college (maybe I'm no expert, but I > took that damn course 3 times...) on RISC is: > > o RISC is not *supposed* to be easy to program. Its supposed to give compiler > writers the minimal tools they will need. Programmers are supposed to use the > compilers, not RISC. If you are writing assembly language RISC code, you are > either writing a compiler, or you are fighting the system. > > o What is efficient depends on the rest of the architecture; particularly on > where the bottlenecks are. In this day and age, the bottleneck is in accessing > memory. Thus you want a lot of register-to-register instructions, and memory > accesses should be the last resort. Also, efficency requres that you "pipeline" > instructions, like on an assembly-line. Doing that, using hardware, without > having one in-progress instruction screw up another, is very complicated. To > make it achievable, you don't want to have lots of instructions, and you don't > want the ones you have to do very much. > > Now the question you should be asking is, "Do these design goal make sense for > my virtual machine?" Unless you have an eye on making it an acutal machine, or > performing one-to-one transformations into the target platform's RISC code, I'd > guess the answer would be "no". > The reason i started with a RISC Architecture was that i originally planned to have kind of generic assembly language that could be translated to native hardware easily. A smart conversion program would be able to figure out improvements in CISC machines -- e.g. instead of loading from memory and adding, fold them into one. I don't really know if this smart optimisation would be benefitial. For RISC machines the translation would be fairly straight forward i think. Then i realised that one of the goals i wanted was interactive program development. This means i can supply sample arguments and watch what the program does with it in a _virtual environment_ -- VE is primarily for safety reasons (i'm not as competent at assembly as i'd like to be). This is for later but it occured to me that the VM approach would work for me on this. If i could avoid VMs i would, i planned way way back to not use them for portability, and use a kind of hybrid description-assembly language, that could be optimised for native platforms. I'd looked at the JVM, but it's not a model i like. It has too much dependance on the stack, which is good for VM but not good for optimisations and other things. The crued method support also annoyed me. I was planning to port Ada to JVM before JGNAT became available. *For simulation the VM seems to win. For portability RISC seems to win.* Then i thought about doing more an Architecture specific to the concepts i wanted in the language. When i read the post somewhere i thought since i have little experience(just a CS Student who programs for uni and as a hobby) in comparison to all the veterans out there, it seemed like a good idea to ask all the folk out there. Chicken and egg... My plan for the language goes along a similar path. Start with a simple prototype, test it out, study results. Build another prototype, test it out, study results. Build new prototype integrating main points of results and see how they glue, test it out, study results, and keep going. Of course planning is important and if correctly done, many features may integrate without much trouble. The language testing will probably be done on the current RISC vm, but in the interests of efficiency it might be best once the language is _stable_ for a more specific VM, to be developed. I like to plan ahead, hence this post. Chris