Re: Thoughts and Opinions or something like that

["chris.danx" <chris.danx@ntlworld.com>]

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