Re: Recent dialog and old initiatives
Myron Plichota wrote:
> I can see how the
> presence of an A-register stack could affect programming style as
> fundamentally as the original single A-register does.
Hmm stacks in Forth, what is next? Index registers.!?
I think Forth needs a few more 'conventional' cpu instructions
because any unusual word definitions previously could be handled
with assembly code of the host machine now only has the high level forth
instructions in hardware.
> If I were made of money, I'd produce a 64-bit x21-like MISC with a
> full-lookahead carry adder, one or two additional instructions to augment
> DSP capabilities, six or more serial links, and a glueless SDRAM interface
> as the toppers in the features list. Putting a stake in the ground at 64
> bits may seem excessive and arbitrary, but it banishes integer queasiness in
> DSP algorithms and makes problems like pixel boffing and astrogation math
> within better reach. A 64-bit address is not so far fetched when you also
> consider virtual reality as a potential application. Maybe (probably) we'll
> always want more.
I think the problem is not that we need 64bit address space, but because
the current bunch of cpu's and software is very wasteful of resources.
They have two sizes of index offsets,8 bit signed and 32bit signed.
Yet 90%? of memory access is for local variables. The number of local/gobal
variables is small.One could get by with <8k offsets if one did not
place arrays in the middle of local data. ie : int foo,foobar,fooie[1000];
Pointers to arrays are fine.This goes for both static and local stack data,that
really only need have a small amount of space.A memory map could look like this
for a conventional cpu.
<Static simple variables>
<Fized arrays>
<Small stack>
<code segment>
<heap for local/gobal arrays >
<heap for random memory>
Virtual memory and object oriented programing both are wasteful in resources if
used as a cure-all for programing problems.While useful they need to be used
with care. BTHW with 4kb (2^12) pages the pagetables for 31 bit virtual memory
(2^31) is 2^19 long words or 2 MB per process.With 64 bit memory you need
virtual memory
for the page tables alone.
> A while ago, I raised the notion of "The 2's-complement Cookbook". Since I
> last posted, I have implemented the CORDIC sin/cos algorithm in 32 bits on a
> 16-bit DOS Forth, an F21d+ emulation, and a direct-threaded code Forth on
> TI's TMS320C6x DSP. I have also discovered some other interesting algorithms
> and insights. If anyone is interested, some e-mail requesting copies would
> spur me to organize things into a half-decent zipped attachment for general
> consumption.
That cookbook sounds useful.
> The Steamer16 CPLD design I posted a while back has been revamped to pack
> five 3-bit instructions into each 16-bit cell, and HLL-support macros have
> been implemented for the assembler. It's first application is a machine
> vision system which will hopefully earn its keep in the real world of
> CAD/CAM.
I think packing of a few (3,4?) opcodes per instruction word and more
local (on chip) memory access is the way to go with external memory getting
slower
compared to internal memory.
> BTW, I strongly encourage anyone out there who wants to design their own
> silicon to learn VHDL and use any one of the various low-cost tools
> available. I have used 4 different vendors' tools so far, and they are all
> _pretty good_. You can learn a lot and gain confidence from simulations even
> if you never actually burn or otherwise fab a chip.
For now schematic capture makes more sense to me because you can see what you
get.With the high level hardware languages I am never sure what logic comes out.
Also after about 20 pages of schematic you know your do all, know all, cpu
could use some simplification.:)
> Myron Plichota
Ben.
PS. Since my local ISP has dropped newsgroup service I have missed
the forth and FPGA newsgroups for the last few months.Thus I may not
be upto speed on the latest news.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk
