Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

FORTH IF HONK THEN


devel / comp.lang.forth / Re: Bytecode Forth VM's?

SubjectAuthor
* Bytecode Forth VM's?Paul Rubin
+* Re: Bytecode Forth VM's?Anton Ertl
|`- Re: Bytecode Forth VM's?Paul Rubin
+* Re: Bytecode Forth VM's?minf...@arcor.de
|`* Re: Bytecode Forth VM's?Paul Rubin
| `- Re: Bytecode Forth VM's?minf...@arcor.de
`* Re: Bytecode Forth VM's?Hans Bezemer
 `* Re: Bytecode Forth VM's?Hugh Aguilar
  `- Re: Bytecode Forth VM's?Hans Bezemer

1
Bytecode Forth VM's?

<87sfya7nzn.fsf@nightsong.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=14577&group=comp.lang.forth#14577

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: no.em...@nospam.invalid (Paul Rubin)
Newsgroups: comp.lang.forth
Subject: Bytecode Forth VM's?
Date: Sat, 11 Sep 2021 15:21:00 -0700
Organization: A noiseless patient Spider
Lines: 11
Message-ID: <87sfya7nzn.fsf@nightsong.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="ba54d55f56f7c6ebe10fbd14de294cd6";
logging-data="11293"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18+OOdyEpYRtuOf2qbqvzfQ"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Cancel-Lock: sha1:Gqeh0K/+AjE6dSxGdM1tOzAc28s=
sha1:Dts4Ga+4Z/2Wld71p23MlNpkJ7g=
 by: Paul Rubin - Sat, 11 Sep 2021 22:21 UTC

I may have asked this before, but do people here have favorite designs
for bytecode (aka token threaded) Forth VM's? Using something like MISC
seems too minimal. The idea is that having more bytecodes means shorter
byte-compiled code, but they also bloat the interpreter, so there is a
trade-off. The obvious idea of measuring compilations on a pile of
existing code isn't so great, because user code written for a given
compiler is likely to take the compiler's code generation into account.

Target cpu is AVR8 if it matters. The VM will have to be sparing with
code space on the target. The compiler would be on a remote host and
not face such constraints.

Re: Bytecode Forth VM's?

<2021Sep12.122635@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=14587&group=comp.lang.forth#14587

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: Bytecode Forth VM's?
Date: Sun, 12 Sep 2021 10:26:35 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 24
Message-ID: <2021Sep12.122635@mips.complang.tuwien.ac.at>
References: <87sfya7nzn.fsf@nightsong.com>
Injection-Info: reader02.eternal-september.org; posting-host="c44f096c1a6c40e22bb5d141b7a34564";
logging-data="4078"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19TQqTQk+AQNnlvTZkjt7i5"
Cancel-Lock: sha1:Rv9jyMKM+aWUjv75xVIynw78wdI=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Sun, 12 Sep 2021 10:26 UTC

Paul Rubin <no.email@nospam.invalid> writes:
>The obvious idea of measuring compilations on a pile of
>existing code isn't so great, because user code written for a given
>compiler is likely to take the compiler's code generation into account.

Maybe. However, I don't think it plays a big role. Perceptions about
what is supposed to be efficient play a bigger role than what is
actually efficient. And in any case, the requirements are most
important, and there are also considerations like maintainability or
religious beliefs ("thou shalt not PICK") that probably have a bigger
influence.

In any case, I would go with the measurements. What's the
alternative? If you implement, say, ROT inefficiently (because the
swap dragon hates jugglers) and communicate that, yes, maybe some
programmer would use ROT less, but I doubt that it would make much of
a difference.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Re: Bytecode Forth VM's?

<acc4be27-7731-4d38-92b2-8a16ec1f581cn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=14595&group=comp.lang.forth#14595

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a05:620a:24c2:: with SMTP id m2mr6246627qkn.394.1631462474184;
Sun, 12 Sep 2021 09:01:14 -0700 (PDT)
X-Received: by 2002:a05:620a:294d:: with SMTP id n13mr6076388qkp.179.1631462473981;
Sun, 12 Sep 2021 09:01:13 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Sun, 12 Sep 2021 09:01:13 -0700 (PDT)
In-Reply-To: <87sfya7nzn.fsf@nightsong.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2003:f7:1f0f:8f53:852b:d8a1:af20:573f;
posting-account=AqNUYgoAAADmkK2pN-RKms8sww57W0Iw
NNTP-Posting-Host: 2003:f7:1f0f:8f53:852b:d8a1:af20:573f
References: <87sfya7nzn.fsf@nightsong.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <acc4be27-7731-4d38-92b2-8a16ec1f581cn@googlegroups.com>
Subject: Re: Bytecode Forth VM's?
From: minfo...@arcor.de (minf...@arcor.de)
Injection-Date: Sun, 12 Sep 2021 16:01:14 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 23
 by: minf...@arcor.de - Sun, 12 Sep 2021 16:01 UTC

Paul Rubin schrieb am Sonntag, 12. September 2021 um 00:21:03 UTC+2:
> I may have asked this before, but do people here have favorite designs
> for bytecode (aka token threaded) Forth VM's? Using something like MISC
> seems too minimal. The idea is that having more bytecodes means shorter
> byte-compiled code, but they also bloat the interpreter, so there is a
> trade-off. The obvious idea of measuring compilations on a pile of
> existing code isn't so great, because user code written for a given
> compiler is likely to take the compiler's code generation into account.
>
> Target cpu is AVR8 if it matters. The VM will have to be sparing with
> code space on the target. The compiler would be on a remote host and
> not face such constraints.

I forgot where, but somebody did statistics about occurence probabilities
of Forth words across a number of applications. That gives some indications
for a good selection of VM primitives, but nothing more.

If your applications are floating-point number heavy, or call external libraries,
you have to make your own design.

In my experience more attention must be given in the VM to error handling
and multitasking support, than for the set of bytecode operands.

Re: Bytecode Forth VM's?

<877dfl7als.fsf@nightsong.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=14604&group=comp.lang.forth#14604

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: no.em...@nospam.invalid (Paul Rubin)
Newsgroups: comp.lang.forth
Subject: Re: Bytecode Forth VM's?
Date: Sun, 12 Sep 2021 14:22:23 -0700
Organization: A noiseless patient Spider
Lines: 18
Message-ID: <877dfl7als.fsf@nightsong.com>
References: <87sfya7nzn.fsf@nightsong.com>
<2021Sep12.122635@mips.complang.tuwien.ac.at>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="ba54d55f56f7c6ebe10fbd14de294cd6";
logging-data="13422"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+8vjG5x0yM6KebmDvw3Zv7"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Cancel-Lock: sha1:8SNrkASNvEl5QxotYg/EcyNhK4E=
sha1:SDY9claxgoBeRJhT8F4JRUOwLKs=
 by: Paul Rubin - Sun, 12 Sep 2021 21:22 UTC

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> Maybe. However, I don't think it plays a big role. Perceptions about
> what is supposed to be efficient play a bigger role than what is
> actually efficient.

Here I'm more concerned with code space than speed, partly on the theory
that if there is a bottleneck I can always write another primitive.
Code size at least is a clearly measurable objective.

The thing is, this Forth would be for use in a specific application and
really won't be used for running general purpose Forth programs. A
question like "should 2OVER be a primitive?" is affected by whether
2OVER is used much in the application. And that in turn is influenced
by whether the compiler supports locals.

The situation where the runtime interpreter is on a space-constrained
target but the compiler is on a remote machine and can be fancy, makes
sense for quite a few applications but doesn't get much attention on clf.

Re: Bytecode Forth VM's?

<87y2815vly.fsf@nightsong.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=14606&group=comp.lang.forth#14606

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: no.em...@nospam.invalid (Paul Rubin)
Newsgroups: comp.lang.forth
Subject: Re: Bytecode Forth VM's?
Date: Sun, 12 Sep 2021 14:31:37 -0700
Organization: A noiseless patient Spider
Lines: 9
Message-ID: <87y2815vly.fsf@nightsong.com>
References: <87sfya7nzn.fsf@nightsong.com>
<acc4be27-7731-4d38-92b2-8a16ec1f581cn@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="ba54d55f56f7c6ebe10fbd14de294cd6";
logging-data="13422"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19rqqYVEVHbGCo9bL3VtIZS"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Cancel-Lock: sha1:cDBalsokI3jAyVzGLit7XPsbZZs=
sha1:LpTa2GdE+3NrNjmK5sLAS088Bk8=
 by: Paul Rubin - Sun, 12 Sep 2021 21:31 UTC

"minf...@arcor.de" <minforth@arcor.de> writes:
> In my experience more attention must be given in the VM to error
> handling and multitasking support, than for the set of bytecode
> operands.

Thanks, those are good things to bring up, and I will try to give more
attention to these issues. Is there particular wisdom about error
handling I should look at? If I have a multitasker, it would be a
simple one like eForth's.

Re: Bytecode Forth VM's?

<44a75200-4c1d-44dd-9429-7c1fd5b741adn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=14615&group=comp.lang.forth#14615

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a05:6214:151:: with SMTP id x17mr9128951qvs.38.1631513696164;
Sun, 12 Sep 2021 23:14:56 -0700 (PDT)
X-Received: by 2002:a05:620a:1210:: with SMTP id u16mr8468842qkj.390.1631513695985;
Sun, 12 Sep 2021 23:14:55 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Sun, 12 Sep 2021 23:14:55 -0700 (PDT)
In-Reply-To: <87y2815vly.fsf@nightsong.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2003:f7:1f0f:8f91:16a:bc70:aeb6:b83b;
posting-account=AqNUYgoAAADmkK2pN-RKms8sww57W0Iw
NNTP-Posting-Host: 2003:f7:1f0f:8f91:16a:bc70:aeb6:b83b
References: <87sfya7nzn.fsf@nightsong.com> <acc4be27-7731-4d38-92b2-8a16ec1f581cn@googlegroups.com>
<87y2815vly.fsf@nightsong.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <44a75200-4c1d-44dd-9429-7c1fd5b741adn@googlegroups.com>
Subject: Re: Bytecode Forth VM's?
From: minfo...@arcor.de (minf...@arcor.de)
Injection-Date: Mon, 13 Sep 2021 06:14:56 +0000
Content-Type: text/plain; charset="UTF-8"
 by: minf...@arcor.de - Mon, 13 Sep 2021 06:14 UTC

Paul Rubin schrieb am Sonntag, 12. September 2021 um 23:31:39 UTC+2:
> "minf...@arcor.de" <minf...@arcor.de> writes:
> > In my experience more attention must be given in the VM to error
> > handling and multitasking support, than for the set of bytecode
> > operands.
> Thanks, those are good things to bring up, and I will try to give more
> attention to these issues. Is there particular wisdom about error
> handling I should look at? If I have a multitasker, it would be a
> simple one like eForth's.

That really depends on the target environment. For instance, the standard
exception wordlist doesn't know of exception classes, eg warning-alarm-failure,
and pertaining different exception handling routines. In a real world
application you will rather soon stumble over such things.

"Argument out of allowed range" could be an application exception, to be handled
by retrying an input routine.
"Missing opcode" is an internal VM exception, resulting in a core dump.
"User interrupt" could lead to a warm start.
"Timer overflow" in a multitasker could 'ring a bell'.
And so on...

To start with:
1) implement a catch/throw mechanism already in the VM
2) list all your possible exceptions and categorize them into severity classes
3) prepare the VM to handle different exception handlers

We know that the old Forth wisdom comes with "crash early".
But this is only a poor excuse for poor engineering.

Re: Bytecode Forth VM's?

<c64e15d7-ec42-4c7e-a129-25ddf114ce55n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=14718&group=comp.lang.forth#14718

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:ac8:5492:: with SMTP id h18mr177180qtq.152.1632328856299;
Wed, 22 Sep 2021 09:40:56 -0700 (PDT)
X-Received: by 2002:ac8:4243:: with SMTP id r3mr124730qtm.187.1632328856151;
Wed, 22 Sep 2021 09:40:56 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Wed, 22 Sep 2021 09:40:55 -0700 (PDT)
In-Reply-To: <87sfya7nzn.fsf@nightsong.com>
Injection-Info: google-groups.googlegroups.com; posting-host=82.95.228.79; posting-account=Ebqe4AoAAABfjCRL4ZqOHWv4jv5ZU4Cs
NNTP-Posting-Host: 82.95.228.79
References: <87sfya7nzn.fsf@nightsong.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <c64e15d7-ec42-4c7e-a129-25ddf114ce55n@googlegroups.com>
Subject: Re: Bytecode Forth VM's?
From: the.beez...@gmail.com (Hans Bezemer)
Injection-Date: Wed, 22 Sep 2021 16:40:56 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 27
 by: Hans Bezemer - Wed, 22 Sep 2021 16:40 UTC

On Sunday, September 12, 2021 at 12:21:03 AM UTC+2, Paul Rubin wrote:
> I may have asked this before, but do people here have favorite designs
> for bytecode (aka token threaded) Forth VM's? Using something like MISC
> seems too minimal. The idea is that having more bytecodes means shorter
> byte-compiled code, but they also bloat the interpreter, so there is a
> trade-off. The obvious idea of measuring compilations on a pile of
> existing code isn't so great, because user code written for a given
> compiler is likely to take the compiler's code generation into account.
>
> Target cpu is AVR8 if it matters. The VM will have to be sparing with
> code space on the target. The compiler would be on a remote host and
> not face such constraints.

4tH's got about a hundred opcodes using a Harvard architecture. 2DUP will give you very little speedup over OVER OVER if you design the thing properly - and even less space. Note that even 2OVER has minimal space overhead, since you have to define it only once - then it's reduced to a single CALL.

switch() or GCC goto interpreters are quite fast (don't believe me - ask FICL). Tables with function pointers are slow - don't underestimate function call overhead in C. Some C compilers convert switches to jumptables, you see. If you want to avoid slow access in switches() anyways, get some stats about the frequency of keywords in Forth and organize 'em that way.

Hans

Re: Bytecode Forth VM's?

<054a76c8-8bc1-4476-8390-bfcb71fb6066n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=14721&group=comp.lang.forth#14721

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:ac8:5a4f:: with SMTP id o15mr2919192qta.131.1632371772810;
Wed, 22 Sep 2021 21:36:12 -0700 (PDT)
X-Received: by 2002:a37:2dc7:: with SMTP id t190mr3007399qkh.60.1632371772692;
Wed, 22 Sep 2021 21:36:12 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Wed, 22 Sep 2021 21:36:12 -0700 (PDT)
In-Reply-To: <c64e15d7-ec42-4c7e-a129-25ddf114ce55n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:579:8018:1b00:4870:941:368a:9f5f;
posting-account=OxDKOgoAAADW0cxAqHqpN1zqeCoSsDap
NNTP-Posting-Host: 2001:579:8018:1b00:4870:941:368a:9f5f
References: <87sfya7nzn.fsf@nightsong.com> <c64e15d7-ec42-4c7e-a129-25ddf114ce55n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <054a76c8-8bc1-4476-8390-bfcb71fb6066n@googlegroups.com>
Subject: Re: Bytecode Forth VM's?
From: hughagui...@gmail.com (Hugh Aguilar)
Injection-Date: Thu, 23 Sep 2021 04:36:12 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 14
 by: Hugh Aguilar - Thu, 23 Sep 2021 04:36 UTC

On Wednesday, September 22, 2021 at 9:40:57 AM UTC-7, the.bee...@gmail.com wrote:
> 4tH's got about a hundred opcodes using a Harvard architecture.

You don't know what Harvard Architecture is!

This is a kind of processor in which the code-memory and data-memory each have
their own address and data bus --- it is possible to access both code-memory and
data-memory concurrently.

The MiniForth is the only processor that I am familiar with that had a Harvard Architecture.
Every opcode executed in one clock cycle. It was reading the next opcode concurrently with
executing the current opcode (this was true even if the current opcode was accessing
data-memory). Note that there was no way to change the PC (program counter)
except with the NXT instruction --- this means that the next opcode in code memory is always
the next opcode to be executed --- there are no jumps or branches.

Re: Bytecode Forth VM's?

<70737b29-a579-4fba-9943-1cde4a939f05n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=14722&group=comp.lang.forth#14722

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a0c:c189:: with SMTP id n9mr3532654qvh.5.1632397695009;
Thu, 23 Sep 2021 04:48:15 -0700 (PDT)
X-Received: by 2002:ad4:456e:: with SMTP id o14mr3665316qvu.15.1632397694867;
Thu, 23 Sep 2021 04:48:14 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Thu, 23 Sep 2021 04:48:14 -0700 (PDT)
In-Reply-To: <054a76c8-8bc1-4476-8390-bfcb71fb6066n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=82.95.228.79; posting-account=Ebqe4AoAAABfjCRL4ZqOHWv4jv5ZU4Cs
NNTP-Posting-Host: 82.95.228.79
References: <87sfya7nzn.fsf@nightsong.com> <c64e15d7-ec42-4c7e-a129-25ddf114ce55n@googlegroups.com>
<054a76c8-8bc1-4476-8390-bfcb71fb6066n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <70737b29-a579-4fba-9943-1cde4a939f05n@googlegroups.com>
Subject: Re: Bytecode Forth VM's?
From: the.beez...@gmail.com (Hans Bezemer)
Injection-Date: Thu, 23 Sep 2021 11:48:15 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 43
 by: Hans Bezemer - Thu, 23 Sep 2021 11:48 UTC

On Thursday, September 23, 2021 at 6:36:13 AM UTC+2, Hugh Aguilar wrote:
> On Wednesday, September 22, 2021 at 9:40:57 AM UTC-7, the.bee...@gmail.com wrote:
> > 4tH's got about a hundred opcodes using a Harvard architecture.
> You don't know what Harvard Architecture is!
>
> This is a kind of processor in which the code-memory and data-memory each have
> their own address and data bus --- it is possible to access both code-memory and
> data-memory concurrently.

You can make up all the definitions you want, Hugh, but I'm going for this one: "The Harvard architecture is a computer architecture with separate storage and signal pathways for instructions and data. It contrasts with the von Neumann architecture, where program instructions and data share the same memory and pathways. In a Harvard architecture, there is no need to make the two memories share characteristics. In particular, the word width, timing, implementation technology, and memory address structure can differ".

Which is exactly what the segments in 4tH do. The Code Segment is R/O and contains opcodes and operands. The String Segment is R/O - and there are even NO opcode to access it directly. The Integer Segment contains cells, the Character Segment contains chars. All opcodes are bound to operate on their distinct segments. All addresses are for a specific segment.

> The MiniForth is the only processor that I am familiar with that had a Harvard Architecture.
> Every opcode executed in one clock cycle. It was reading the next opcode concurrently with
> executing the current opcode (this was true even if the current opcode was accessing
> data-memory). Note that there was no way to change the PC (program counter)
> except with the NXT instruction --- this means that the next opcode in code memory is always
> the next opcode to be executed --- there are no jumps or branches.

These are not specific for a Harvard architecture.

Hans Bezemer

1
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor