| View previous topic :: View next topic |
| Author |
Message |
Rob Warnock
Guest
|
 Posted: Wed Aug 27, 2008 6:51 am Post subject: Re: Future architectures [was Re: Intel details future Larra |
 |
|
Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
+---------------
| rpw3@rpw3.org (Rob Warnock) writes:
| |> My guess would be the rise of separate I & D on-chip caches, which
| |> naturally leads to a Harvard approach inside the CPU/ALU pipeline,
| |> while the external memory interface remains (mostly) von Neumann...
|
| Well, separate I and D caches was a well-established technology by
| the 1960s (and probably a lot earlier).
+---------------
Well, you couldn't tell it by me!! ;-} I started coding in 1965,
and *none* of the machines I learned on[1] had *any* caches yet, not
even the venerable DEC PDP-10 (KA10) we got in 1970 (FCS Sep. 1967) --
and in those days the -10 was used for quite significant timesharing
loads! Not until the KL10 (FCS June 1975) did the PDP-10 series get
any cache at all.[2]
And the first microprocessor I ran into that had separate on-chip
I & D caches would have been the MIPS R3000, circa 1988.
You were clearly in a different world than I was at the time.
[Not surprising, as I was nowhere near any of the centers of
advanced computing research until 1980 or so.]
-Rob
[1] IBM 1410, LGP-30, IBM 1620, DEC PDP-10, PDP-8, PDP-11.
[2] I don't count the "fast registers" (accumulators) of the
KA10 & KI10 or the TLB of the KI10 as "cache" in the sense
of this discussion.
-----
Rob Warnock <rpw3@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607 |
|
| |
|
 Back to top |
Nick Maclaren
Guest
|
| Posted: Wed Aug 27, 2008 9:20 am Post subject: Re: Future architectures [was Re: Intel details future Larra |
|
|
In article <ofydnRgczKm1XinVnZ2dnUVZ_tfinZ2d@speakeasy.net>,
rpw3@rpw3.org (Rob Warnock) writes:
|>
|> +---------------
|> | |> My guess would be the rise of separate I & D on-chip caches, which
|> | |> naturally leads to a Harvard approach inside the CPU/ALU pipeline,
|> | |> while the external memory interface remains (mostly) von Neumann...
|> |
|> | Well, separate I and D caches was a well-established technology by
|> | the 1960s (and probably a lot earlier).
|> +---------------
|>
|> Well, you couldn't tell it by me!! ;-} I started coding in 1965,
|> and *none* of the machines I learned on[1] had *any* caches yet, ...
The IBM 370/165 did! I can't now remember the details, but that was
a (very) late 1960s machine.
|> You were clearly in a different world than I was at the time.
|> [Not surprising, as I was nowhere near any of the centers of
|> advanced computing research until 1980 or so.]
Cambridge had stopped doing much hardware work by the time I
arrived.
Regards,
Nick Maclaren. |
|
| |
|
| Back to top |
Wilco Dijkstra
Guest
|
| Posted: Wed Aug 27, 2008 9:20 am Post subject: Re: Future architectures [was Re: Intel details future Larra |
|
|
"JosephKK" <quiettechblue@yahoo.com> wrote in message news:62r9b4hafqbn5nuaiu4379prqguunokgqt@4ax.com...
| Quote: | On Tue, 26 Aug 2008 23:56:47 +0100, "Wilco Dijkstra"
Wilco.removethisDijkstra@ntlworld.com> wrote:
"Terje Mathisen" <terje.mathisen@hda.hydro.com> wrote in message news:PKydnRanqZPHcy7VnZ2dnUVZ8srinZ2d@giganews.com...
JosephKK wrote:
On 25 Aug 2008 18:32:43 GMT, nmm1@cus.cam.ac.uk (Nick Maclaren) wrote:
That doesn't help with denormals, though! You can't always use them
in denormalised form, and can rarely use the same code as for normal
numbers unless you normalise them.
Regards,
Nick Maclaren.
Would you kindly explain to me how to normalize a denormal without
expanding the exponent range?
You don't.
I.e. a sw library will almost certainly choose to work in an internal exponent format with a lot more bits, like a
32-bit int.
To follow the spec you have to denormalize (if needed) the result again after each operation, unless you can fake it
exactly.
One possible idea would be to mask away (with proper rounding) the bottom bits that would have been shifted away
during the conversion to external exponent range.
You can often use unnormalized denormals but with the exponent forced
to 1. This gives the correct result for add/sub and multiply but it's usually
better to normalize division and square root.
When you normalize you just need an extra exponent bit to allow for
negative exponents. I often bias the exponent by 1 so that the largest
denormal has exponent -1 (rather than 0). This allows the overflow
and underflow tests to be done using a single compare. It also makes
recombining the exponent and mantissa easier.
You can use a wider internal format for the calculations as long as no
rounding is done to the internal format. You can only round once when
you create the final result with the reduced exponent/mantissa (ie.
rounding must be done on the final denormal value).
Wilco
And what actual hardware are taking about?
|
We were talking about emulating IEEE in software, so it works on any
hardware. My C implementation requires a 32-bit type, so as long as your
compiler has one, it will work.
Wilco |
|
| |
|
| Back to top |
MooseFET
Guest
|
| Posted: Wed Aug 27, 2008 1:15 pm Post subject: Re: Future architectures [was Re: Intel details future Larra |
|
|
On Aug 27, 1:54 pm, JosephKK <quiettechb...@yahoo.com> wrote:
| Quote: | On Wed, 27 Aug 2008 00:05:47 +0100, "Wilco Dijkstra"
Wilco.removethisDijks...@ntlworld.com> wrote:
"MooseFET" <kensm...@rahul.net> wrote in message
news:ac9d3411-d83d-49d5-8310-bd649ed43a69@n33g2000pri.googlegroups.com...
On Aug 26, 7:51 pm, Terje Mathisen <terje.mathi...@hda.hydro.com
wrote:
JosephKK wrote:
On 25 Aug 2008 18:32:43 GMT, n...@cus.cam.ac.uk (Nick Maclaren) wrote:
That doesn't help with denormals, though! You can't always use them
in denormalised form, and can rarely use the same code as for normal
numbers unless you normalise them.
Regards,
Nick Maclaren.
Would you kindly explain to me how to normalize a denormal without
expanding the exponent range?
You don't.
I.e. a sw library will almost certainly choose to work in an internal
exponent format with a lot more bits, like a 32-bit int.
To follow the spec you have to denormalize (if needed) the result again
after each operation, unless you can fake it exactly.
One possible idea would be to mask away (with proper rounding) the
bottom bits that would have been shifted away during the conversion to
external exponent range.
If I was coding such a library I would most likely convert to an
internal format with a longer mantissa and a base 256 exponent. While
the numbers are being held in the internals, a few extra bytes needed
for such a format would be a low price to pay for the greater speed.
A base 256 number with a longer mantissa speeds up adding and
subtracting at the cost of some speed in the multiply and divide.
Making the mantissa a multiple of the natural word length of the
processor, gets you most of that back.
The mantissa would normally already be 32-bit or 64-bit internally.
Addition is already as simple as:
res = manta + (mantb >> (expa - expb));
I can't see how rebasing the exponent could possibly simplify this.
Wilco
Would the both of you try reading IEEE 754 please?
|
Yes, I know that he didn't show the right operation for the alignment
before the add, but I don't think it matters to my disagreement with
him since the right one requires an extra bit of "if" logic and
depending on the exponent the prepending of a one. |
|
| |
|
| Back to top |
MooseFET
Guest
|
| Posted: Wed Aug 27, 2008 1:27 pm Post subject: Re: Future architectures [was Re: Intel details future Larra |
|
|
On Aug 27, 1:16 pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
| Quote: | MooseFET wrote:
Many of the tools require way too much knowledge about the internal
details of the chip to make your source code really portable.
I would say not much more than you need to know about most
computers to write portable and fast C code, but you probably
don't think about those.
If I write careful "C" for gcc, it is portable without thinking about
the details of the CPU chip that runs it. If you keep it simple gcc
produces very good results.
Even with FPGAs the code can be quite portable. Usually quite small
portability layer that contains PLLs and special IO pins is only
needed. Most of the memories can be nowadays written portably etc.
That can be compared to code needed to support different operating
systems in C programs.
|
I have never seen a case of FPGA code going between Xilinx's tools and
Altera's without some very serious rewriting.
| Quote: | Of course some coders like to use special blocks, big IP cores from
the vendors etc. At that point the portability is not so great, but
that is also comparable to usage of OS specific libraries in software
projects.
I think the bigger obstacle in FPGA use is the parallel vs. sequential
mindset of programming.
|
I don't see that as an obstacle at all. The sequential mindset is a
learned thing. If you do FPGAs, parallel computers, random logic or
design analog circuits, you think in parallel terms. |
|
| |
|
| Back to top |
MooseFET
Guest
|
| Posted: Wed Aug 27, 2008 1:30 pm Post subject: Re: Future architectures [was Re: Intel details future Larra |
|
|
On Aug 27, 2:02 pm, JosephKK <quiettechb...@yahoo.com> wrote:
| Quote: | On Tue, 26 Aug 2008 11:48:40 -0700, "Joel Koltner"
zapwireDASHgro...@yahoo.com> wrote:
"glen herrmannsfeldt" <g...@ugcs.caltech.edu> wrote in message
news:PrmdnUxpJeN_1SnVnZ2dnUVZ_vjinZ2d@comcast.com...
I think, though, that dataflow is
closer to the way to think about logic design than
traditional programming languages.
I wonder if LabView programmers might make good VHDL/Verilog programmers?
I would be really surprised. Functional/procedural languages are
conceptually very different from logic HDLs. Though at least a few
will be.
|
I think the "it all always happens" thinking of analog circuit design
is more like FPGA design than most programming languages. |
|
| |
|
| Back to top |
Nick Maclaren
Guest
|
| Posted: Wed Aug 27, 2008 7:06 pm Post subject: Re: Future architectures [was Re: Intel details future Larra |
|
|
In article <ba1d77ae-176b-4c94-8fdd-ada3e6061aab@a2g2000prm.googlegroups.com>,
MooseFET <kensmith@rahul.net> writes:
|>
|> I think the "it all always happens" thinking of analog circuit design
|> is more like FPGA design than most programming languages.
Because most are Von Neumann! Prolog is much closer to analogue
computers.
Regards,
Nick Maclaren. |
|
| |
|
| Back to top |
Anne & Lynn Wheeler
Guest
|
| Posted: Wed Aug 27, 2008 7:37 pm Post subject: Re: Future architectures |
|
|
rpw3@rpw3.org (Rob Warnock) writes:
| Quote: | Well, you couldn't tell it by me!! ;-} I started coding in 1965,
and *none* of the machines I learned on[1] had *any* caches yet, not
even the venerable DEC PDP-10 (KA10) we got in 1970 (FCS Sep. 1967) --
and in those days the -10 was used for quite significant timesharing
loads! Not until the KL10 (FCS June 1975) did the PDP-10 series get
any cache at all.[2]
|
look a virtual memory systems from 60s ... cp40 (on 360/40 with custom
virtual memory hardware) and cp67 (on 360/67 that came standard with
virtual memory) the size of real storage and the relative page-miss
latency to paging drum (in processor cycles) is compareable to modern
processor caches and relative cache-miss latency to memory. somewhat
related earlier post in this thread
http://www.garlic.com/~lynn/2008m.html#1 Future architectures
besides the mentioned paging algorithm work as undergraduate in the 60s,
i had also done a lot of scheduling algorithm and other performance
related work (all of it shipping in cp67 product). in the
(simplification) morph from cp67 to vm370 ... a lot of that work was
dropped.
i had moved a lot of the work (that had been dropped in the morph) to
vm370 and made it available in internally distributed systems ... some
recent posts with references
http://www.garlic.com/~lynn/2008l.html#72 Error handling for system calls
http://www.garlic.com/~lynn/2008l.html#82 Yet another squirrel question
when the future system project failed
http://www.garlic.com/~lynn/subtopic.html#futuresys
there was something of a mad rush to get stuff back into the 370 product
pipeline (which had been neglected ... some assumptions that future
system would replace 370). this was possibly some of the motivation to
pickup & release much of the stuff that I had been doing (during the
future system period). some recent references:
http://www.garlic.com/~lynn/2008m.html#1 Yet another squirrel question
http://www.garlic.com/~lynn/2008m.html#10 Unbelievable Patent for JCL
one of the features that I had added with moving a lot of my stuff from
cp67 to vm370 ... was some scheduling cache optimization (with the
increasing use of caches on 370 processors). Nominally, system was
enabled for (asynchronous) i/o interrupts ... which can have lot of
downside pressure on cache hit ratio. The scheduler would look at
relative i/o interrupt rates ... and change from general enabled for i/o
interrupts to mostly disabled for i/o interrupts with periodic check for
pending i/o interrupts. This traded off cache-hit performance against
i/o service time latency.
for other topic drift ... there was survey of some number of operations
during the summer of '81 (which included some KL10 and Vax systems)
this post has some excerpts from that survey (with some comments
about time-sharing comparison between cp67 and some KL10 systems):
http://www.garlic.com/~lynn/2001l.html#61
other posts with other excerpts from that survey
http://www.garlic.com ~lynn/2006n.html#56
http://www.garlic.com/~lynn/2008m.html#11
other past posts mentioning scheduling/performance work
http://www.garlic.com/~lynn/subtopic.html#fairshare
other past posts mentioning paging algorithm work
http://www.garlic.com/~lynn/subtopic.html#wsclock
--
40+yrs virtualization experience (since Jan68), online at home since Mar70 |
|
| |
|
| Back to top |
Guest
|
| Posted: Thu Aug 28, 2008 5:08 am Post subject: Re: Future architectures [was Re: Intel details future Larra |
|
|
On Thu, 28 Aug 2008 00:08:49 +0100, "Wilco Dijkstra"
<Wilco.removethisDijkstra@ntlworld.com> wrote:
| Quote: | "MooseFET" <kensmith@rahul.net> wrote in message
snip
A 4 bit shift takes quite a bit of time on an 8-bitter. You have only
one carry to tranfer the bits between bytes so it is usually faster to
do 4 one bit shifts. Here it is for an 8051:
CLR C ; Shift in a zero
MOV A,LSB ; Load the lowest
RLC A ; Shift up one
MOV LSB,A
MOV A,LSB+1 ; Next byte
RLC A
MOV LSB+1,A
MOV A,LSB+2 ; Next byte
RLC A
MOV LSB+2,A
MOV A,LSB+3 ; Next byte
RLC A
MOV LSB+3,A
As you can see it comes out to 13 instructions per one bit shift.
This makes it well worth avoiding if you can.
Note you can use XCH in the above code to get it down to 9 instructions.
XCH stores in one byte and fetches from the next? |
--
ArarghMail808 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
To reply by email, remove the extra stuff from the reply address. |
|
| |
|
| Back to top |
Kim Enkovaara
Guest
|
| Posted: Thu Aug 28, 2008 11:11 am Post subject: Re: Future architectures [was Re: Intel details future Larra |
|
|
MooseFET wrote:
| Quote: | On Aug 27, 1:16 pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
Even with FPGAs the code can be quite portable. Usually quite small
...
I have never seen a case of FPGA code going between Xilinx's tools and
Altera's without some very serious rewriting.
|
Then you have something wrong in your coding style. Normally if some
portability is taken into consideration during design, porting takes
few days to get first impressions. Usually what is needed is some
tweaking of attributes in inferred memories, new clocking scheme
(PLL etc.) and maybe some IO pin instantiations if DDR or very
high speed signaling is used. For some higher level IP (tranceivers,
PCI express etc.) more effort is needed, but that can be handled
by portability layers.
With third party synthesizer scripts need only minor changes. And even
with the integrated ones usually some editor tweaking can be used
to get most of the scripts converted. STA is the most painful thing
to convert, that will take some time. But that is only loosely part
of the code, and Synopsys SDC format is gaining ground in FPGA tools
also.
It is quite normal to code the FPGA to support many different chips
and keep the vendors fighting with price to the end and select the
one that was the cheapest ;)
--Kim |
|
| |
|
| Back to top |
MooseFET
Guest
|
| Posted: Thu Aug 28, 2008 12:58 pm Post subject: Re: Future architectures [was Re: Intel details future Larra |
|
|
On Aug 27, 11:11 pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
| Quote: | MooseFET wrote:
On Aug 27, 1:16 pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
Even with FPGAs the code can be quite portable. Usually quite small
...
I have never seen a case of FPGA code going between Xilinx's tools and
Altera's without some very serious rewriting.
Then you have something wrong in your coding style. Normally if some
portability is taken into consideration during design, porting takes
few days to get first impressions.
|
I wasn't referring to just my code when I said "seen".
Do you use the assignment of the "Z" value to cause a tri-state?
Quartus doesn't compile them.
| Quote: | Usually what is needed is some
tweaking of attributes in inferred memories, new clocking scheme
(PLL etc.) and maybe some IO pin instantiations if DDR or very
high speed signaling is used. For some higher level IP (tranceivers,
PCI express etc.) more effort is needed, but that can be handled
by portability layers.
With third party synthesizer scripts need only minor changes. And even
with the integrated ones usually some editor tweaking can be used
to get most of the scripts converted. STA is the most painful thing
to convert, that will take some time. But that is only loosely part
of the code, and Synopsys SDC format is gaining ground in FPGA tools
also.
|
We were talking of the tools that are free or low cost that come from
the makers of the chips.
| Quote: | It is quite normal to code the FPGA to support many different chips
and keep the vendors fighting with price to the end and select the
one that was the cheapest 
|
I really don't care which chip is the cheapest. In the market I'm in,
nearly all electronic designs are a "cost is no object" sort of
thing. The first 3 tings on the list are reliability. Then comes low
power and light weight. |
|
| |
|
| Back to top |
Guest
|
| Posted: Thu Aug 28, 2008 1:50 pm Post subject: Re: Future architectures [was Re: Intel details future Larra |
|
|
On Aug 28, 3:58 pm, MooseFET <kensm...@rahul.net> wrote:
| Quote: | On Aug 27, 11:11 pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
MooseFET wrote:
On Aug 27, 1:16 pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
Even with FPGAs the code can be quite portable. Usually quite small
...
I have never seen a case of FPGA code going between Xilinx's tools and
Altera's without some very serious rewriting.
Then you have something wrong in your coding style. Normally if some
portability is taken into consideration during design, porting takes
few days to get first impressions.
I wasn't referring to just my code when I said "seen".
Do you use the assignment of the "Z" value to cause a tri-state?
Quartus doesn't compile them.
|
When you assign "Z" to external pin - Quartus compiles it very well,
thank you.
On the other hand, internal tristate nodes are not supported by Altera
architecture - how would you expect Quartus to synthesize them in this
case? Infer muxes? |
|
| |
|
| Back to top |
Muzaffer Kal
Guest
|
| Posted: Thu Aug 28, 2008 9:09 pm Post subject: Re: Future architectures [was Re: Intel details future Larra |
|
|
On Thu, 28 Aug 2008 06:50:25 -0700 (PDT), already5chosen@yahoo.com
wrote:
| Quote: | On Aug 28, 3:58 pm, MooseFET <kensm...@rahul.net> wrote:
On Aug 27, 11:11 pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
MooseFET wrote:
On Aug 27, 1:16 pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
Even with FPGAs the code can be quite portable. Usually quite small
...
I have never seen a case of FPGA code going between Xilinx's tools and
Altera's without some very serious rewriting.
Then you have something wrong in your coding style. Normally if some
portability is taken into consideration during design, porting takes
few days to get first impressions.
I wasn't referring to just my code when I said "seen".
Do you use the assignment of the "Z" value to cause a tri-state?
Quartus doesn't compile them.
When you assign "Z" to external pin - Quartus compiles it very well,
thank you.
On the other hand, internal tristate nodes are not supported by Altera
architecture - how would you expect Quartus to synthesize them in this
case? Infer muxes?
|
Actually MaxplusII had support for converting internal tri-states to
muxes. That feature is removed in Quartus? |
|
| |
|
| Back to top |
Guest
|
| Posted: Thu Aug 28, 2008 9:39 pm Post subject: Re: Future architectures [was Re: Intel details future Larra |
|
|
On Aug 28, 6:09 pm, Muzaffer Kal <k...@dspia.com> wrote:
| Quote: | On Thu, 28 Aug 2008 06:50:25 -0700 (PDT), already5cho...@yahoo.com
wrote:
On Aug 28, 3:58 pm, MooseFET <kensm...@rahul.net> wrote:
On Aug 27, 11:11 pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
MooseFET wrote:
On Aug 27, 1:16 pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
Even with FPGAs the code can be quite portable. Usually quite small
...
I have never seen a case of FPGA code going between Xilinx's tools and
Altera's without some very serious rewriting.
Then you have something wrong in your coding style. Normally if some
portability is taken into consideration during design, porting takes
few days to get first impressions.
I wasn't referring to just my code when I said "seen".
Do you use the assignment of the "Z" value to cause a tri-state?
Quartus doesn't compile them.
When you assign "Z" to external pin - Quartus compiles it very well,
thank you.
On the other hand, internal tristate nodes are not supported by Altera
architecture - how would you expect Quartus to synthesize them in this
case? Infer muxes?
Actually MaxplusII had support for converting internal tri-states to
muxes. That feature is removed in Quartus?
|
We never used Altera-provide VHDL or Verilog synthesis on MaxplusII -
only Altera's AHDL or 3rd party synthesis for standard HDLs. So I have
no idea how Altera's synthesis on MaxplussII handled 'Z' - AHDL simply
doesn't have it.
On the other hand, on QuartusII we never ever used 3rd-party VHDL
synthesis tools since Altera's own are good enough. For me, it proves
that VHDL front end was completely redone during M->Q transition. I
vaguely remember reading (on c.a.fpga? ) that they bought a front end
from somebody else.
Does a new synthesis infer muxes for internal 3-state nodes? I don't
know. I nobody here tried to code this way. |
|
| |
|
| Back to top |
krw
Guest
|
| Posted: Fri Aug 29, 2008 5:03 am Post subject: Re: Future architectures [was Re: Intel details future Larra |
|
|
In article <xkrtk.56880$_03.4041@reader1.news.saunalahti.fi>,
kim.enkovaara@iki.fi says...
| Quote: | MooseFET wrote:
On Aug 27, 1:16 pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
Even with FPGAs the code can be quite portable. Usually quite small
...
I have never seen a case of FPGA code going between Xilinx's tools and
Altera's without some very serious rewriting.
Then you have something wrong in your coding style. Normally if some
portability is taken into consideration during design, porting takes
few days to get first impressions. Usually what is needed is some
tweaking of attributes in inferred memories, new clocking scheme
(PLL etc.) and maybe some IO pin instantiations if DDR or very
high speed signaling is used. For some higher level IP (tranceivers,
PCI express etc.) more effort is needed, but that can be handled
by portability layers.
|
Portability is also highly dependent on special features and IP
blocks used. Some can be quite difficult to port. Older
synthesizers didn't infer complex logic functions well so people
relied on IP cores for simple things. There are loads of reasons
designs may be difficult to port, though it's not often necessary
(or considered during design).
| Quote: | With third party synthesizer scripts need only minor changes. And even
with the integrated ones usually some editor tweaking can be used
to get most of the scripts converted. STA is the most painful thing
to convert, that will take some time. But that is only loosely part
of the code, and Synopsys SDC format is gaining ground in FPGA tools
also.
It is quite normal to code the FPGA to support many different chips
and keep the vendors fighting with price to the end and select the
one that was the cheapest
|
You may think it's normal, but I've not seen it actually done. The
project I've been involved with are heavily weighted towards
engineering costs. The cost of the FPGA, while pretty impressive on
the face of it, is peanuts compared to the total system cost.
--
Keith |
|
| |
|
| Back to top |
|
