> At 8:07 AM +1000 on 2/10/00, Paul Sutton wrote:
> >Adrian: Anthony, I have been reviewing the things that are sitting around
> >on my hard drive here at home and discovered a file "NuParser.png" which
> >is a diagram of the conceptual foundation of NuParser. There are a
> >couple of things that concern me about this diagram but there is not
> >enough information in the diagram to be sure that these concerns are
> >founded, or to discuss them informatively.
>
> Anthony: I'm not sure to which diagram you are referring. Please send me a copy.
> I don't have any file called "NuParser.png" around here. And the mail
> archive search is down.
Adrian: I'll send you a copy when I can (I've moved again and am
just starting to reorganize).
> >Adrian: Has documentation relating to NuParser been uploaded to the UFP
> >server yet?
>
> Anthony: No. NuParser is not done yet, and has not been documented yet. It has
> online help, the incomplete version of which has been pasted to the end
> of this message.
Adrian: Okay. I will look carefully at these docs in the next few
days.
> Anthony: NOTE: NuParser is a parser generator, like bison.
NuInterpreter is the
> (presently nonexistant) new interpreter generated with NuParser instead
> of Bison. Interpreter is the old snapshot from summer(?). The naming
> confusion will be straitened out sometime. Anyone with suggestions for
> better names should mail me.
Adrian: yes, I understand this - sorry if I've used the wrong terminology somewhere.
> >if this is still the case could any
> >documentation relating to nullCPU assembly be uploaded as well?
>
> Look in the Interpreter sources, in NullCPUInstr.h. That's the best
> documentation availible. Most of it is fairly obvious (e.g., multiply),
> some is based in HT (e.g., mod) and some in PPCAsm (e.g., bc).
>
> Also, OTDisAsm.cp contains the disasembler and CodeRunner.cp the actual
> emulator.
Adrian: Okay, this will need to be improved on (I would think).
Code is generally not suitable documentation - though it should
contain documentation. I'll take a look and see what I can come
up with, this is dependant on me understanding it though.
> >It would also help with my
> >understanding of C/C++
>
> The Interpreter is _not_ a good place to try and understand C/C++. The
> interpreter is the only place that when the choice is a 1% speed gain
> vs. 100x more readability, the speed gain is chosen.
>
> You can see all sorts of evils, such as a single string being used a
> both a C and Pascal string in OTVar.h (which, stunningly, is
> well-documented)
Adrian: Unfortunately, a great deal of C code is written like this. It
is a useful way to learn C++ and that is more important to me than
an easy way. I would rather invest more time in learning and
achieve something useful at the same time than less time learning
without making useful progress.
