Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 138975

Article: 138975
Subject: Re: Zero operand CPUs
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Tue, 17 Mar 2009 16:12:18 +0000
Links: << >>  << T >>  << A >>
On Tue, 17 Mar 2009 08:27:48 -0700 (PDT), 
Antti Lukats wrote:

>well assembler is GOOD if it exist :)
>so any soft-core with assembler is ok
>but there is no assembler for nibz? so == useless.
>no C, no assembler, == not possible to use :(

I think you're being a bit blinkered about this.
Writing an assembler for a machine as simple as
nibz is not much more than a day's work if you 
are sensible about your choice of tool (Tcl, Perl?)
and limit your ambitions reasonably.  No rocket
science required.

>a non working somesort of forht partially adopted
>but not really tested does not count as development tool.
>a simple assembler would.

Yes. gcc is not the only act in town for these 
very simple, small machines.  A simple assembler
gets you going, and a nice macro-generating 
assembler gets you productive, for very little
investment in the tool chain.  Of course a full
C toolchain is way better; but targeting gcc to a
new machine is not for the faint-hearted, I think
(it's not for me at all, I would have no idea
how to start).

I'd consider throwing together an assembler for
nibz myself, but like many others here I simply
can't divine its specification from the published
docs - and that's my real problem with it.  If 
jacko wants it to become more widely accepted he
must put in the effort to document it intelligibly
(or find someone else who can do so).  He's 
competing in a very crowded marketplace, and 
has erected very effective barriers to other 
people's understanding of his offering;
not a smart move.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 138976
Subject: Re: Zero operand CPUs
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Tue, 17 Mar 2009 10:33:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 17, 6:12=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Tue, 17 Mar 2009 08:27:48 -0700 (PDT),
>
> Antti Lukats wrote:
> >well assembler is GOOD if it exist :)
> >so any soft-core with assembler is ok
> >but there is no assembler for nibz? so =3D=3D useless.
> >no C, no assembler, =3D=3D not possible to use :(
>
> I think you're being a bit blinkered about this.
> Writing an assembler for a machine as simple as
> nibz is not much more than a day's work if you
> are sensible about your choice of tool (Tcl, Perl?)
> and limit your ambitions reasonably. =A0No rocket
> science required.
>
> >a non working somesort of forht partially adopted
> >but not really tested does not count as development tool.
> >a simple assembler would.
>
> Yes. gcc is not the only act in town for these
> very simple, small machines. =A0A simple assembler
> gets you going, and a nice macro-generating
> assembler gets you productive, for very little
> investment in the tool chain. =A0Of course a full
> C toolchain is way better; but targeting gcc to a
> new machine is not for the faint-hearted, I think
> (it's not for me at all, I would have no idea
> how to start).
>
> I'd consider throwing together an assembler for
> nibz myself, but like many others here I simply
> can't divine its specification from the published
> docs - and that's my real problem with it. =A0If
> jacko wants it to become more widely accepted he
> must put in the effort to document it intelligibly
> (or find someone else who can do so). =A0He's
> competing in a very crowded marketplace, and
> has erected very effective barriers to other
> people's understanding of his offering;
> not a smart move.
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
> jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.

right Jonathan

a simple assembler would suffice
a good macro assembler is better
or then can use c preprocessor on the asm source
or use some retargetable assembler..

but if the core specs itselfs are really fuzzy then its
hard to use it, or make an assembler for it

Antti











From bernd.paysan@gmx.de Tue Mar 17 10:35:52 2009
Path: flpi141.ffdc.sbc.com!flph199.ffdc.sbc.com!prodigy.com!flph200.ffdc.sbc.com!prodigy.net!newshub.sdsu.edu!feeder.erje.net!bnewspeer00.bru.ops.eu.uu.net!bnewspeer01.bru.ops.eu.uu.net!emea.uu.net!read.news.uk.uu.net!not-for-mail
Message-Id: <ok3596-n4f.ln1@annette.zetex.de>
From: Bernd Paysan <bernd.paysan@gmx.de>
Subject: Re: Zero operand CPUs
Newsgroups: comp.lang.forth,comp.arch.embedded,comp.arch.fpga
Followup-To: comp.lang.forth
Date: Tue, 17 Mar 2009 18:35:52 +0100
References: <95f3256f-1304-48ba-a982-15562c1cc585@h20g2000yqn.googlegroups.com> <ebd30a00-1790-4e0e-8de5-a4f6c8e6c66f@e38g2000yqa.googlegroups.com> <49bfc0c7$0$14779$8404b019@news.wineasy.se>
User-Agent: KNode/0.10.9
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
Lines: 13
NNTP-Posting-Host: 62.190.115.228
X-Trace: 1237311602 read.news.uk.uu.net 19014 62.190.115.228:10618
X-Complaints-To: abuse@uk.uu.net
Xref: prodigy.net comp.lang.forth:140908 comp.arch.embedded:302772 comp.arch.fpga:152305
X-Received-Date: Tue, 17 Mar 2009 13:40:18 EDT (flpi141.ffdc.sbc.com)

David Brown wrote:
> So a compiler without a debugger is somewhat limited but still useful,
> but a debugger without a compiler is rather less useful!

I've done a debugger on my last b16 version, and it doesn't come with a
compiler, either (only an assembler), and I assure you, the debugger *is*
useful. At least that's what the coworker who does the firmware development
tells me.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

Article: 138977
Subject: Re: Zero operand CPUs
From: Jeff Fox <fox@ultratechnology.com>
Date: Tue, 17 Mar 2009 11:44:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 17, 9:12 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Tue, 17 Mar 2009 08:27:48 -0700 (PDT),
>
> Antti Lukats wrote:
> >well assembler is GOOD if it exist :)
> >so any soft-core with assembler is ok
> >but there is no assembler for nibz? so == useless.
> >no C, no assembler, == not possible to use :(
>
> I think you're being a bit blinkered about this.
> Writing an assembler for a machine as simple as
> nibz is not much more than a day's work if you
> are sensible about your choice of tool (Tcl, Perl?)
> and limit your ambitions reasonably.  No rocket
> science required.

That's about right.

> >a non working somesort of forht partially adopted
> >but not really tested does not count as development tool.
> >a simple assembler would.
>
> Yes. gcc is not the only act in town for these
> very simple, small machines.

Forth covers a wide range of hardware and software these
days.  The op mentioned Moore's ideas on the subject.
Mr. Moore's current ideas are about full custom vlsi
Forth chips designed with Forth CAD software.  They
have 700Mhz core that use 1/30 the power of an MSP430
for a given computation and are small enough to fit a
hundred or more on a tiny chip and program them with
the simplest Forth compilers yet using libraries of code
objects written by various teams of people.  Other people
have fit multiple tiny 200 mip code compatible core on
small FPGA.  These are some of the things the op refered
to as Chuck Moore's ideas on this subject.

The op also talked about a project to implement a simple
processor with modest performance requirements and
write code himself.  He is not alone in being interested
in that sort of thing, but rolling your own hardware/software
or using gcc are certainly not the only options here.

> A simple assembler
> gets you going, and a nice macro-generating
> assembler gets you productive, for very little
> investment in the tool chain.  Of course a full
> C toolchain is way better; but targeting gcc to a
> new machine is not for the faint-hearted, I think
> (it's not for me at all, I would have no idea
> how to start).

The first page of gcc documentation will explain
why you would need to choose a different path
if you want to try to implement a C for these designs.

> I'd consider throwing together an assembler for
> nibz myself, but like many others here I simply
> can't divine its specification from the published
> docs - and that's my real problem with it.  If
> jacko wants it to become more widely accepted he
> must put in the effort to document it intelligibly
> (or find someone else who can do so).  He's
> competing in a very crowded marketplace, and
> has erected very effective barriers to other
> people's understanding of his offering;
> not a smart move.

People are making knock-offs of 20+ year old
Forth chips in modern FPGA and are now getting 50
mips or more.   People are making newer smaller
Forth chips with tens or hundreds of thousands
of Forth mips and at very lower power and cost.
Some people are making their own designs
tuned for the performance that they need which
might be just be a small control processor with
source code that doesn't need to be very fast
or might be specialized for some purpose.

Choosing a model that offers a few mips and
writing your own assembler for it are not your
only options.  However it is how the inventor
of Forth got started in hardware design in
the early 80s after thirty years experience
writing code.  The first step was 4-10 mips,
then 100, 220, 700, 18,000, 30,000, 100k+
and beyond.

It started with one person's work and expanded
to include a hundred other people doing cad work
in Forth or writing tools and library code for target
chips etc. so you don't have to redo it all yourself.

Best Wishes

Article: 138978
Subject: Re: Zero operand CPUs
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Tue, 17 Mar 2009 14:04:19 -0500
Links: << >>  << T >>  << A >>

>>well assembler is GOOD if it exist :)
>>so any soft-core with assembler is ok
>>but there is no assembler for nibz? so == useless.
>>no C, no assembler, == not possible to use :(
>
>I think you're being a bit blinkered about this.
>Writing an assembler for a machine as simple as
>nibz is not much more than a day's work if you 
>are sensible about your choice of tool (Tcl, Perl?)
>and limit your ambitions reasonably.  No rocket
>science required.

You can also use cpp in front of your assembler.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 138979
Subject: Re: Zero operand CPUs
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Tue, 17 Mar 2009 12:13:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 17, 9:04=A0pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
Murray) wrote:
> >>well assembler is GOOD if it exist :)
> >>so any soft-core with assembler is ok
> >>but there is no assembler for nibz? so =3D=3D useless.
> >>no C, no assembler, =3D=3D not possible to use :(
>
> >I think you're being a bit blinkered about this.
> >Writing an assembler for a machine as simple as
> >nibz is not much more than a day's work if you
> >are sensible about your choice of tool (Tcl, Perl?)
> >and limit your ambitions reasonably. =A0No rocket
> >science required.
>
> You can also use cpp in front of your assembler.
>
> --
> These are my opinions, not necessarily my employer's. =A0I hate spam.

sure can use GCC as i already mentioned 4 posts ago :)
but it not always as good as good macro assembler

Antti


Article: 138980
Subject: Re: Zero operand CPUs
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Tue, 17 Mar 2009 14:49:49 -0500
Links: << >>  << T >>  << A >>

>BTW, ZPU may have a GCC compiler, but without a debugger, is that
>really useful?  There aren't many projects done in C that are debugged
>without an emulator.

I'm happy without a debugger, at least as long as the edit/compile/run
cycle is fast.  Besides, a lot of the quirks I'm chasing are
timing issues where you need a scope to see what's going on.

What do you use for a debugger when working on perl/python code?

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 138981
Subject: Re: Zero operand CPUs
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Tue, 17 Mar 2009 15:01:13 -0500
Links: << >>  << T >>  << A >>
>Getting the compiler to limit the stack size is
>clearly possible (Transputer, anyone? it had a
>3-register stack).  But this is certain to
>cause more memory references to escape to
>memory.  It's a compromise, like everything else.

3 is a small number.

If you have 8 or 16, the same ballpark as the number
of registers in a typical CPU, then most code never
spills to memory.

It was a long time ago, so my memory is fuzzy.  I think
the Mesa/Cedar system had a rule of nothing on the stack
at procedure calls except the arguments/results.  I think
the only time that sane code spilled was calls to get
the arguments of a call, things like:
  x = foo(a, baz(b));

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 138982
Subject: Re: Zero operand CPUs
From: Goran_Bilski <goran.bilski@xilinx.com>
Date: Tue, 17 Mar 2009 13:17:40 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

Not sure I want to jump into this (but I couldn't resists ;-) ) but I
created a stack RISC processor back in 1990 which was targetting space
application.
It had the ADA run-time kernel in hardware and support 8 tasks in
hardware.
We handled the memory accesses using cache, there is no real
difference in cache for stack machine or register-file based CPU.
We did however had one operand to minimize the program code size.
Instead of just operating on the two operand on the stack, one operand
was address with a stack offset.
This removed tons of push instructions and thus minimized the program
code space.

A processor needs assembler, simple as that. Debugger is nice to have
but you can develop stuff without it, it just takes longer time.
C compiler is needed if you want more users.

With Xilinx 6-LUT, you can really make small 16-bit RISC machines
which is register file based.
Programming a register based CPU in assembler is much easier than a
stack machine.
I crafted a couple of years ago a 16-bit machine which could be as
small as 200 LUTs (4-LUT) but was around 300 LUTs in general.
It might be possible to do a 16-bit RISC at around 100 LUTs (6-LUT).
So the only benefit I see a stack machine has is more compact code.

G=F6ran Bilski

Article: 138983
Subject: Re: Zero operand CPUs
From: Elizabeth D Rather <erather@forth.com>
Date: Tue, 17 Mar 2009 10:33:50 -1000
Links: << >>  << T >>  << A >>
Jonathan Bromley wrote:
> On Tue, 17 Mar 2009 08:27:48 -0700 (PDT), 
> Antti Lukats wrote:
> 
>> well assembler is GOOD if it exist :)
>> so any soft-core with assembler is ok
>> but there is no assembler for nibz? so == useless.
>> no C, no assembler, == not possible to use :(
> 
> I think you're being a bit blinkered about this.
> Writing an assembler for a machine as simple as
> nibz is not much more than a day's work if you 
> are sensible about your choice of tool (Tcl, Perl?)
> and limit your ambitions reasonably.  No rocket
> science required.

Write it in Forth.  Also about a day's work.  Use a PC Forth to generate 
code for it, and when you get it working set up a little "talker" for 
interactive debugging.  You don't need a full Forth in the target for that.

We have several times managed low-level controllers (not quite "smart" 
enough to support a full Forth VM) that way.

...
> I'd consider throwing together an assembler for
> nibz myself, but like many others here I simply
> can't divine its specification from the published
> docs - and that's my real problem with it.  If 
> jacko wants it to become more widely accepted he
> must put in the effort to document it intelligibly
> (or find someone else who can do so).  He's 
> competing in a very crowded marketplace, and 
> has erected very effective barriers to other 
> people's understanding of his offering;
> not a smart move.

Ah, well, that's a problem.  If you can't get a detailed description of 
the instruction set, you're stuck.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

Article: 138984
Subject: Re: Zero operand CPUs
From: Jacko <jackokring@gmail.com>
Date: Tue, 17 Mar 2009 16:06:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 17 Mar, 17:33, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Mar 17, 6:12=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
> wrote:
>
>
>
>
>
> > On Tue, 17 Mar 2009 08:27:48 -0700 (PDT),
>
> > Antti Lukats wrote:
> > >well assembler is GOOD if it exist :)
> > >so any soft-core with assembler is ok
> > >but there is no assembler for nibz? so =3D=3D useless.
> > >no C, no assembler, =3D=3D not possible to use :(
>
> > I think you're being a bit blinkered about this.
> > Writing an assembler for a machine as simple as
> > nibz is not much more than a day's work if you
> > are sensible about your choice of tool (Tcl, Perl?)
> > and limit your ambitions reasonably. =A0No rocket
> > science required.
>
> > >a non working somesort of forht partially adopted
> > >but not really tested does not count as development tool.
> > >a simple assembler would.
>
> > Yes. gcc is not the only act in town for these
> > very simple, small machines. =A0A simple assembler
> > gets you going, and a nice macro-generating
> > assembler gets you productive, for very little
> > investment in the tool chain. =A0Of course a full
> > C toolchain is way better; but targeting gcc to a
> > new machine is not for the faint-hearted, I think
> > (it's not for me at all, I would have no idea
> > how to start).
>
> > I'd consider throwing together an assembler for
> > nibz myself, but like many others here I simply
> > can't divine its specification from the published
> > docs - and that's my real problem with it. =A0If
> > jacko wants it to become more widely accepted he
> > must put in the effort to document it intelligibly
> > (or find someone else who can do so). =A0He's
> > competing in a very crowded marketplace, and
> > has erected very effective barriers to other
> > people's understanding of his offering;
> > not a smart move.
> > --
> > Jonathan Bromley, Consultant
>
> > DOULOS - Developing Design Know-how
> > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
> > jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> > The contents of this message may contain personal views which
> > are not the views of Doulos Ltd., unless specifically stated.
>
> right Jonathan
>
> a simple assembler would suffice
> a good macro assembler is better
> or then can use c preprocessor on the asm source
> or use some retargetable assembler..
>
> but if the core specs itselfs are really fuzzy then its
> hard to use it, or make an assembler for it

There is now a link on the instruction set page presenting an english
text description of the BO instruction. All other instructions follow
a similar symbology.

SU always has carry, BO always rotates through carry. DI leaves the
carry alone, just like all the register/memory move instructions. All
opcodes above 15 are subroutine call addresses. There are no general
purpose register fields in the 4 bits of hardwired 16 opcodes (0-15),
although there is some pattern to it.

Yes the indexing has been fixed, i.e. non-clocked assignment to
indirect, which is also good for speed, as well as executing the
current instruction rather than the current operation with the last
instruction's indirection register. (this removes a row of clocked
flip-flops).

Personally I find what else I have to explain as a difficult task. I
would accept any correct documentation which falls under the BSD
licence, or has no publication restriction.

The simplicity of the assembler was the main reason for the
instruction choice, and lack of multiple addressing modes. In some
senses the assembler complexity indicates how much decode processing
is required for an instruction. There is a GPL assembler written in
forth, using the gforth sytem this is suitable for macro programming.
It's a tiny amount of code.

The lack of certain complicated instructions takes some working
around, but it is not beyond a talented code writer. The macro feature
is not really relevant, as a subroutine will work, but I suppose some
critical inline macros would be useful to some to prevent excessive
return stack juggling.

All instructions are fixed and final, except RE and SE, which are
useful only in multi-tasking, and even then there is some debate.

cheers jacko

Article: 138985
Subject: uB and external CPU communications
From: reganireland@gmail.com
Date: Tue, 17 Mar 2009 16:14:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hey guys,

I am working on an image processing FPGA design and plan to use an
embedded uB to control certain FPGA functions and perform some
preliminary analysis on processed image data written into a FIFO
peripheral. With any luck, the uB will be powerful enough to do
everything (analysis/calculation), but I have no experience with uB
and cannot really count on that.

With further development of the recognition etc. I was considering
using a PowerPC CPU. If I did this, what would you recommend as the
best way to communicate between the uB and the PowerPC? I am just
learning embedded systems and any resources would be great.

Thanks,
Gints

Article: 138986
Subject: Re: Zero operand CPUs
From: Jacko <jackokring@gmail.com>
Date: Tue, 17 Mar 2009 16:57:04 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 17 Mar, 20:17, Goran_Bilski <goran.bil...@xilinx.com> wrote:
> Hi,
>
> Not sure I want to jump into this (but I couldn't resists ;-) ) but I
> created a stack RISC processor back in 1990 which was targetting space
> application.
> It had the ADA run-time kernel in hardware and support 8 tasks in
> hardware.
> We handled the memory accesses using cache, there is no real
> difference in cache for stack machine or register-file based CPU.
> We did however had one operand to minimize the program code size.
> Instead of just operating on the two operand on the stack, one operand
> was address with a stack offset.
> This removed tons of push instructions and thus minimized the program
> code space.

Sounds ok. I did think of using such a pick optimization, but
considered it responsable for a potential cache slowdown as the design
progresses. In nibz picking lower in the stack like this may be
possible, but is not advised for scalability reasons. I have the idea
too that any object C (++) should have method local instance variables
only, indicating which method has write access to the variable. A
tough restriction, but I think essential for scalable future coding.

> A processor needs assembler, simple as that. Debugger is nice to have
> but you can develop stuff without it, it just takes longer time.
> C compiler is needed if you want more users.

True.

> With Xilinx 6-LUT, you can really make small 16-bit RISC machines
> which is register file based.
> Programming a register based CPU in assembler is much easier than a
> stack machine.
> I crafted a couple of years ago a 16-bit machine which could be as
> small as 200 LUTs (4-LUT) but was around 300 LUTs in general.
> It might be possible to do a 16-bit RISC at around 100 LUTs (6-LUT).
> So the only benefit I see a stack machine has is more compact code.

Yes , a good code density is possible. The use of code compression
techniques by using an indirect jump vector table is a possible
improvement in code density.

Thus the following memory types could be defined.
1. Microcode. 4 bit instructions wide memory.
2. Jumpcode. n bit < 16 bit (n->16 map addresses).
3. Fullwidth. 16 bit.

cheers jacko

Article: 138987
Subject: Re: How to load an image onto system ace compact flash embedded on
From: newman5382@yahoo.com
Date: Tue, 17 Mar 2009 17:10:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 17, 7:51=A0am, mopra <mohitpra...@gmail.com> wrote:
> Hey thanks for your help but can you explain it a little more
> elaborately.
>
> where should i use " copy myimage.jpg f:\ =A0"? =A0How to embed that in
> the C code?
>
> Please help me in this regard.
>
> Regards,
> Mohit

If you have a Compact Disk reader/writer that attaches to a PC, one
could use the DOS copy command like Antti mentioned to write your file
to the compact disk.
I have an IntelliFlash USB 6 to 1 memory reader/writer that lets me
access the compact disk from my Windows Computer.
.

Article: 138988
Subject: Re: Zero operand CPUs
From: Bit Farmer <noone@wrenchman.com>
Date: Tue, 17 Mar 2009 19:33:05 -0500
Links: << >>  << T >>  << A >>
Antti.Lukats@googlemail.com wrote:
> On Mar 17, 5:09 pm, rickman <gnu...@gmail.com> wrote:
>> On Mar 17, 9:58 am, "Antti.Luk...@googlemail.com"
>>
>>
>>
>>
>>
>> <Antti.Luk...@googlemail.com> wrote:
>>> On Mar 17, 3:24 pm, Jacko <jackokr...@gmail.com> wrote:
>>>> Hi
>>>> Three cheers for Chuck Moore, and his hidden friend Keep Less ;-)
>>>> Another zero operand CPUhttp://nibz.googlecode.com
>>>> cheers jacko
>>>> Now available in free licence of one core per ASIC/FPGA/CPLD, with two
>>>> conditions.
>>>> 1. A K Ring Technologies Logo must be printed atop the chip or close
>>>> by on the PCB at any resolution.
>>>> 2. Any documentation produced must acknowledge copyright and provide
>>>> the URL.
>>>> This licence is for those folks who do not like the BSD derived work
>>>> restrictions.
>>> the difference between zpu and nibz is that ZPU is supported
>>> by GCC toolchain, while there are no tools to generate any
>>> meaningful code for nibz
>>> correct me if i am wrong
>>> Antti
>> Is that really the primary critera?  I think you are right.  But I
>> have a similar CPU design that I expect to use on a project shortly
>> and it will be programmed in assembly, but it will look a lot like
>> Forth.  I consider that to be close enough to a high level language.
>>
>> BTW, ZPU may have a GCC compiler, but without a debugger, is that
>> really useful?  There aren't many projects done in C that are debugged
>> without an emulator.
>>
>> Rick- Hide quoted text -
>>
>> - Show quoted text -
> 
> well assembler is GOOD if it exist :)
> 
> so any soft-core with assembler is ok
> but there is no assembler for nibz? so == useless.
> no C, no assembler, == not possible to use :(
> 
> a non working somesort of forht partially adopted
> but not really tested does not count as development tool.
> 
> a simple assembler would.
> 
> I personally dont like C, but unfortunatly can not fully avoid it
> either
> 
> Antti

Look at using a table driven user definable universal assembler

b. Farmer.  (I am back).

Article: 138989
Subject: Re: Zero operand CPUs
From: -jg <Jim.Granville@gmail.com>
Date: Tue, 17 Mar 2009 19:43:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 18, 8:17=A0am, Goran_Bilski <goran.bil...@xilinx.com> wrote:
> It might be possible to do a 16-bit RISC at around 100 LUTs (6-LUT).
> So the only benefit I see a stack machine has is more compact code.

So, are we going to see a Nano-Blaze for the 6-LUT Xilinx parts ? ;)

-jg


Article: 138990
Subject: Re: Zero operand CPUs
From: rickman <gnuarm@gmail.com>
Date: Tue, 17 Mar 2009 23:45:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 17, 7:06=A0pm, Jacko <jackokr...@gmail.com> wrote:
>
> There is now a link on the instruction set page presenting an english
> text description of the BO instruction. All other instructions follow
> a similar symbology.

Dude, you are really terrible at this.  In one place you tell people
about a CPU you designed with no specifics.  Another place you post a
link to a web page with very fuzzy descriptions of the instruction set
that is not usable.  Then here you post that you have added some more
explanation, but no link.  Are we supposed to search around to find
the link to your web page again?  I have no idea where to find it.

I may not be very tactful, but I really am trying to help you, not be
insulting.  I hope it doesn't come off that way.


Rick

Article: 138991
Subject: PLL inclk error
From: randy <xingchen.guo@gmail.com>
Date: Wed, 18 Mar 2009 01:34:53 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi all:
   I use the Transceiver's RX_clk as PLL ref_inclk, but it reports
error as below:
Error: Clock input port inclk[0] of PLL "rec_clk62_pll:rec_clk62_pll|
altpll:altpll_component|rec_clk62_pll_altpll:auto_generated|pll1" must
be driven by a non-inverted input pin or another PLL, optionally
through a Clock Control bloc.

The transceiver is work in 10G date rate mode, and the clk frequency
is 257.8125M

How to resolve this problem, can you give any suggestions?

Thank you very much for your help.

Article: 138992
Subject: Re: uB and external CPU communications
From: wolahr <will@volamp.com>
Date: Wed, 18 Mar 2009 02:48:11 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 17, 11:14=A0pm, reganirel...@gmail.com wrote:
> Hey guys,
>
> I am working on an image processing FPGA design and plan to use an
> embedded uB to control certain FPGA functions and perform some
> preliminary analysis on processed image data written into a FIFO
> peripheral. With any luck, the uB will be powerful enough to do
> everything (analysis/calculation), but I have no experience with uB
> and cannot really count on that.
>
> With further development of the recognition etc. I was considering
> using a PowerPC CPU. If I did this, what would you recommend as the
> best way to communicate between the uB and the PowerPC? I am just
> learning embedded systems and any resources would be great.
>
> Thanks,
> Gints

excuse my ignorance here, but what is a uB?

Article: 138993
Subject: Re: Zero operand CPUs
From: Paul Urbanus <urbpublic@hotmail.com>
Date: Wed, 18 Mar 2009 05:19:50 -0500
Links: << >>  << T >>  << A >>
Hal Murray wrote:
>> BTW, ZPU may have a GCC compiler, but without a debugger, is that
>> really useful?  There aren't many projects done in C that are debugged
>> without an emulator.
> 
> I'm happy without a debugger, at least as long as the edit/compile/run
> cycle is fast.  Besides, a lot of the quirks I'm chasing are
> timing issues where you need a scope to see what's going on.
> 
> What do you use for a debugger when working on perl/python code?
> 
For perl, Open Perl IDE
http://open-perl-ide.sourceforge.net/

-urb

Article: 138994
Subject: Re: Zero operand CPUs
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: Wed, 18 Mar 2009 11:43:32 +0100
Links: << >>  << T >>  << A >>
"Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com> writes:

> sure can use GCC as i already mentioned 4 posts ago :)
> but it not always as good as good macro assembler

I once wrote a microcode assembler *generator*. It would extract the
operand specs from the Verilog HDL source and generate an assembler on
the fly and then run it.

The only two hardcoded ops were "org" and "label". The program was
quite small, less than 200 lines of Common Lisp code. The assembler
was built on top of Common Lisp so you also got the powerful Common
Lisp macros and functions as a free feature.

Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 138995
Subject: Re: Zero operand CPUs
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Wed, 18 Mar 2009 10:45:04 +0000
Links: << >>  << T >>  << A >>
On 18 Mar 2009 11:24:45 GMT, Albert van der Horst wrote:

>The shallow stack of the transputer is lost on context
>switches for equal priority task. Together with the
>limitation where context switches could occur (only
>on conditional jumps) this accounts for a very practical
>design. (I would like to see a Ghz transputer with
>all the modern chip design tricks.)

Agreed wholeheartedly.  The Transputer suffered
badly because the technology that would make it
effective (particularly, very fast serial links)
was not available at the time; and the "prefix"
mechanism was too wasteful of code space for 
comfort; but it had some brilliantly clever
architectural ideas and I mourn its passing.

Context switches could happen only at "scheduling
points"; I think there were more of these than
merely conditional branches.  But whatever the
detail, the basic idea of choosing only to 
switch context when the stack is empty is 
very cool.  It requires very tight coupling 
among architecture, compiler and runtime
executive, though.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 138996
Subject: Re: Zero operand CPUs
From: Albert van der Horst <albert@spenarnc.xs4all.nl>
Date: 18 Mar 2009 11:24:45 GMT
Links: << >>  << T >>  << A >>
In article <2cpur41022f7ug3ql1mknldgq88lebftju@4ax.com>,
Jonathan Bromley  <jonathan.bromley@MYCOMPANY.com> wrote:
>On Tue, 17 Mar 2009 03:46:55 -0500, Hal Murray wrote:
>
>>You can simplify the hardware a lot by pushing
>>the stack overflow problem back to the compiler.
>>That is, the stack has a fixed size.  The compiler
>>can't generate code that overflows that limit.
>
>OK.
>
>Getting the compiler to limit the stack size is
>clearly possible (Transputer, anyone? it had a
>3-register stack).  But this is certain to
>cause more memory references to escape to
>memory.  It's a compromise, like everything else.

This 3 level stack already covered a great deal
of formulas to calculcate.
There is also a one byte instruction to fetch one of
16 memory locations, probably located in on chip ram.
You may think of those as registers, and below that as
explicit microcoding.

>
>>>Unfortunately the stack cache trashes multi-threading
>>>performance, because there is so much context to swap.
>[...]
>>I don't understand that comment.  Multi-threading requires
>>separate stacks.  That's just more RAM in the CPU
>
>Yes, but if a large swath of CPU register space is used
>to cache the top-of-stack, then that cache must be
>saved and restored on a context switch.  You can only
>provide a finite number of stack spaces in the CPU's
>on-chip RAM, so at some point a context switch is
>sure to entail a large penalty as some other thread's
>stack cache must be evicted to main memory.
>
>Shallower on-chip stack cache means slower single-
>thread performance, but faster context switch and
>the opportunity to keep more threads' stacks
>on-chip.  Compromises again.

The shallow stack of the transputer is lost on context
switches for equal priority task. Together with the
limitation where context switches could occur (only
on conditional jumps) this accounts for a very practical
design. (I would like to see a Ghz transputer with
all the modern chip design tricks.)

>--
>Jonathan Bromley, Consultant

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst


Article: 138997
Subject: Re: Zero operand CPUs
From: Albert van der Horst <albert@spenarnc.xs4all.nl>
Date: 18 Mar 2009 11:36:57 GMT
Links: << >>  << T >>  << A >>
In article <ebc3acb0-d9d7-47aa-bc80-c120670cc03a@s20g2000yqh.googlegroups.com>,
Antti.Lukats@googlemail.com <Antti.Lukats@googlemail.com> wrote:
>On Mar 17, 5:09=A0pm, rickman <gnu...@gmail.com> wrote:
>> On Mar 17, 9:58=A0am, "Antti.Luk...@googlemail.com"
>>
>>
>>
>>
>>
>> <Antti.Luk...@googlemail.com> wrote:
>> > On Mar 17, 3:24=A0pm, Jacko <jackokr...@gmail.com> wrote:
>>
>> > > Hi
>>
>> > > Three cheers for Chuck Moore, and his hidden friend Keep Less ;-)
>>
>> > > Another zero operand CPUhttp://nibz.googlecode.com
>>
>> > > cheers jacko
>>
>> > > Now available in free licence of one core per ASIC/FPGA/CPLD, with tw=
>o
>> > > conditions.
>> > > 1. A K Ring Technologies Logo must be printed atop the chip or close
>> > > by on the PCB at any resolution.
>> > > 2. Any documentation produced must acknowledge copyright and provide
>> > > the URL.
>>
>> > > This licence is for those folks who do not like the BSD derived work
>> > > restrictions.
>>
>> > the difference between zpu and nibz is that ZPU is supported
>> > by GCC toolchain, while there are no tools to generate any
>> > meaningful code for nibz
>>
>> > correct me if i am wrong
>>
>> > Antti
>>
>> Is that really the primary critera? =A0I think you are right. =A0But I
>> have a similar CPU design that I expect to use on a project shortly
>> and it will be programmed in assembly, but it will look a lot like
>> Forth. =A0I consider that to be close enough to a high level language.
>>
>> BTW, ZPU may have a GCC compiler, but without a debugger, is that
>> really useful? =A0There aren't many projects done in C that are debugged
>> without an emulator.
>>
>> Rick- Hide quoted text -
>>
>> - Show quoted text -
>
>well assembler is GOOD if it exist :)
>
>so any soft-core with assembler is ok
>but there is no assembler for nibz? so =3D=3D useless.
>no C, no assembler, =3D=3D not possible to use :(

I offer to write an assembler for euro 500 if it is of the
complexity of an 68K, and for Euro 1000 if it is of the
complexity of a DEC Alpha.

>a non working somesort of forht partially adopted
>but not really tested does not count as development tool.
>
>a simple assembler would.
>
>I personally dont like C, but unfortunatly can not fully avoid it
>either
>
>Antti

Now we are at it, would it not be a nice inroad for Forth if
we were to generate the back end of gcc by Forth Assemblers?
[My post-it fix-up assembler could be beefed up to do
   BEGIN NAME HASH PLONK REPEAT
where NAME fetches the next word, HASH does a perfect HASH
(and takes care of numbers) and PLONK is a single toggle of bits
into memory. There is no conditional code, except for error
checking.
Now the output of a compiler can be trusted ...
]

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst


Article: 138998
Subject: Re: Zero operand CPUs
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Wed, 18 Mar 2009 04:48:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 18, 8:45=A0am, rickman <gnu...@gmail.com> wrote:
> On Mar 17, 7:06=A0pm, Jacko <jackokr...@gmail.com> wrote:
>
>
>
> > There is now a link on the instruction set page presenting an english
> > text description of the BO instruction. All other instructions follow
> > a similar symbology.
>
> Dude, you are really terrible at this. =A0In one place you tell people
> about a CPU you designed with no specifics. =A0Another place you post a
> link to a web page with very fuzzy descriptions of the instruction set
> that is not usable. =A0Then here you post that you have added some more
> explanation, but no link. =A0Are we supposed to search around to find
> the link to your web page again? =A0I have no idea where to find it.
>
> I may not be very tactful, but I really am trying to help you, not be
> insulting. =A0I hope it doesn't come off that way.
>
> Rick

You are so right...
I looked (again) the nibz web

downloaded the most promising document (tagged FEATURED!)

did not understand much, scrolled to the end of the document..
where on the last line stands:

".... ummmm ...."

guess this is what we all should be doing: ummmmmmm

now, if we compare nibz to Mproz3

then
1 mproz3 is MUCH smaller
2 has superiour docu
3 has VERY simple assembler with source code (single file just invoke
gcc to compile it)

mproz3 is now available in VHDL form, and succesfully working in
Silicon Blue FPGA :)

so it doesnt matter how many times the nibz may be better, without
documentation
and tools its useless for anybody except the author.

Antti





Article: 138999
Subject: Re: Zero operand CPUs
From: Andrew Haley <andrew29@littlepinkcloud.invalid>
Date: Wed, 18 Mar 2009 07:20:00 -0500
Links: << >>  << T >>  << A >>
In comp.lang.forth Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:

> The shallow stack of the transputer is lost on context switches for
> equal priority task. Together with the limitation where context
> switches could occur (only on conditional jumps) this accounts for a
> very practical design.

Actually UNconditional jumps and lend (loop end).  This was quite nice
since you could prevent a context switch simply by

   ldc 0; cj L

Andrew.



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search