RISC big or small. Harvard Architecture or pseudo-Von Neuman?

Started by G. Kramer Herzog August 24, 2005
I look at the documentation for the BX-01 and then I go to Amtel's
site for more hardward information and I just seem to get a bit
confused.

First of all, Amtel does define the BasicX microprocessors as reduced
instruction set [RISC]. The whole idea was to eliminate the
complexity of Assembly language encoding.

But Amtel's AVR RISC has 100 or so instructions [where as Microchip's
PIC has about 30 and so does SX-Ubicom].

So, why do they claim to have RISC?

Then we get into the memory architecture of Harvard versus VonNeuman.
PIC and SX-UBicom are clearly Harvard, but the BX-01 appears to be
using a system of addressing that is quite similar to VonNeuman.
Granted that maybe you cannot easily mix program and data in RAM, but
you certainly have a lot more RAM to play with that the other Harvard
chips.

In sum, I really am struggling to come to terms with how the Amtel
AVR thinks of itself in terms of usefulness. It is somewhere between
the two more typical solutions. Is it special because of this or
just an big complex machine?



G. Kramer Herzog wrote:

> In sum, I really am struggling to come to terms with how the Amtel
> AVR thinks of itself in terms of usefulness. It is somewhere between
> the two more typical solutions. Is it special because of this or
> just an big complex machine?
>
This group is about BasicX and not AVR. I suggest you ask your question
on the AVR-Chat group. The answer to your question doesn't make any
difference, does it?

Mike



Well, I sort of agree that this is a little off topic for BASICX
issues, but it does apply to our hardware even if we BasicX users do
not DIRECTLY see the underlying structures.

THese structures do affect what the BasicX designers were able to
do, and I suspect that the true RISC chips were inadequate.

So, we can thank our lucky stars that the AVRs exist because it
allows the BasicX type of chips to exist.

As for whether AVRs are truely RISC, well, what are the advantages
of RISC? 1) 8 bit instructions, 2) all instructions executing in 1
or 2 clock cycles, preferably 1.

These goals are nearly always met with the AVR arcitecture. So, as
far as the functions go, the AVRs are very RISC-like. But within
these constraints, the AVR designers gave us some more powerful
commands to work with. A definite advantage.

What's not to like about more program and data memory? More speed
would be good too! As long as the CPU efficiency is maintained....

-Tony
--- In basicx@basi..., "G. Kramer Herzog" <hwanghetw@y...>
wrote:
> I look at the documentation for the BX-01 and then I go to Amtel's
> site for more hardward information and I just seem to get a bit
> confused.
>
> First of all, Amtel does define the BasicX microprocessors as
reduced
> instruction set [RISC]. The whole idea was to eliminate the
> complexity of Assembly language encoding.
>
> But Amtel's AVR RISC has 100 or so instructions [where as
Microchip's
> PIC has about 30 and so does SX-Ubicom].
>
> So, why do they claim to have RISC?
>
> Then we get into the memory architecture of Harvard versus
VonNeuman.
> PIC and SX-UBicom are clearly Harvard, but the BX-01 appears to be
> using a system of addressing that is quite similar to VonNeuman.
> Granted that maybe you cannot easily mix program and data in RAM,
but
> you certainly have a lot more RAM to play with that the other
Harvard
> chips.
>
> In sum, I really am struggling to come to terms with how the Amtel
> AVR thinks of itself in terms of usefulness. It is somewhere
between
> the two more typical solutions. Is it special because of this or
> just an big complex machine?



> This group is about BasicX and not AVR. I suggest you ask your
question
> on the AVR-Chat group. The answer to your question doesn't make any
> difference, does it?
>
> Mike

I suppose that I haven't made myself clear.

BasicX is written solely to operate two distinct Amtel AVR chips.

In is not a portable language that moves from platform to platform
and it both depends on and conceptually originates from the AVR
capabilities.

The whole concept of BASIC languages on RISC microcontrollers seems
particularly related to the Harvard Architecture and the RISC
offering the learner the kind of environment where it becomes easier
to learn the hardware and eventually the assembly language.

Both BasicX and the AVR seem to explore the boundaries more than
their competators.

Also, I assume that some of us eventually might move into Assembly
language programing if we have enough time and develop a keener
understanding of what the distinct and unusual properties of a
product [the AVR] are.

Please forgive me, if you don't agree. But, I really find the BX-01
to be a quite unique and puzzling chip. Unlike the BasicAtom, the
BasicStamp, the PICs, or any other of the 24pin DIP microcontrollers
with somewhat similar Basic language support.

I enjoy your contributions to identifying the 'BasicX way of
programing'. It seems that is a quite powerful and easily integrated
software [uses Visual Basic to some extent, so you can create GUI in
the Windows environment to interface with the BX-01, BX-35, or BX-24].

Nonetheless, I still am working on understanding the BX-01 as it
seems to be mostly ignored and yet very useful. You must admit that
you have set aside the BX-01,too. The larger instruction set and the
multiplexed data and addressing are certainly used in BasicX in the
BX-01.

And, you cannot fully understand features such as Capture or Analogue
to Digital without opening the hood and looking at the hardware.


--- In basicx@basi..., "G. Kramer Herzog" <hwanghetw@y...>
wrote:
> [BasicX] is not a portable language that moves from platform to
> platform and it both depends on and conceptually originates
> from the AVR capabilities.

This assertion is incorrect, in my opinion. The BasicX language
itself has nothing to do directly with the hardware on which it is
implemented. The language would be no different if the virtual
machine were re-targeted to an MCU with a von Neumann architecture,
e.g. 68HC01, or if it were re-targeted to your x86-based PC or even
the PIC.

Some aspects of the System Library routines are specific to the AVR
microcontrollers and might need to be changed if a different MCU
were targeted. However, I cannot see anything in the System Library
routines that remotely suggests that they are implemented on a RISC-
based architecture. The only hint of Harvard architecture is that
there are different functions for accessing RAM and EEPROM. That
distinction would probably not be necessary for an underlying von
Neumann architecture.

> The whole concept of BASIC languages on RISC microcontrollers
> seems particularly related to the Harvard Architecture and the
> RISC offering the learner the kind of environment where it
> becomes easier to learn the hardware and eventually the assembly
> language.

I don't see the connection at all. Your assertion is somewhat akin
to suggesting that driving a car that has diesel engine will make it
easier to become an expert diesel mechanic. The driving experience
is not much different whether the vehicle is a gasser, a diesel or a
hybrid. The casual user may not even notice a difference. On the
other hand, an experienced mechanic or engineer might.

Don



I. too, must disagree, Kramer.

The whole point of a high level language like basic is to insulate
you from the internals of the hardware. This basic running on the
little uC is extremely similar to other versions running on very
different hardware. Unless you decide to interact with hardware
registers, you would never know what you are running on (except for
memory limitations)

Learning BasicX in no way prepares you for Assembly Language, other
than teaching you logic and stuff.

However, I think that ASM has a more limited application than you
seem to indicate. Getting down to the level of ASM is not necessary
for most of us. I _do_ find that the strong typing required my
BasicX is very similar to C. As a matter of fact, I can port my
basic code to C VERY easily. C is much easier to maintain than
ASM. These days, I think most stuff is being written in a higher
level language, like C, then there may be hand-coded ASM routines
for the bottlenecks

For instance, I started the design of a rally computer in BAsicX,
mostly to see if it could be done, and to see what the constrains
were. Once I got it working in a simple manner, and had the
external hardware somewhat functional, I could choose the AVR
hardware to get down to some real horsepower. I ended up with an
ATMega128. Now I am testing some new hardware (realtime clock and
precision oscillator) on the BX, and once I get the hardware and
interface algorithm, I will re-write it in C for the AVR. (I am
considering a Ramtron combined RTC, and 32KB Ferroelectric RAM).
Using the BX allows me to do the basic stuff and get it working
easily and smoothly before I rip up my development board with the
ARV hardware, LCD displays, switches, etc.

I really like the BX for its simplicity and INSULATION from the
hardware.

-Tony

--- In basicx@basi..., "G. Kramer Herzog" <hwanghetw@y...>
wrote:
>
> > This group is about BasicX and not AVR. I suggest you ask your
> question
> > on the AVR-Chat group. The answer to your question doesn't make
any
> > difference, does it?
> >
> > Mike
>
> I suppose that I haven't made myself clear.
>
> BasicX is written solely to operate two distinct Amtel AVR chips.
>
> In is not a portable language that moves from platform to platform
> and it both depends on and conceptually originates from the AVR
> capabilities.
>
> The whole concept of BASIC languages on RISC microcontrollers
seems
> particularly related to the Harvard Architecture and the RISC
> offering the learner the kind of environment where it becomes
easier
> to learn the hardware and eventually the assembly language.
>
> Both BasicX and the AVR seem to explore the boundaries more than
> their competators.
>
> Also, I assume that some of us eventually might move into Assembly
> language programing if we have enough time and develop a keener
> understanding of what the distinct and unusual properties of a
> product [the AVR] are.
>
> Please forgive me, if you don't agree. But, I really find the BX-
01
> to be a quite unique and puzzling chip. Unlike the BasicAtom, the
> BasicStamp, the PICs, or any other of the 24pin DIP
microcontrollers
> with somewhat similar Basic language support.
>
> I enjoy your contributions to identifying the 'BasicX way of
> programing'. It seems that is a quite powerful and easily
integrated
> software [uses Visual Basic to some extent, so you can create GUI
in
> the Windows environment to interface with the BX-01, BX-35, or BX-
24].
>
> Nonetheless, I still am working on understanding the BX-01 as it
> seems to be mostly ignored and yet very useful. You must admit
that
> you have set aside the BX-01,too. The larger instruction set and
the
> multiplexed data and addressing are certainly used in BasicX in
the
> BX-01.
>
> And, you cannot fully understand features such as Capture or
Analogue
> to Digital without opening the hood and looking at the hardware.



G. Kramer Herzog wrote:

> > This group is about BasicX and not AVR. I suggest you ask your
> question
> > on the AVR-Chat group. The answer to your question doesn't make any
> > difference, does it?
> >
> > Mike
>
> I suppose that I haven't made myself clear.

I have to respectfully disagree with you. I really didn't want to debate
this subject because it doesn't contribute one iota to using and
understand BasicX. There are plenty of other fora to debate the relative
merits of programming languages and computer architectures. The fact
that your arguments are technically inaccurate is also somewhat
frustrating. I think Tony made some excellent points as well.

> BasicX is written solely to operate two distinct Amtel AVR chips.
>
> In is not a portable language that moves from platform to platform
> and it both depends on and conceptually originates from the AVR
> capabilities.

The BASIC language like most 3GLs is VERY portable to other platforms.
This is one reason why BASIC has endured for over 25 years. The system
library functions are not part of the language per se and do not
necessarily port to other platforms as they reflect the capabilities of
the underlying hardware.

> The whole concept of BASIC languages on RISC microcontrollers seems
> particularly related to the Harvard Architecture and the RISC
> offering the learner the kind of environment where it becomes easier
> to learn the hardware and eventually the assembly language.

What has BASIC got to do with computer architectures? The compiler takes
care of any differences. Even more so as the BasicX compiler converts a
program to an intermediate stack based language which is then
interpreted by a virtual machine inside the Atmel RISC chip. I count
that as 3 layers of abstraction above the hardware.

You may want to read the Atmel paper which should answer all your
questions on AVR RISC versus CISC:
http://www.compass-lab.com/pdf/AVR_RISC.pdf

> Also, I assume that some of us eventually might move into Assembly
> language programing if we have enough time and develop a keener
> understanding of what the distinct and unusual properties of a
> product [the AVR] are.

You may chose to do this but as Tony rightly points out most of what you
need to do can be done in C. In fact without the 10 to 100x productivity
brought by 3GLs we wouldn't have the computer applications of today.
Very few companies still use assembly language programming even those
people writing device drivers.

> Please forgive me, if you don't agree. But, I really find the BX-01
> to be a quite unique and puzzling chip. Unlike the BasicAtom, the
> BasicStamp, the PICs, or any other of the 24pin DIP microcontrollers
> with somewhat similar Basic language support.

I'm not sure why you find the BX-01 puzzling. It does reflect some of
the hardware features of the 8515. Obviously NetMedia thought that these
would be useful to some people otherwise why bother creating it in the
first place? I think the BX-01 was the first chip but ultimately the
BX-24/35 was more successful partly because of the range of features of
the underlying chip.

> Nonetheless, I still am working on understanding the BX-01 as it
> seems to be mostly ignored and yet very useful. You must admit that
> you have set aside the BX-01,too.

I didn't set aside the BX-01. I looked at the features of the various
chips against what I wanted to do and decided that the BX-35 most
suitable. Other people have different criteria and so may choose
something else.

> And, you cannot fully understand features such as Capture or Analogue
> to Digital without opening the hood and looking at the hardware.

Really? I have never had to read the Atmel hardware datasheet to
understand how to use a BasicX system library function. The
documentation could be better, of course, but GetADC is almost
self-explanatory.

Mike


--- In basicx@basi..., "arhodes19044" <spamiam@c...> wrote:
> I. too, must disagree, Kramer.
>
> The whole point of a high level language like basic is to insulate
> you from the internals of the hardware.

I do understand and appreciate the whole idea of a 'high level
language'.

It seems though that the microcontroller took what was once Basic and
re-invented it into a subset that was focused on controlling pins
rather than the manipulation of data or a visual image on a screen
via a key board.

Once that occured, the RISC seems to be attached as a part of
the 'new Basic concept'.

I can appreciate that you want to keep the integrity and versatility
of BasicX as a high level language and may even think that it should
be portable to other processors. Why not the 8051, the PIC and or
the SX-Ubicom? I know I have left out a few, but why not all of
them? I suspect it is easier to dream of that to muster the
resources to do.

In any event, I didn't want to drag you fellows into a purely
conceptual conversation. I just really wanted to understand why the
BX-24, BX-35, and BX-01 are special and capable of unique tasks among
the crowd.

At times I am very busy with my English teaching duties and my
writing suffers. Please forgive the tone if it seems to be too
pedantic. My intentions are to try to constructively contribute to
discovering more of what BasicX and its related hardware can do.

Obviously I am not as far along in the programing as many of you. And
it seems that is one of its major appeals - a more sophisticated
programing structure that Parallax's PBasic [which has only one
dimensional arrays and limited math].

I worked on my BX-35 board today and it is coming along nicely. It is
actually smaller than I first mentioned. About 80mm by 64mm at this
stage. The ON/OFF switch seems hugely out of place ;-).



I really didn't want a conceptual debate either. I just wanted to
understand what I thought was BasicX's approach.

I am just more of a hardware person and obviously BasicX attracts
software people more that the other products due to its
sophistication.

In particular, I purchased the BX-24 without concerning myself very
much about the software. What caught my fancy was the claim for more
speed and more instructions.

At times I am rushed and when I re-read the tone of my writing I am
disappointed with it. I will try to slow down, re-read more before
sending, and be more patient.

>
> I have to respectfully disagree with you. I really didn't want to
debate
> this subject because it doesn't contribute one iota to using and
> understand BasicX. There are plenty of other fora to debate the
relative
> merits of programming languages and computer architectures. The
fact
> that your arguments are technically inaccurate is also somewhat
> frustrating. I think Tony made some excellent points as well.
>