none David Given wrote:
> As some people might remember, I've been working on a code generator for
> the Z80 for the ACK compiler suite.

Apologies for the crappy posting --- I used to get my usenet feed through
work, which went bust, and I'm still working getting a new feed set up.

--
David Given
dg@cowlark.com

dg@hilfy.(none) (David Given) wrote:


>Would this kind of approach appeal to Z80 programmers? Is it worth
>trading size for speed in this way? Has anyone ever done anything like
>this in the past? Did it work?
>
It has indeed been done before.And it worked, a full system in very limited
computers. The system is called the UCSD p-System, an operating system and
several compilers and more based upon a virtual machine executing p-code. It was
well-known as Apple Pascal on the Apple II. Z80 (CP/M based) versions also exist
and many other platforms.
Have a look at my website and join the Yahoo UCSD at
Pascalhttp://tech.groups.yahoo.com/group/UCSDPascal/ for sources and docs.
Hans, http://www.hansotten.com, http://weblog.hansotten.com

none David Given wrote:
>
> As some people might remember, I've been working on a code
> generator for the Z80 for the ACK compiler suite.
>
> http://tack.sourceforge.net
>
> This is, if I may say so, an utter exercise in frustration, mostly
> because the Z80 gets on terribly badly with stack-frame based
> programming languages. We've done this argument to death, so I
> won't reiterate it here. I've made it produce working code, but
> the result is not what you would call great --- about on a par
> with SDCC; I think Hitech produces better results.

Having experience with this, I advise you to stick with the
fundamentals of the original interpreter, which runs on a stack
machine. The results will run about 3 to 5 times slower than
machine code. You can use varying translators to convert the raw
(text) compiler output Pcode to either binary interpretable, or to
run-time object code. The object code will again be about 3 to 5
times larger than the pcode.

You can find some remains from my system at:



including a functional X86 compiler, z80 interpreter. Much was
lost in a disk crash. Look around.

--



cbfalconer at maineline dot net



--
Posted via a free Usenet account from http://www.teranews.com

HansO wrote:
[...]
> It has indeed been done before.And it worked, a full system in very limited
> computers. The system is called the UCSD p-System, an operating system and
> several compilers and more based upon a virtual machine executing p-code. It was
> well-known as Apple Pascal on the Apple II. Z80 (CP/M based) versions also exist
> and many other platforms.

Yes, I know of p-System, but I was really thinking of something considerably
more lightweight. p-System is designed to be a complete platform running in a
VM. What I want is a simple inner interpreter, which coexists with routines
written in native machine code to do the heavy lifting, which is shipped as
part of the target executables.

The design I'm currently playing with is a dead simple accumulator machine
with eight 16-bit registers (and a separate accumulator), using single-byte
opcodes. Each opcode contains a four bit parameter specifier that allows
several addressing modes; unlike SWEET16, it's important for me to be able to
easily access values relative to the frame pointer.

Currently I'm thinking about opcode maps, and the best way of making dense code...

--
┌── ｄｇï¼*ｃï½�ｗｌï½�ｒｋ．ｃï½�ï½� ─── http://www.cowlark.com ────────────────┠€â”€â”€
│
│ "The god of the Old Testament was actually a TRIBE OF RENEGADE SPACE
│ CANNIBALS." --- Robert McElwaine

>Yes, I know of p-System, but I was really thinking of something considerably
>more lightweight. p-System is designed to be a complete platform running
>in a VM. What I want is a simple inner interpreter, which coexists with routines
>written in native machine code to do the heavy lifting, which is shipped as
>part of the target executables.

>The design I'm currently playing with is a dead simple accumulator machine
>with eight 16-bit registers (and a separate accumulator), using single-byte
>opcodes. Each opcode contains a four bit parameter specifier that allows
>several addressing modes; unlike SWEET16, it's important for me to be able
>to easily access values relative to the frame pointer.

>Currently I'm thinking about opcode maps, and the best way of making dense
>code...

A few years back I developed a virtual machine for my Micro-C compiler called
the "C-flea" - Micro-C was designed from the beginning to be portable to a wide
variety of small CPU architectures (so far, I've done native ports to 68HC08,
6809, 68HC11, 68HC12, 68HC16, 8051/52, 8080/85/Z80, 8086, 8096 and AVR),
but some architectures are just too limited/weird for an efficent port. There
are other reasons as well, secure applications, embedded "scripting" etc.

Anyway, the flea is about as minimal as you can get and be close to "ideal"
in terms of what the compiler likes to have available. There are only four
registers (Accumulator, Index register, Stack pointer and Program counter),
and 8 addressing modes. All opcodes are a single byte, which includes the
addressing mode for instructions where it is applicable (plus additional
immediate, offset or address bytes if they are required by the instruction).

The resulting code is very space efficient, and surprisingly fast given that
it is being emulated in most cases by an 8-bit processor.

Generally it takes about 1K of native machine code to implement the
C-flea interpreter. So far I've done VMs for 6502, 6805, 8051/52,
6800/01/02, PIC, and 8086. I've got an 8080 port partially done, but
never finished it (It's on my "to do" list - honest!)

The exact details of an implementation vary from one to the other,
but in general:

- You CALL the interpreter, which begins interpreting at the opcode
following the call - this allows you to switch to c-flea code at any
point in your code. Most VM's provide a mapping of native CPU
registers to c-flea registers at this transition.

- There is a NATIVE instruction which begins executing native code
at the following location - this allows you to switch to native code
at any point in your code. Most VMs provide a mapping of c-flea
registers to native mode CPU registers at this transition.

- IN and OUT instructions are provided to access "I/O" devices.
I put quotes around that, because often these are devices are
virtual in nature, often representing an interface considerably
"smarter" than a corresponding physical device.

- I also provide a SYS instruction which can be used to implement
other system-dependant functions which you may not wish to map
to an I/O event.

You can check it out at my site if you like - You can install it as a demo,
which makes a limited compiler, simulator and most of the documentation
available. The details of the instruction set are documented (IIRC the
demo docs give you the instruction set but not the actual encoding - which
you don't need to see how it basically works anyway).

Regards,
Dave

--
dave06a@ Low-cost firmware development tools: www.dunfield.com
dunfield. Classic computer collection: www.classiccmp.org/dunfield
com Stuff I have for sale: www.dunfield.com/sale