New soft processor core paper publisher?

Eric Wallin wrote:
> On Saturday, June 22, 2013 1:26:53 AM UTC-4, rickman wrote:
>
>> So why are you here exactly?  I'm not saying you shouldn't be here or
>> that you shouldn't be saying what you are saying.  But given how you
>> feel about Forth, I'm just curious why you want to have the conversation
>> you are having?  Are you exploring your inner curmudgeon?
>
> Just venting at the industry, and procrastinating a bit (putting off the final verification of the processor).  Apparently OT is my favorite subject as it seems I'm always busy derailing my own (and others) threads.  That, and Y'all have very interesting takes on these and various and sundry other things.
>
> Backing up a bit, it strikes me as a bit crazy to make a
> language based on the concept of a weird target processor.
> I mean, I get the portability thing, but at what cost?
> If my experience as a casual user (not programmer) of
> Java on my PC is any indication (data point of one,
> the plural of anecdote isn't data, etc.), the virtual stack-based
> processor paradigm has failed, as the constant updates, security
> issues, etc. pretty much forced me to uninstall it.

None of those real problems are related to "virtual stack-based
processor paradigm".



> And I would think that a language targeting a processor model
> that is radically different than the physically underlying one
> would be terribly inefficient unless the compiler can do hand
> stands while juggling spinning plates on fire - even if it is,
> god knows what it spits out.

That is just about what HotSpot does :) As L Peter Deutsch remarked
when people had similar reservations about the first (Smalltalk) JIT
in the mid 80s, if you can't tell the difference externally, the
internals don't matter.

Now for some fun how emulated processors can be faster than
native processors *even when both processors are the same*
   - take processor X executing cpu intensive C benchmarks
     compiled with optimisation on, and measure speed S1
   - write an emulator for processor X and run that emulator
     on processor X
   - run those C benchmarks on in the emulator, see what the
     code is actually doing (as opposed to what the compiler
     dared not assume)
   - use that knowledge to "patch the optimised binaries"
   - run the patched binaries in the emulator, and measure
     speed S2
   - note that S2 can be faster than S1
http://archive.arstechnica.com/reviews/1q00/dynamo/dynamo-1.html



> Canonical stack processors and theirlanguages (Forth, Java,
 > Postscript) at this point seem to be hanging by a legacy thread
> (even if every PC runs one peripherally at one time or another).

That's a bizarre assertion.

> I find it exceeding odd that the PC industry is still using
 > x86 _anything_ at this point.

backwards compatibility is the dominant commercial imperative:
don't inconvenience your existing customers. (Windows 8? Tee hee)

> Apple showed us you can just dumpyour processor and switch
 > horses in midstream pretty much whenever you feel like it
 > (68k => PowerPC => x86) and not torch your product line /
 > lose your customer base.

Only given preconditions that don't apply in the Wintel world.

David Brown wrote:

> I do mostly small-systems embedded programming, which is mostly in C. It used to include a lot more assembly, but that's quite rare now (though it is not uncommon to have to make little snippets in
> assembly, or to study compiler-generated assembly), and perhaps in the future it will include more C++ (especially with C++11 features).  I also do desktop and server programming, mostly in Python,
> and I have done a bit of FPGA work (but not for a number of years).

If C++ is the answer, I want to know what the question is.

How many *years* does it take before the first commercial
implementation of a C++ standard becomes available? Yes, I
know partial implementations become available pretty quickly.

Soustroup's tome describing "this is what I meant by the
various bits of C++" started out at ~400 pages and is now
around 1300 pages. 'Nuff said.

Don't forget that it is possible to get the compiler to
emit the sequence of prime numbers during the (unterminating)
compilation process. The language designers didn't realise
they had created such a monster until it was demonstrated
to them!
<http://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP>



> I just think it's fun to work with different types of language - it gives you a better understanding of programming in general, and new ideas of different ways to handle tasks.

Very true. Choose the right tool for the task at hand.

On 6/22/2013 12:26 PM, Eric Wallin wrote:
> On Saturday, June 22, 2013 1:26:53 AM UTC-4, rickman wrote:
>
>> So why are you here exactly?  I'm not saying you shouldn't be here or
>> that you shouldn't be saying what you are saying.  But given how you
>> feel about Forth, I'm just curious why you want to have the conversation
>> you are having?  Are you exploring your inner curmudgeon?
>
> Just venting at the industry, and procrastinating a bit (putting off the final verification of the processor).  Apparently OT is my favorite subject as it seems I'm always busy derailing my own (and others) threads.  That, and Y'all have very interesting takes on these and various and sundry other things.

I am cc'ing this to the forth group in case anyone there cares to join 
in.  I'm still a novice at the language so I only can give you my take 
on things.


> Backing up a bit, it strikes me as a bit crazy to make a language based on the concept of a weird target processor.  I mean, I get the portability thing, but at what cost?  If my experience as a casual user (not programmer) of Java on my PC is any indication (data point of one, the plural of anecdote isn't data, etc.), the virtual stack-based processor paradigm has failed, as the constant updates, security issues, etc. pretty much forced me to uninstall it.  And I would think that a language targeting a processor model that is radically different than the physically underlying one would be terribly inefficient unless the compiler can do hand stands while juggling spinning plates on fire - even if it is, god knows what it spits out.  Canonical stack processors and their languages (Forth, Java, Postscript) at this point seem to be hanging by a legacy thread (even if every PC runs one peripherally at one time or another).

Off the topic at hand, here is one of thunderbird's many issues as a 
news reader.  It displays messages just fine in the reading window, but 
in the edit window all of your quoted paragraphs show as single lines 
goiing far off the right side of the screen.  I have to switch back and 
forth to read the text I am replying to!

Back to the discussion...

By weird target processor you mean the virtual machine?  That is because 
it is a very simple model.  It does seem odd that such a model would be 
adopted, but the use of the stack makes for a very simple parameter 
passing method supported by very simple language features.  There is no 
need for syntax other than spaces.  That is *very* powerful and allows 
the tool to be kept very small.

Chuck Moore is all about simplicity and this is how he got this level of 
simplicity in the language.


> I suspect that multiple independent equal bandwidth threads (as I strongly suspect the Propeller has, and my processor definitely has) is such a natural construct - it fully utilizes the HW pipeline by eliminating all hazards, bubbles, stalls, branch prediction, etc. and uses the interstage registering for data and control value storage - that it will come more into common usage as compilers better adapt to multi-cores and threads.  Then again, the industry never met a billion transistor bizarro world processor it didn't absolutely love, so what do I know?

So what clock speeds does your processor achieve?  It is an interesting 
idea to pipeline everything and then treat the one processor as N 
processors running in parallel.  I think you have mentioned that here 
before and I seem to recall taking a quick look at the idea some time 
back.  It fits well with many of the features available in FPGAs and 
likely would do ok in an ASIC.  I just would not have much need for it 
in most of the things I am looking at doing.

Rather than N totally independent processors, have you considered using 
pipelining to implement SIMD?  This could get around some of the 
difficulties in the N wide processor like memory bandwidth.


> I find it exceeding odd that the PC industry is still using x86 _anything_ at this point.  Apple showed us you can just dump your processor and switch horses in midstream pretty much whenever you feel like it (68k =>  PowerPC =>  x86) and not torch your product line / lose your customer base.  I suppose having Intel and MS go belly up overnight is beyond the pale and at the root of why we can't have nice things.  I remember buying my first 286, imagining of all the wonderful projects it would enable, and then finding out what complete dogs the processor and OS were - it was quite disillusioning for the big boys to sell me a lump of shit like that (and for a lot more than 3 farthings).

You know why the x86 is still in use.  It is not really that bad in 
relation to the other architectures when measured objectively.  It may 
not be the best, but there is a large investment, mostly by Intel.  if 
Intel doesn't change why would anyone else?  But that is being eroded by 
the ARM processors in the handheld market.  We'll see if Intel can 
continue to adapt the x86 to low power and maintain a low cost.

I don't think MS is propping up the x86.  They offer a version of 
Windows for the ARM don't they?  As you say, there is a bit of processor 
specific code but the vast bulk of it is just a matter of saying ARMxyz 
rather than X86xyz.  Developers are another matter.  Not many want to 
support yet another target, period.  If the market opens up for Windows 
on ARM devices then that can change.  In the mean time it will be 
business as usual for desktop computing.

-- 

Rick

On Saturday, June 22, 2013 2:08:20 PM UTC-4, rickman wrote:

> So what clock speeds does your processor achieve?  It is an interesting=
=20
> idea to pipeline everything and then treat the one processor as N=20
> processors running in parallel.  I think you have mentioned that here=20
> before and I seem to recall taking a quick look at the idea some time=20
> back.  It fits well with many of the features available in FPGAs and=20
> likely would do ok in an ASIC.  I just would not have much need for it=20
> in most of the things I am looking at doing.

The core will do ~200 MHz in the smallest Cyclone 3 or 4 speed grade 8 (the=
 cheapest and slowest).  It looks to the outside world like 8 independent p=
rocessors (threads) running at 25 MHz, each with its own independent interr=
upt.  Internally each thread has 4 private general purpose stacks that are =
each 32 entries deep, but all threads fully share main memory (combined ins=
truction/data).

> Rather than N totally independent processors, have you considered using=
=20
> pipelining to implement SIMD?  This could get around some of the=20
> difficulties in the N wide processor like memory bandwidth.

I haven't given this very much thought.  But different cores could simultan=
eously work on different byte fields in a word in main memory so I'm not su=
re HW SIMD support is all that necessary.

This is just a small FPGA core, not an x86 killer.  Though it beats me why =
more muscular processors don't employ these simple techniques.

Eric Wallin wrote:

> The core will do ~200 MHz in the smallest Cyclone 3 or 4 speed grade
 > 8 (the cheapest and slowest).  It looks to the outside world like
> 8 independent processors (threads) running at 25 MHz, each with
> its own independent interrupt.  Internally each thread has 4
 > private general purpose stacks that are each 32 entries deep,
 > but all threads fully share main memory (combined instruction/data).

Have you defined what happens when one processor writes to a
memory location that is being read by another processor?
In other words, what primitives do you provide that allow
one processor to reliably communicate with another?

On 6/22/2013 4:11 PM, Eric Wallin wrote:
> On Saturday, June 22, 2013 2:08:20 PM UTC-4, rickman wrote:
>
>> So what clock speeds does your processor achieve?  It is an interesting
>> idea to pipeline everything and then treat the one processor as N
>> processors running in parallel.  I think you have mentioned that here
>> before and I seem to recall taking a quick look at the idea some time
>> back.  It fits well with many of the features available in FPGAs and
>> likely would do ok in an ASIC.  I just would not have much need for it
>> in most of the things I am looking at doing.
>
> The core will do ~200 MHz in the smallest Cyclone 3 or 4 speed grade 8 (the cheapest and slowest).  It looks to the outside world like 8 independent processors (threads) running at 25 MHz, each with its own independent interrupt.  Internally each thread has 4 private general purpose stacks that are each 32 entries deep, but all threads fully share main memory (combined instruction/data).
>
>> Rather than N totally independent processors, have you considered using
>> pipelining to implement SIMD?  This could get around some of the
>> difficulties in the N wide processor like memory bandwidth.
>
> I haven't given this very much thought.  But different cores could simultaneously work on different byte fields in a word in main memory so I'm not sure HW SIMD support is all that necessary.
>
> This is just a small FPGA core, not an x86 killer.  Though it beats me why more muscular processors don't employ these simple techniques.

That is my point.  With SIMD you have 1/8th the instruction rate saving 
memory accesses, but the same amount of data can be processed.  Of 
course, it all depends on your app.

-- 

Rick

On Saturday, June 22, 2013 4:22:02 PM UTC-4, Tom Gardner wrote:

> Have you defined what happens when one processor writes to a
> memory location that is being read by another processor?

Main memory is accessed by the threads sequentially, so there is no real co=
ntention possible.

> In other words, what primitives do you provide that allow
> one processor to reliably communicate with another?

None, it's all up to the programmer.  Off the top of my head, one thread mi=
ght keep tabs on a certain memory location A looking for a change of some s=
ort, perform some activity in response to this, then write to a separate lo=
cation B that one or more other threads are similarly watching.

Another option (that I didn't implement, but it would be simple to do) woul=
d be to enable interrupt access via the local register set, giving threads =
the ability to interrupt one another for whatever reason.  But doing this v=
ia a single register could lead to confusion because there is no atomic rea=
d/write access (and I don't think it's worth implementing atomics just for =
this).  Each thread interrupt could be in a separate register I suppose.  W=
ith an ocean of main memory available for flags and mail boxes and such I g=
uess I don't see the need for added complexity.

On Saturday, June 22, 2013 4:37:00 PM UTC-4, rickman wrote:

> That is my point.  With SIMD you have 1/8th the instruction rate saving 
> memory accesses, but the same amount of data can be processed.  Of 
> course, it all depends on your app.

But this processor core doesn't have a memory bandwidth bottleneck, so the instruction rate is moot.

Main memory is a full dual port BRAM, so each thread gets a chance to read/write data and fetch an instruction every cycle.  The bandwidth is actually overkill - the fetch side write port is unused.

I think the design document is good enough for general public consumption, =
so I applied for a project over at opencores.org (they say they'll get arou=
nd to it in one working day). =20

Still doing verification and minor code polishing, no bugs so far.  All bra=
nch immediate distances and conditionals check out; interrupts are working =
as expected; stack functionality, depth, and error reporting via the local =
register set checks out.  A log base 2 subroutine returns the same values a=
s a spreadsheet, ditto for restoring unsigned division.  I just need to con=
firm a few more things like logical and arithmetic ALU operations and the c=
ode should be good to go.

Eric Wallin wrote:
> On Saturday, June 22, 2013 4:22:02 PM UTC-4, Tom Gardner wrote:
>
>> Have you defined what happens when one processor writes to a
>> memory location that is being read by another processor?
>
> Main memory is accessed by the threads sequentially, so there is no real contention possible.

OK, so what *atomic* synchronisation primitives are available?
Classic examples involve atomic read-modify-write operations (e.g.
test and set, compare and swap). And they are bloody difficult
and non-scalable if there is any memory hierarchy.


>> In other words, what primitives do you provide that allow
>> one processor to reliably communicate with another?
>
> None, it's all up to the programmer.

That raises red flags with software engineers. Infamously
with the Itanic, for example!


> Off the top of my head, one thread might keep tabs on a certain memory location A looking for a change of some sort, perform some activity in response to this, then write to a separate location B that one or more other threads are similarly watching.
>
> Another option (that I didn't implement, but it would be simple to do) would be to enable interrupt access via the local register set, giving threads the ability to interrupt one another for whatever reason.  But doing this via a single register could lead to confusion because there is no atomic read/write access (and I don't think it's worth implementing atomics just for this).  Each thread interrupt could be in a separate register I suppose.  With an ocean of main memory available for flags and mail boxes and such I guess I don't see the need for added complexity.

How do you propose to implement mailboxes reliably?
You need to think of all the possible memory-access
sequences, of course.