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 155275

Article: 155275
Subject: Equivalent .tdf file in Aldec Active-HDL?
From: rc0clx@gmail.com
Date: Fri, 21 Jun 2013 01:54:07 -0700 (PDT)
Links: << >>  << T >>  << A >>

Is there an equivalent .tdf file in Aldec Active-HDL? One can find "text design file" in Quartus II. I like the same in Active-HDL.

Thanks.

Article: 155276
Subject: Re: New soft processor core paper publisher?
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Fri, 21 Jun 2013 10:30:39 +0100
Links: << >>  << T >>  << A >>
Elizabeth D. Rather wrote:
 > I'm also baffled about your comment about "programs that emit
 > Forth." Although PostScript has many features in common with
 > Forth, it is quite different, both in terms of command set
 > and programming model.

It was my comment, based on experience of writing
a few Forth and PostScript programs back in the mid 80s.

I'm know there are differences between Forth and
PostScript, but the similarities are /more/ significant.
Forth is like PostScript in the same way that Delphi
is like Pascal, C# is like Java, Scheme is like Lisp,
Objective-C is like SmallTalk (and unlike C++) etc.

And, more importantly, ForthPostscript is unlike C,
is unlike Prolog, is unlike Lisp, is unlike Smalltalk
is unlike Pascal.

I was beguiled by Forth and to some extend remain so:
I'd /love/ to find a good justification to use it again,
and might do so, just for the hell of it.

I'm sure Forth has moved on since the 80s, but it cannot
escape its ethos any more than C, Prolog, Lisp,
Smalltalk can. Or rather, if it did chance then it wouldn't
be Forth anymore.


 > Modern Forths (e.g. since the release of ANS Forth 94)
 > feature a variety of implementation strategies, ranging
 > from fairly conventional compilers that generate
 > optimized machine code to more traditional threaded code models.

I'm sure that's true, but it misses the point.
Interpreted Java is the same as jitted Java is
the same as Hotspotted Java.

Ditto Forth; if it wasn't then it simply wouldn't be Forth!

I suppose I ought to change "nobody writes Forth" to
"almost nobody writes Forth.

I would, however, be interested to know whether Forth
has a defined  memory model, since that's a _necessary_
_precondition_ to be able to write portable multithreaded
code that runs on multicore processors. Hells teeth,
even C has now has finally decided that they need to define
a memory model, only 20 years after those With Clue
knew it was required. (I don't think there are any
implementation though!)


Article: 155277
Subject: Re: New soft processor core paper publisher?
From: David Brown <david@westcontrol.removethisbit.com>
Date: Fri, 21 Jun 2013 13:18:32 +0200
Links: << >>  << T >>  << A >>
On 21/06/13 11:30, Tom Gardner wrote:

> I suppose I ought to change "nobody writes Forth" to
> "almost nobody writes Forth.
> 

Shouldn't that be "almost nobody Forth writes" ?

I wonder if Yoda programs in Forth...


(I too would like an excuse to work with Forth again.)


Article: 155278
Subject: Re: New soft processor core paper publisher?
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Fri, 21 Jun 2013 15:25:55 +0100
Links: << >>  << T >>  << A >>
David Brown wrote:
> On 21/06/13 11:30, Tom Gardner wrote:
>
>> I suppose I ought to change "nobody writes Forth" to
>> "almost nobody writes Forth.
>>
>
> Shouldn't that be "almost nobody Forth writes" ?

:)

Still use my HP calculators in preference to
algebraic and half-algebraic calculators!


Article: 155279
Subject: Re: New soft processor core paper publisher?
From: Eric Wallin <tammie.eric@gmail.com>
Date: Fri, 21 Jun 2013 21:44:29 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, June 21, 2013 10:25:55 AM UTC-4, Tom Gardner wrote:

> Still use my HP calculators in preference to
> algebraic and half-algebraic calculators!

Same here!  When manually calculating, give me HP (or similar) or give me d=
eath.  But Forth kind of sucks (and it pains me deeply to have discovered t=
hat).  The failure (as I see it) of Forth is the awkward target programming=
 model (or virtual machine as the kids say these days - virtual anything is=
 sexy).

There's a pretty big gulf between between manual data & operation entry on =
something like an HP (or any hand held calculator) and programming with For=
th (or any language).  A single stack very much facilitates the former but =
places handcuffs on the latter.  These are two fairly different activities =
that IMO don't exactly have boatloads of overlap, however much we might wan=
t or personally need for it to be so.

Article: 155280
Subject: Re: Modelsim ought to be cheaper
From: rickman <gnuarm@gmail.com>
Date: Sat, 22 Jun 2013 01:03:18 -0400
Links: << >>  << T >>  << A >>
On 6/20/2013 8:34 PM, Kevin Neilson wrote:
> I'd really like to make some cores in my spare time, but the revenues would be pretty small, and there is no way it would be worthwhile to buy Synplify and Modelsim licenses for such a small endeavor.  I don't know exactly what that would cost, but I'm sure it's tens of thousands.  It'd be great if I use the tools online for a few hours here and there and just pay for that..  Even if I couldn't use the GUI--if I could just get an EDIF and .srr file back--that would be useful.

I know Modelsim isn't that high, or at least it wasn't some 5 years ago. 
  I think I was quoted $5k give or take.  But then it is another $1k per 
year maintenance.  The point is the company has to have a given level of 
revenue and even if they adopt a per use based pricing structure, they 
would have to charge pretty steeply for each use to get that same level 
of revenue.

The only way it could become less expensive is if they ended up with a 
lot more sales.  I'm sure they have looked at it and found the "sweet 
spot" for pricing maximizing their profit.  After all, that is what it 
is about.


> I guess I could use Icarus or something, but I'm sure it's not going to parse the nice SysVerilog / VHDL 2008 code I write, and who wants to buy a core that comes with an Icarus project file?

Why can't you use the free versions of the tools provided by the FPGA 
vendors?  You get Active-HDL from Lattice, i think Xilinx has their own 
simulator and I don't know what Altera offers.  What does Microsemi 
offer these days since they bought Actel?

-- 

Rick

Article: 155281
Subject: Re: New soft processor core paper publisher?
From: rickman <gnuarm@gmail.com>
Date: Sat, 22 Jun 2013 01:07:12 -0400
Links: << >>  << T >>  << A >>
On 6/20/2013 11:38 PM, Eric Wallin wrote:
> On Thursday, June 20, 2013 7:50:09 PM UTC-4, rickman wrote:
>> Quitter!  If the syntax (or near total lack thereof) bothers you, then
>> you must have a very thin skin.
>
> Ha ha!  And I see what you did there.
>
>
> On Thursday, June 20, 2013 9:31:53 PM UTC-4, Elizabeth D. Rather wrote:
>> Eric, I'm curious what books these were that you found so offensive?
>
> The books ("Starting Forth", "Thinkind Forth", "Forth Programmer's Handbook") weren't themselves offensive, but they revealed Forth to be much lamer than I expected for all the stick-it-to-the-man ethos surrounding it.  I was totally stoked for a stack-based language that would solve all my problems, but all I got was some books gathering dust.
>
>> I'm also baffled about your comment about "programs that emit Forth."
>> Although PostScript has many features in common with Forth, it is quite
>> different, both in terms of command set and programming model.
>
> You're looking for Tom Gardner, he's down the hall near the elevators using a little stamp at the bottom of his cane to make little chicken footprints on the floor..

I just saw that episode a few weeks ago.  The chicken contest was pretty 
cool actually.

I actually identify with House.  Not that I am as smart as he is, but I 
have a bad hip (waiting for Obamacare to kick in so I can get a new one) 
and have a natural tendency to tick off people unless I work to reign it 
in.  :]

-- 

Rick

Article: 155282
Subject: Re: New soft processor core paper publisher?
From: rickman <gnuarm@gmail.com>
Date: Sat, 22 Jun 2013 01:20:13 -0400
Links: << >>  << T >>  << A >>
On 6/21/2013 5:30 AM, Tom Gardner wrote:
> Elizabeth D. Rather wrote:
>  > I'm also baffled about your comment about "programs that emit
>  > Forth." Although PostScript has many features in common with
>  > Forth, it is quite different, both in terms of command set
>  > and programming model.
>
> It was my comment, based on experience of writing
> a few Forth and PostScript programs back in the mid 80s.
>
> I'm know there are differences between Forth and
> PostScript, but the similarities are /more/ significant.
> Forth is like PostScript in the same way that Delphi
> is like Pascal, C# is like Java, Scheme is like Lisp,
> Objective-C is like SmallTalk (and unlike C++) etc.
>
> And, more importantly, ForthPostscript is unlike C,
> is unlike Prolog, is unlike Lisp, is unlike Smalltalk
> is unlike Pascal.
>
> I was beguiled by Forth and to some extend remain so:
> I'd /love/ to find a good justification to use it again,
> and might do so, just for the hell of it.

If you ever need to control hardware, you will want it.  The 
interactivity is great.
Actually, when doing things in real time the interactivity sort of goes 
away (or at least the utility of it) since you can't type fast enough to 
control a robot or intercept a serial port running at 38.4 kbps.  But 
you can very easily test small portions of your code in ways that are 
tricky in C or the other languages you mention.  Then those ideas can be 
applied to any app... even if not real time.


> I'm sure Forth has moved on since the 80s, but it cannot
> escape its ethos any more than C, Prolog, Lisp,
> Smalltalk can. Or rather, if it did chance then it wouldn't
> be Forth anymore.

Can *any* of us ever escape our ethos?  I know I've been trying for many 
a year and it is still right here by my side, aren't you Ethos? 
Actually, that would be a good name for a couple of dogs, Ethos and 
Pathos, Chesapeake Bay retrievers.


>  > Modern Forths (e.g. since the release of ANS Forth 94)
>  > feature a variety of implementation strategies, ranging
>  > from fairly conventional compilers that generate
>  > optimized machine code to more traditional threaded code models.
>
> I'm sure that's true, but it misses the point.
> Interpreted Java is the same as jitted Java is
> the same as Hotspotted Java.
>
> Ditto Forth; if it wasn't then it simply wouldn't be Forth!
>
> I suppose I ought to change "nobody writes Forth" to
> "almost nobody writes Forth.

So now I've been demoted to to "almost" nobody?  What do I have to do to 
work my way *up* to nobody?


> I would, however, be interested to know whether Forth
> has a defined memory model, since that's a _necessary_
> _precondition_ to be able to write portable multithreaded
> code that runs on multicore processors. Hells teeth,
> even C has now has finally decided that they need to define
> a memory model, only 20 years after those With Clue
> knew it was required. (I don't think there are any
> implementation though!)

Uh, can *someone* who knows something answer that one?

Do you have a lot of call to program multithreaded code for multicore 
processors?  What sort of apps are you coding?

-- 

Rick

Article: 155283
Subject: Re: New soft processor core paper publisher?
From: rickman <gnuarm@gmail.com>
Date: Sat, 22 Jun 2013 01:23:18 -0400
Links: << >>  << T >>  << A >>
On 6/21/2013 7:18 AM, David Brown wrote:
> On 21/06/13 11:30, Tom Gardner wrote:
>
>> I suppose I ought to change "nobody writes Forth" to
>> "almost nobody writes Forth.
>>
>
> Shouldn't that be "almost nobody Forth writes" ?

I would say that was "nobody almost Forth writes".  Wouldn't it be [noun 
[adjective] [noun [adjective]]] verb?

> (I too would like an excuse to work with Forth again.)

What do you do instead?

-- 

Rick

Article: 155284
Subject: Re: New soft processor core paper publisher?
From: rickman <gnuarm@gmail.com>
Date: Sat, 22 Jun 2013 01:26:53 -0400
Links: << >>  << T >>  << A >>
On 6/22/2013 12:44 AM, Eric Wallin wrote:
> On Friday, June 21, 2013 10:25:55 AM UTC-4, Tom Gardner wrote:
>
>> Still use my HP calculators in preference to
>> algebraic and half-algebraic calculators!
>
> Same here!  When manually calculating, give me HP (or similar) or give me death.  But Forth kind of sucks (and it pains me deeply to have discovered that).  The failure (as I see it) of Forth is the awkward target programming model (or virtual machine as the kids say these days - virtual anything is sexy).
>
> There's a pretty big gulf between between manual data&  operation entry on something like an HP (or any hand held calculator) and programming with Forth (or any language).  A single stack very much facilitates the former but places handcuffs on the latter.  These are two fairly different activities that IMO don't exactly have boatloads of overlap, however much we might want or personally need for it to be so.

I won't argue with any of that, or I might...

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?

-- 

Rick

Article: 155285
Subject: Re: New soft processor core paper publisher?
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Sat, 22 Jun 2013 09:34:46 +0100
Links: << >>  << T >>  << A >>
rickman wrote:
> On 6/21/2013 5:30 AM, Tom Gardner wrote:
>> Elizabeth D. Rather wrote:
>>  > I'm also baffled about your comment about "programs that emit
>>  > Forth." Although PostScript has many features in common with
>>  > Forth, it is quite different, both in terms of command set
>>  > and programming model.
>>
>> I was beguiled by Forth and to some extend remain so:
>> I'd /love/ to find a good justification to use it again,
>> and might do so, just for the hell of it.
>
> If you ever need to control hardware, you will want it.  The interactivity is great.

The first time I wished I had Forth was when manually
testing prototype hardware with a z80-class processor
c1983. Forth would have been ideal, and significantly
better than the rubbish I threw together.

That experience has shaped my views of "domain specific
languages" vs libraries to this day.

> Actually, when doing things in real time the interactivity sort of goes away (or at least the utility of it) since you can't type fast enough to control a robot or intercept a serial port running at
> 38.4 kbps.  But you can very easily test small portions of your code in ways that are tricky in C or the other languages you mention.  Then those ideas can be applied to any app... even if not real time.

Just so. It seems we are in violent agreement.

One also has to consider the tools that other people
are familiar with; changing away from them requires
very significant advantages, and Forth just doesn't
have those.


>> I suppose I ought to change "nobody writes Forth" to
>> "almost nobody writes Forth.
>
> So now I've been demoted to to "almost" nobody?  What do I have to do to work my way *up* to nobody?

Why are you assuming "demoted"? Is a screw above or
below a nail in some imagined hierarchy!


>> I would, however, be interested to know whether Forth
>> has a defined memory model, since that's a _necessary_
>> _precondition_ to be able to write portable multithreaded
>> code that runs on multicore processors. Hells teeth,
>> even C has now has finally decided that they need to define
>> a memory model, only 20 years after those With Clue
>> knew it was required. (I don't think there are any
>> implementation though!)
>
> Uh, can *someone* who knows something answer that one?
>
> Do you have a lot of call to program multithreaded code for multicore processors?  What sort of apps are you coding?

Even cellphones have dual and quad processors nowadays.

And, of course, there are outliers like the Parallax
Propellor.

Multicore will become the norm in the near future; the
only constraint in embedded systems will be memory bandwidth.

Article: 155286
Subject: Re: New soft processor core paper publisher?
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Sat, 22 Jun 2013 09:36:22 +0100
Links: << >>  << T >>  << A >>
rickman wrote:
> I won't argue with any of that, or I might...
>
> 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?

(a) because it is fun
(b) to gain a personal understanding of the advantages of
nails and screws, and when each should/shouldn't be used



Article: 155287
Subject: Re: Modelsim ought to be cheaper
From: Alan Fitch <apf@invalid.invalid>
Date: Sat, 22 Jun 2013 10:55:29 +0100
Links: << >>  << T >>  << A >>
On 22/06/13 06:03, rickman wrote:
> On 6/20/2013 8:34 PM, Kevin Neilson wrote:
>> I'd really like to make some cores in my spare time, but the revenues would be pretty small, and there is no way it would be worthwhile to buy Synplify and Modelsim licenses for such a small endeavor.  I don't know exactly what that would cost, but I'm sure it's tens of thousands.  It'd be great if I use the tools online for a few hours here and there and just pay for that..  Even if I couldn't use the GUI--if I could just get an EDIF and .srr file back--that would be useful.
> 
> I know Modelsim isn't that high, or at least it wasn't some 5 years ago. 
>   I think I was quoted $5k give or take.  But then it is another $1k per 
> year maintenance.  The point is the company has to have a given level of 
> revenue and even if they adopt a per use based pricing structure, they 
> would have to charge pretty steeply for each use to get that same level 
> of revenue.
> 
> The only way it could become less expensive is if they ended up with a 
> lot more sales.  I'm sure they have looked at it and found the "sweet 
> spot" for pricing maximizing their profit.  After all, that is what it 
> is about.
> 
> 
>> I guess I could use Icarus or something, but I'm sure it's not going to parse the nice SysVerilog / VHDL 2008 code I write, and who wants to buy a core that comes with an Icarus project file?
> 
> Why can't you use the free versions of the tools provided by the FPGA 
> vendors?  You get Active-HDL from Lattice, i think Xilinx has their own 
> simulator and I don't know what Altera offers.  What does Microsemi 
> offer these days since they bought Actel?
> 

Altera offer Modelsim Altera Edition (linked to the subscription edition
of Quartus), and Modelsim Altera Starter Edition (completely free).
Obviously they have limited capacity compared to the full edition of
Modelsim - but they do have a surprising range of language support,
include the design features of SystemVerilog.

There is a "cloud" version of Aldec Riviera - I don't know how much it
costs. See
http://www.aldec.com/en/solutions/functional_verification/aldec_cloud

Microsemi Libero SoC comes with a version of Modelsim, and of Synplify.

regards
Alan

-- 
Alan Fitch

Article: 155288
Subject: Re: New soft processor core paper publisher?
From: rickman <gnuarm@gmail.com>
Date: Sat, 22 Jun 2013 10:17:29 -0400
Links: << >>  << T >>  << A >>
On 6/22/2013 4:34 AM, Tom Gardner wrote:
> rickman wrote:
>> On 6/21/2013 5:30 AM, Tom Gardner wrote:
>>> Elizabeth D. Rather wrote:
>>> > I'm also baffled about your comment about "programs that emit
>>> > Forth." Although PostScript has many features in common with
>>> > Forth, it is quite different, both in terms of command set
>>> > and programming model.
>>>
>>> I was beguiled by Forth and to some extend remain so:
>>> I'd /love/ to find a good justification to use it again,
>>> and might do so, just for the hell of it.
>>
>> If you ever need to control hardware, you will want it. The
>> interactivity is great.
>
> The first time I wished I had Forth was when manually
> testing prototype hardware with a z80-class processor
> c1983. Forth would have been ideal, and significantly
> better than the rubbish I threw together.
>
> That experience has shaped my views of "domain specific
> languages" vs libraries to this day.

I'm not sure what that implies, but I'll go with it.


>> Actually, when doing things in real time the interactivity sort of
>> goes away (or at least the utility of it) since you can't type fast
>> enough to control a robot or intercept a serial port running at
>> 38.4 kbps. But you can very easily test small portions of your code in
>> ways that are tricky in C or the other languages you mention. Then
>> those ideas can be applied to any app... even if not real time.
>
> Just so. It seems we are in violent agreement.

Not *too* violent.  I don't have guns or anything like that.


> One also has to consider the tools that other people
> are familiar with; changing away from them requires
> very significant advantages, and Forth just doesn't
> have those.

I'm not sure what tools you mean.  Sometimes I miss using a debugger 
where I can step through my code.  Actually I bet Win32Forth has that 
somewhere, but the docs are not so great and I am likely missing some 
95% of what is in it.  Still, debuggers have their limits, notably they 
don't do a great job of getting you in the vicinity of the bug so you 
can step through the code to find it.

My willingness to give up debuggers and "go with the Forth" was largely 
prompted by a statement by Jeff Fox.  I don't recall the context exactly 
but I was talking about the difficulties of tracking down stack 
underflows.  My context was thinking like I was coding in C where I 
would write a bunch of code and then start in on the bugs often adding 
new ones in the process.  Jeff pointed out that in Forth, if you have a 
stack mismatch it shows that *you can't count*.  Even though (or perhaps 
because) it was so simple, that really struck me.  If I can't write a 
Forth word that balances the stack effects, it means I can't count to 
three or four.  Counting to three or four is a lot easier than using a 
debugger!


>>> I suppose I ought to change "nobody writes Forth" to
>>> "almost nobody writes Forth.
>>
>> So now I've been demoted to to "almost" nobody? What do I have to do
>> to work my way *up* to nobody?
>
> Why are you assuming "demoted"? Is a screw above or
> below a nail in some imagined hierarchy!

Context is everything.  I have no idea what the context of screw v nail 
is about.


>>> I would, however, be interested to know whether Forth
>>> has a defined memory model, since that's a _necessary_
>>> _precondition_ to be able to write portable multithreaded
>>> code that runs on multicore processors. Hells teeth,
>>> even C has now has finally decided that they need to define
>>> a memory model, only 20 years after those With Clue
>>> knew it was required. (I don't think there are any
>>> implementation though!)
>>
>> Uh, can *someone* who knows something answer that one?
>>
>> Do you have a lot of call to program multithreaded code for multicore
>> processors? What sort of apps are you coding?
>
> Even cellphones have dual and quad processors nowadays.
>
> And, of course, there are outliers like the Parallax
> Propellor.
>
> Multicore will become the norm in the near future; the
> only constraint in embedded systems will be memory bandwidth.

So which are you writing code for?  Or is this just a theoretical 
discussion?

As to multicore being the norm... well, the last toaster I bought does 
seem to have a micro in it, *really*.  It's a four slice unit, each half 
has three little buttons for bagel, frozen and reheat, one button for 
cancel and a darkness knob.  You have up to five seconds after pushing 
down the handle to make your selections.  I'll bet you anything this has 
a GA4 in it!  I can't imagine doing this without a multicore 
processor... oh, wait, that is programmed in Forth isn't it... what is 
that memory model again?

-- 

Rick

Article: 155289
Subject: Re: New soft processor core paper publisher?
From: chrisabele <ccabele@yahoo.com>
Date: Sat, 22 Jun 2013 10:19:55 -0400
Links: << >>  << T >>  << A >>
On 6/22/2013 1:20 AM, rickman wrote:
>...
> Actually, that would be a good name for a couple of dogs, Ethos and
> Pathos, Chesapeake Bay retrievers.
>...

What happened to the third dog, Logos?

A funny omission, given that this group is primarily logic related (only 
secondarily philosophy related).

Chris

Article: 155290
Subject: Re: New soft processor core paper publisher?
From: David Brown <david.brown@removethis.hesbynett.no>
Date: Sat, 22 Jun 2013 17:21:14 +0200
Links: << >>  << T >>  << A >>
On 22/06/13 07:23, rickman wrote:
> On 6/21/2013 7:18 AM, David Brown wrote:
>> On 21/06/13 11:30, Tom Gardner wrote:
>>
>>> I suppose I ought to change "nobody writes Forth" to
>>> "almost nobody writes Forth.
>>>
>>
>> Shouldn't that be "almost nobody Forth writes" ?
>
> I would say that was "nobody almost Forth writes".  Wouldn't it be [noun
> [adjective] [noun [adjective]]] verb?

I thought about that, but I was not sure.  When I say "work with Forth 
again", I have only "played" with Forth, not "worked" with it, and it 
was a couple of decades ago.

>
>> (I too would like an excuse to work with Forth again.)
>
> What do you do instead?
>

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).

I don't think of Forth as being a suitable choice of language for the 
kind of systems I work with - but I do think it would be fun to work 
with the kind of systems for which Forth is the best choice.  However, I 
suspect that is unlikely to happen in practice.  (Many years ago, my 
company looked at a potential project for which Atmel's Marc-4 
processors were a possibility, but that's the nearest I've come to Forth 
at work.)

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.


Article: 155291
Subject: Re: New soft processor core paper publisher?
From: rickman <gnuarm@gmail.com>
Date: Sat, 22 Jun 2013 12:18:55 -0400
Links: << >>  << T >>  << A >>
On 6/22/2013 11:21 AM, David Brown wrote:
> On 22/06/13 07:23, rickman wrote:
>> On 6/21/2013 7:18 AM, David Brown wrote:
>>> On 21/06/13 11:30, Tom Gardner wrote:
>>>
>>>> I suppose I ought to change "nobody writes Forth" to
>>>> "almost nobody writes Forth.
>>>>
>>>
>>> Shouldn't that be "almost nobody Forth writes" ?
>>
>> I would say that was "nobody almost Forth writes". Wouldn't it be [noun
>> [adjective] [noun [adjective]]] verb?
>
> I thought about that, but I was not sure. When I say "work with Forth
> again", I have only "played" with Forth, not "worked" with it, and it
> was a couple of decades ago.

Hey, it's not like this is *real* forth.  But looking at how some Forth 
code works for things like assemblers and my own projects, the data is 
dealt with first starting with some sort of a noun type piece of data 
(like a register) which may be modified by an adjective (perhaps an 
addressing mode) followed by others, then the final verb to complete the 
action (operation).


>>> (I too would like an excuse to work with Forth again.)
>>
>> What do you do instead?
>>
>
> 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).

Similar to myself, but with the opposite emphasis.  I mostly do hardware 
and FPGA work with embedded programming which has been rare for some years.

I think Python is the language a customer recommended to me.  He said 
that some languages are good for this or good for that, but Python 
incorporates a lot of the various features that makes it good for most 
things.  They write code running under Linux on IP chassis.  I think 
they use Python a lot.


> I don't think of Forth as being a suitable choice of language for the
> kind of systems I work with - but I do think it would be fun to work
> with the kind of systems for which Forth is the best choice. However, I
> suspect that is unlikely to happen in practice. (Many years ago, my
> company looked at a potential project for which Atmel's Marc-4
> processors were a possibility, but that's the nearest I've come to Forth
> at work.)

So why can't you consider Forth for processors that aren't stack based?


> 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.

I'm beyond "playing" in this stuff and I don't mean "playing" in a 
derogatory way, I mean I just want to get my work done.  I'm all but 
retired and although some of my projects are not truly profit motivated, 
I want to get them done with a minimum of fuss.  I look at the tools 
used to code in C on embedded systems and it scares me off really, 
especially the open source ones that require you to learn so much before 
you can become productive or even get the "hello world" program to work. 
  That's why I haven't done anything with the rPi or the Beagle Boards.

-- 

Rick

Article: 155292
Subject: Re: New soft processor core paper publisher?
From: Eric Wallin <tammie.eric@gmail.com>
Date: Sat, 22 Jun 2013 09:26:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
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=20
> that you shouldn't be saying what you are saying.  But given how you=20
> feel about Forth, I'm just curious why you want to have the conversation=
=20
> you are having?  Are you exploring your inner curmudgeon?

Just venting at the industry, and procrastinating a bit (putting off the fi=
nal verification of the processor).  Apparently OT is my favorite subject a=
s it seems I'm always busy derailing my own (and others) threads.  That, an=
d Y'all have very interesting takes on these and various and sundry other t=
hings.

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 thi=
ng, but at what cost?  If my experience as a casual user (not programmer) o=
f Java on my PC is any indication (data point of one, the plural of anecdot=
e isn't data, etc.), the virtual stack-based processor paradigm has failed,=
 as the constant updates, security issues, etc. pretty much forced me to un=
install it.  And I would think that a language targeting a processor model =
that is radically different than the physically underlying one would be ter=
ribly inefficient unless the compiler can do hand stands while juggling spi=
nning plates on fire - even if it is, god knows what it spits out.  Canonic=
al stack processors and their languages (Forth, Java, Postscript) at this p=
oint seem to be hanging by a legacy thread (even if every PC runs one perip=
herally at one time or another).

I suspect that multiple independent equal bandwidth threads (as I strongly =
suspect the Propeller has, and my processor definitely has) is such a natur=
al construct - it fully utilizes the HW pipeline by eliminating all hazards=
, bubbles, stalls, branch prediction, etc. and uses the interstage register=
ing 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, t=
he industry never met a billion transistor bizarro world processor it didn'=
t absolutely love, so what do I know?

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 =3D> PowerP=
C =3D> x86) and not torch your product line / lose your customer base.  I s=
uppose 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 disillusion=
ing for the big boys to sell me a lump of shit like that (and for a lot mor=
e than 3 farthings).

Article: 155293
Subject: Re: New soft processor core paper publisher?
From: Eric Wallin <tammie.eric@gmail.com>
Date: Sat, 22 Jun 2013 09:36:20 -0700 (PDT)
Links: << >>  << T >>  << A >>
Why is it that every "serious" processor is a ball of cruft with multiple bags on the side, some much worse than others, but none even a mother could love?  Is it because overly complex compilers have made HW developers disillusioned / complacent?  

I honestly don't get how we got here from there.  If it's anything, engineering is an exercise in complexity management, but processor design is somehow flying under the radar.

Article: 155294
Subject: Re: New soft processor core paper publisher?
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Sat, 22 Jun 2013 17:56:24 +0100
Links: << >>  << T >>  << A >>
Eric Wallin wrote:
> Why is it that every "serious" processor is a ball of cruft with multiple bags on the side, some much worse than others, but none even a mother could love?  Is it because overly complex compilers have made HW developers disillusioned / complacent?

1) an adherence to the von Neumann concepts of what a processor should be
2) processing models that worked well given previous technology limits,
    but which don't scale to modern technology limits (e.g processor/memory
    speed ratio, number of ic pins, cache coherence)
3) backwards compatibility (*the* dominant commercial consideration)



> I honestly don't get how we got here from there.  If it's anything, engineering is an exercise in complexity management, but processor design is somehow flying under the radar.

1) look at The Mill on comp.arch, for one beguiling possibility
2) message passing between processors/threads executing on
    multiprocessor machines with non-coherent memories



Article: 155295
Subject: Re: New soft processor core paper publisher?
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Sat, 22 Jun 2013 18:17:18 +0100
Links: << >>  << T >>  << A >>
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.


Article: 155296
Subject: Re: New soft processor core paper publisher?
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Sat, 22 Jun 2013 18:27:11 +0100
Links: << >>  << T >>  << A >>
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.



Article: 155297
Subject: Re: New soft processor core paper publisher?
From: rickman <gnuarm@gmail.com>
Date: Sat, 22 Jun 2013 14:08:20 -0400
Links: << >>  << T >>  << A >>
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

Article: 155298
Subject: Re: New soft processor core paper publisher?
From: Eric Wallin <tammie.eric@gmail.com>
Date: Sat, 22 Jun 2013 13:11:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.

Article: 155299
Subject: Re: New soft processor core paper publisher?
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Sat, 22 Jun 2013 21:22:02 +0100
Links: << >>  << T >>  << A >>
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?



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