what is the difference between ALU & FPU
Skillwood
can anyone tell me , what is the difference between an ALU and an FPU
thanks
SKillie
Andrew Reilly
> can anyone tell me , what is the difference between an ALU and an FPU
An ALU is the U that does AL
an FPU is the U that does FP
Simple.
Terje Mathisen
Not _quite_ so simple:
ALU stands for Algorithmic Lisp Unit, i.e. this was the original central
core of the LIPS machine, made for Aritficial Intelligence (AI)
research. It handled if/then/else processing and other algorithmic
decision points.
FPU means Fixed Point Unit, i.e. this was the chip in the LISP machine
that did all integer operations, like plus/minus/and/or etc.
Terje
--
- <Terje.M...@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
Brian Inglis
"Skillwood" <skillwo...@hotmail.com> wrote:
>can anyone tell me , what is the difference between an ALU and an FPU
objects for ALU processing are declared integral number types;
objects for FPU processing are declared real number types
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
--
Brian....@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
fake address use address above to reply
ab...@aol.com tos...@aol.com ab...@att.com ab...@earthlink.com
ab...@hotmail.com ab...@mci.com ab...@msn.com ab...@sprint.com
ab...@yahoo.com ab...@cadvision.com ab...@shaw.ca ab...@telus.com
ab...@ibsystems.com u...@ftc.gov spam traps
glen herrmannsfeldt
"Brian Inglis" <Brian....@SystematicSw.ab.ca> wrote in message
news:n2fs3vka9oj14atms...@4ax.com...
> On Mon, 3 Feb 2003 11:18:53 +0530 in comp.arch.arithmetic,
> "Skillwood" <skillwo...@hotmail.com> wrote:
>
> >can anyone tell me , what is the difference between an ALU and
an FPU
>
> objects for ALU processing are declared integral number types;
> objects for FPU processing are declared real number types
>
> Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
Then where do complex numbers go?
-- glen
Michael S
Ask Google !
Then you would know that ALU stands for "The Association of Lisp
Users" which is pretty different from FPU, i.e. Fukui Prefectural
University.
Rob Warnock
+---------------
| > >can anyone tell me , what is the difference between an ALU and an FPU
| >
| > objects for ALU processing are declared integral number types;
| > objects for FPU processing are declared real number types
|
Well, *duh*! In the CPU, of course!
-Rob
-----
Rob Warnock, PP-ASEL-IA <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Solid Smoke
> Then where do complex numbers go?
>
> -- glen
In the Complex Processing Unit, of course.
Roy Omond
> glen herrmannsfeldt wrote:
> +---------------
> | "Brian Inglis" wrote in message
> | > "Skillwood" wrote:
> | > >can anyone tell me , what is the difference between an ALU and an FPU
> | >
> | > objects for ALU processing are declared integral number types;
> | > objects for FPU processing are declared real number types
> |
> | Then where do complex numbers go?
> +---------------
>
> Well, *duh*! In the CPU, of course!
nah, you're just imagining that they do!
Roy Omond
Blue Bubble Ltd.
Chris Morgan
They have a real part and an imaginary part. The real part is done by
the FPU, and the imaginary part is done in microcode since silicon
can't directly process imaginary numbers.
--
Chris Morgan
"Post posting of policy changes by the boss will result in
real rule revisions that are irreversible"
- anonymous correspondent
Bernd Paysan
>> Then where do complex numbers go?
>
> They have a real part and an imaginary part. The real part is done by
> the FPU, and the imaginary part is done in microcode since silicon
> can't directly process imaginary numbers.
Sure it can. Complex numbers can be represented in 2D, and silicon is also
2D. An imaginary number is just a real number rotated by 90 degree, so to
process complex numbers, you just take the layout of the FPU, duplicate it,
and place it rotated by 90 degrees.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Paul Wallich
Bernd Paysan <bernd....@gmx.de> wrote:
> Chris Morgan wrote:
> >> Then where do complex numbers go?
> >
> > They have a real part and an imaginary part. The real part is done by
> > the FPU, and the imaginary part is done in microcode since silicon
> > can't directly process imaginary numbers.
>
> Sure it can. Complex numbers can be represented in 2D, and silicon is also
> 2D. An imaginary number is just a real number rotated by 90 degree, so to
> process complex numbers, you just take the layout of the FPU, duplicate it,
> and place it rotated by 90 degrees.
That doesn't work on conventional wafer, because the 90-degree rotation
required for processing complex numbers is out of the plane of the
silicon. What you have to do is create a 3-D multiple-die structure in
which each die contains the appropriate cross-section of the FPU used
for processing real numbers. This is called a bitslice processor.
(The unused area on the stacked dice can be used to process
probabilistically related imaginary parts; combined with another set of
dice oriented at 90 degrees to the first two, you have mesoparallel
emulator for quantum computing.)
paul
Stephen Fuld
"Rob Warnock" <rp...@rpw3.org> wrote in message
news:SZGcnYsAgYG...@speakeasy.net...
> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> +---------------
> | "Brian Inglis" <Brian....@SystematicSw.ab.ca> wrote in message
> | > "Skillwood" <skillwo...@hotmail.com> wrote:
> | > >can anyone tell me , what is the difference between an ALU and an FPU
> | >
> | > objects for ALU processing are declared integral number types;
> | > objects for FPU processing are declared real number types
> |
> | Then where do complex numbers go?
> +---------------
>
> Well, *duh*! In the CPU, of course!
Come on guys, Get a CLU. (shame that puns done work as well in print
as verbally)
--
- Stephen Fuld
e-mail address disguised to prevent spam
Keith R. Williams
says...
> Chris Morgan wrote:
> >> Then where do complex numbers go?
> >
> > They have a real part and an imaginary part. The real part is done by
> > the FPU, and the imaginary part is done in microcode since silicon
> > can't directly process imaginary numbers.
>
> Sure it can. Complex numbers can be represented in 2D, and silicon is also
> 2D. An imaginary number is just a real number rotated by 90 degree, so to
> process complex numbers, you just take the layout of the FPU, duplicate it,
> and place it rotated by 90 degrees.
Of course! The iPU. Intel had the imaginary processor part licked as
far back as the in the iA432.
--
Keith
Mike Haertel
> FPU means Fixed Point Unit, i.e. this was the chip in the LISP machine
> that did all integer operations, like plus/minus/and/or etc.
Actually, the point of the FPU on Lisp machines was to find fixed points
of *functions*, i.e. points where X = f(X). This was used in finding solutions
to the Y combinator Yf = f(Yf), essential to implementing recursion.
Thomas
> That doesn't work on conventional wafer, because the 90-degree rotation
> required for processing complex numbers is out of the plane of the
> silicon. What you have to do is create a 3-D multiple-die structure in
> which each die contains the appropriate cross-section of the FPU used
> for processing real numbers. This is called a bitslice processor.
Ah, yes, that's true. But it is possible by not using the usual <100>
orientation, but the <101>, or even more flexible, <111>. The latter allows
overloaded complex (3D) calculations, at a reduction of speed to the third root
of 3 for scalar calculations.
The sqrt(2) reduction in speed for ordinary complex numbers is generally too
much for CPUs, but GPUs (graphic chips) use <101> silicon. Because of that, they
have lower clock speed than a <100> orientation CPU.
Thomas
del cecchi
"Mike Haertel" <mi...@ducky.net> wrote in message
news:slrnb3tgf...@ducky.net...
Clearly that is not correct. The FPU is the FET Processing Unit, which
uses N and P channel Field Effect Transistors to execute the
instructions in a digital format. The ALU is the AnaLog Unit, which
handles continuous variables by using operational amplifiers and
comparators. It is most often implemented with BiPolar Transistors, due
to their better matching and higher gain.
del cecchi
del cecchi
"Keith R. Williams" <k...@attglobal.net> wrote in message
news:MPG.18a87d10e...@enews.newsguy.com...
I worked with some guys that had been part of IBM's first imaginary
processor (no, not the 360/91) FS. Later I got to work on a whole
imaginary system with an imaginary operating system. Fort Knox w/Bach
and Beethoven
So there.
del cecchi
Anne & Lynn Wheeler
> I worked with some guys that had been part of IBM's first imaginary
> processor (no, not the 360/91) FS. Later I got to work on a whole
> imaginary system with an imaginary operating system. Fort Knox w/Bach
> and Beethoven
>
> So there.
>
> del cecchi
but one could claim that the current as/400 is fort knox re-incarnated
and s/38 was FS re-incarnated.
so you might be able to claim that you got to work on both the
imaginary versions and the real(?) versions.
random fs comments:
http://www.garlic.com/~lynn/subtopic.html#futuresys
--
Anne & Lynn Wheeler | ly...@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Paul Wallich
"del cecchi" <dce...@msn.com> wrote:
Of course, the proper codes have to be set in both instruction and data
streams to make this work. For network applications, for example, the
TTL field in a packet describes what kind of circuitry must be used to
process the data. Only if TTL = 0 can the ALU be used.
paul
factory
says...
> I worked with some guys that had been part of IBM's first imaginary
> processor (no, not the 360/91) FS. Later I got to work on a whole
> imaginary system with an imaginary operating system. Fort Knox w/Bach
> and Beethoven
I've heard that Intel's implementation of the x86-64 ISA will be very
quick on imaginary numbers.. or was it that it was based on imagination,
oh I can't remember..
- Factory
Bernd Paysan
>> Sure it can. Complex numbers can be represented in 2D, and silicon is
>> also 2D. An imaginary number is just a real number rotated by 90 degree,
>> so to process complex numbers, you just take the layout of the FPU,
>> duplicate it, and place it rotated by 90 degrees.
>
> Of course! The iPU. Intel had the imaginary processor part licked as
> far back as the in the iA432.
What I forgot to say is that complex operations require to have a CISC, i.e.
a complex instruction set computer. Using RISC (real instruction set
computer) doesn't work.
Keith R. Williams
Actually, I thought about FS just after pushing the send button. I was
hired to work on FS. I did too, for about a nanosecond.
--
Keith
Stan Lackey
"Paul Wallich" <p...@panix.com> wrote in message
news:pw-64CD41.00...@reader1.panix.com...
Duane Rettig
> Andrew Reilly wrote:
> > On Mon, 03 Feb 2003 17:48:53 +1100, Skillwood wrote:
> >
>
> >>can anyone tell me , what is the difference between an ALU and an FPU
> > An ALU is the U that does AL
>
> > an FPU is the U that does FP
> > Simple.
>
>
> Not _quite_ so simple:
>
> ALU stands for Algorithmic Lisp Unit, i.e. this was the original
> central core of the LIPS machine, made for Aritficial Intelligence
> (AI) research. It handled if/then/else processing and other
> algorithmic decision points.
It's even more complicated than that. The above is only from a hardware
perspective. From an organizational perspective, it means Association
of Lisp Users (see http://www.alu.org).
> FPU means Fixed Point Unit, i.e. this was the chip in the LISP machine
> that did all integer operations, like plus/minus/and/or etc.
Again, only from a hardware perspective. It also means Functional
Programming Unit, which is that section in the Lisp Machine Kernel
that does Prolog Emulation.
--
Duane Rettig du...@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
del cecchi
"Stan Lackey" <stanl...@hotmail.com> wrote in message
news:v41aipn...@corp.supernews.com...
> You folks had better stick with your day jobs. -Stan
>
> "Paul Wallich" <p...@panix.com> wrote in message
> > "del cecchi" <dce...@msn.com> wrote:
> >
> > > "Mike Haertel" <mi...@ducky.net> wrote in message
> > > > > In article <b1lcnc$ib3$1...@vkhdsu24.hda.hydro.com>, Terje
Mathisen
snip to avoid chastisement. :-)
>
>
Dennis M O'Connor
> You folks had better stick with your day jobs. -Stan
My day job is as a computer architect for the world's
largest semiconductor manufacturer. A few others here,
including some in this thread, are similarly employed.
And then there's Nick, who isn't. :-P
--
Dennis M. O'Connor dm...@primenet.com
"We don't become a rabid dog to destroy a rabid dog,
but we do get a bit rude."
Toon Moene
> "Stan Lackey" <stanl...@hotmail.com> wrote ...
>
>>You folks had better stick with your day jobs. -Stan
>
>
> My day job is as a computer architect for the world's
> largest semiconductor manufacturer. A few others here,
> including some in this thread, are similarly employed.
>
> And then there's Nick, who isn't. :-P
Don't take Dennis too seriously :-)
There are also those listening in who are just here to be up to date on
CPU architecture because we do not want to depend on brochureware from
vendors.
There was a posting to comp.lang.fortran a couple of weeks ago -
inspired by a "my language is bigger than yours" cross-posting from
either comp.lang.c or comp.lang.c++ - by someone who showed that his
group was responsible for ~ 1.0e6 hours of CPU time (in Fortran) yearly.
I countered that the Dutch Weather service didn't get any farther than
about 2.0e5 hours ...
--
Toon Moene - mailto:to...@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc-g95.sourceforge.net/ (under construction)
Terje Mathisen
> There was a posting to comp.lang.fortran a couple of weeks ago -
> inspired by a "my language is bigger than yours" cross-posting from
> either comp.lang.c or comp.lang.c++ - by someone who showed that his
> group was responsible for ~ 1.0e6 hours of CPU time (in Fortran) yearly.
>
> I countered that the Dutch Weather service didn't get any farther than
> about 2.0e5 hours ...
That shouhld be easy to beat: Just use a language/compiler combination
which is half as effective as yours, then we'd require 2e6 cpu hours for
the same calculations!
Terje
--
- <Terje.M...@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
Rupert Pigott
news:b21659$s4f$1...@vkhdsu24.hda.hydro.com...
> Toon Moene wrote:
> > There was a posting to comp.lang.fortran a couple of weeks ago -
> > inspired by a "my language is bigger than yours" cross-posting from
> > either comp.lang.c or comp.lang.c++ - by someone who showed that his
> > group was responsible for ~ 1.0e6 hours of CPU time (in Fortran) yearly.
> >
> > I countered that the Dutch Weather service didn't get any farther than
> > about 2.0e5 hours ...
>
> That shouhld be easy to beat: Just use a language/compiler combination
> which is half as effective as yours, then we'd require 2e6 cpu hours for
> the same calculations!
-g -O0
:)
Cheers,
Rupert
Toon Moene
> Toon Moene wrote:
>> I countered that the Dutch Weather service didn't get any farther than
>> about 2.0e5 hours ...
> That shouhld be easy to beat: Just use a language/compiler combination
> which is half as effective as yours, then we'd require 2e6 cpu hours for
> the same calculations!
Oh, and we don't have to match certain wall-clock time limits ?
Remember, this is weather _fore_casting, not seti@home :-)
Peter Dickerson
news:3E44FD98...@moene.indiv.nluug.nl...
seti@home has a deadline too - before they arrive. :)
Peter
Jouni Osmala
> can anyone tell me , what is the difference between an ALU and an FPU
> SKillie
Following definition is my personal opinion how I see the facts, and
many around here may disagree with some details, which may open a nice
discussion. But I believe EVERY statement I put here is TRUE.
Any FPU operation can be done by ALU, and ALU is cheaper than FPU.
ALU is necessity, while FPU is helping those who cannot make really
fast ALU:s and scheduler to handle the task. FPU sits idle quite often
but when its needed its work couldn't be done with average ALU:s. You
need superior architecture to handle anything that requires FPU tasks
with only ALU:s but its reasonable design decision IF you do your
research properly. If your imagination is cripled by box defined in
80's or 70's, you are probably out of luck, since FPU is something you
must do because you cannot have fast enough ALU system to handle the
specialised task of FPU.
Jouni Osmala
Helsinki University of Technology.
Electrical Engineering
Alex Colvin
workstation processors and a few DSPs have an FPU.
--
mac the naïf
Chris Morgan
> seti@home has a deadline too - before they arrive. :)
Shh!, or a sizeable portion of potential cycle donators wont bother,
as they believe aliens already did arrive and are living in Area 51,
no doubt with Elvis
Gavin Scott
> "Terje Mathisen" <terje.m...@hda.hydro.com> wrote in message
> news:b21659$s4f$1...@vkhdsu24.hda.hydro.com...
>>
>> which is half as effective as yours, then we'd require 2e6 cpu hours for
>> the same calculations!
> -g -O0
Now this has me wondering if anyone has ever abused profile-based
optimization by altering the collected sample data in order to get
the compiler to produce the *worst* code possible.
Sounds like a useful compiler test, so I'm sure someone has probably
tried it.
G.
Peter Boyle
On Mon, 10 Feb 2003, Alex Colvin wrote:
> Most embedded processors do not have an FPU. Only general-purpose
> workstation processors and a few DSPs have an FPU.
Many embedded cpus do now have FPU's. There's hordes of mips variants,
some powerpc embedded variants do, while certainly many embedded PPC's do
not.
You could argue that many of these parts were long ago workstation
targetted and have shifted their focus to the embedded market, but
they _are_ now embedded chips.
Peter
> --
> mac the naïf
>
Terje Mathisen
> Rupert Pigott <r...@dark-try-removing-this-boong.demon.co.uk> wrote:
>
>>"Terje Mathisen" <terje.m...@hda.hydro.com> wrote in message
>>news:b21659$s4f$1...@vkhdsu24.hda.hydro.com...
>>
>>>That shouhld be easy to beat: Just use a language/compiler combination
>>>which is half as effective as yours, then we'd require 2e6 cpu hours for
>>>the same calculations!
>
>
>>-g -O0
>
>
> Now this has me wondering if anyone has ever abused profile-based
> optimization by altering the collected sample data in order to get
> the compiler to produce the *worst* code possible.
On an OoO cpu, this would be quite hard to do:
What can you really hope for that's going to be worse than non-optimized
code?
IF-conversion of easily predictable branches, with long stretches of
conditionally executed code?
Massive unrolling and inlining of seldomly used functions, to blow out
the code cache?
Flagging all index variables as 'volatile'? This would probably do it,
but would require source code modifications as well, afaik.
> Sounds like a useful compiler test, so I'm sure someone has probably
> tried it.
Possibly not. If they have, it would be interesting to see how they did.
Alex Colvin
>> workstation processors and a few DSPs have an FPU.
>Many embedded cpus do now have FPU's. There's hordes of mips variants,
>some powerpc embedded variants do, while certainly many embedded PPC's do
>not.
I'm thinking of the CPUs in television remote controls, battery chargers,
keyboards, radios, etc. And I meant most by part count, not by model
count.
>You could argue that many of these parts were long ago workstation
>targetted and have shifted their focus to the embedded market, but
>they _are_ now embedded chips.
OK, I'll argue that.
It's true that FPUs have made their way down the food chain, along with
MMUs.
--
mac the naïf
Gavin Scott
> Gavin Scott wrote:
>> Now this has me wondering if anyone has ever abused profile-based
>> optimization by altering the collected sample data in order to get
>> the compiler to produce the *worst* code possible.
> What can you really hope for that's going to be worse than non-optimized
> code?
Well, I was thinking of statically predicting every branch the wrong
way or something similar, but yeah, what is it with compilers these
days? It seems like unoptimized code generation is getting worse at
about the same rate that optimized code is getting better. Try the
PA C compiler in 64-bit (wide) mode without optimization. The result
looks like it came straight from the department of redundancy department.
G.
Jouni Osmala
> > workstation processors and a few DSPs have an FPU.
>
> Many embedded cpus do now have FPU's. There's hordes of mips variants,
> some powerpc embedded variants do, while certainly many embedded PPC's do
> not.
>
> You could argue that many of these parts were long ago workstation
> targetted and have shifted their focus to the embedded market, but
This how they are, but the real issue with having FPU:is that with a
die size of inorder single issue CPU with decent FPU, is about same
as, OOE quad issue CPU with 4 64bit ALU:s running at high frequency.
This assumes ISA was optimized for multi Issue OOE execution. AXP most
certainly is not that, it just don't make doing that any harder, but
it doesn't help it either.
hack
Gavin Scott <ga...@allegro.com> wrote:
>Terje Mathisen <terje.m...@hda.hydro.com> wrote:
>> Gavin Scott wrote:
>>> Now this has me wondering if anyone has ever abused profile-based
>>> optimization by altering the collected sample data in order to get
>>> the compiler to produce the *worst* code possible.
Rumor has it that, a long time ago (40 years?), some compiler did use
branch hints -- and that it took 10 years before somebody realised they
were being set exactly the WRONG way!
Michel.
Peter Boyle
On 11 Feb 2003, Jouni Osmala wrote:
> > Many embedded cpus do now have FPU's. There's hordes of mips variants,
> > some powerpc embedded variants do, while certainly many embedded PPC's do
> > not.
> >
> > You could argue that many of these parts were long ago workstation
> > targetted and have shifted their focus to the embedded market, but
> > they are now embedded chips.
>
> This how they are, but the real issue with having FPU:is that with a
> die size of inorder single issue CPU with decent FPU, is about same
> as, OOE quad issue CPU with 4 64bit ALU:s running at high frequency.
> This assumes ISA was optimized for multi Issue OOE execution. AXP most
> certainly is not that, it just don't make doing that any harder, but
> it doesn't help it either.
So what? It is the real issue only if you are tight for a few mm^2
of die space at .18u, or even less area on newer processes.
I could start listing IBM/Moto/Mips SOC embedded chips some with and some
without without fpu's which integrate:
Multiple ethernet controllers,
PCI controllers,
Memory controllers
L2 Cache.
On-chip busses.
UARTS,
DMA's and more.
These guys are not overly space constrained on the scale of an FPU, some
of them are already dual-issue OoO chips. I would guess power consumption
is probably more of a constraint regarding wider OoO implementations, c.f. the
Broadcom/SiByte decision to go in-order, two core, quad issue.
Peter
Jouni Osmala
> > die size of inorder single issue CPU with decent FPU, is about same
> > as, OOE quad issue CPU with 4 64bit ALU:s running at high frequency.
> > This assumes ISA was optimized for multi Issue OOE execution. AXP most
> > certainly is not that, it just don't make doing that any harder, but
> > it doesn't help it either.
>
> So what? It is the real issue only if you are tight for a few mm^2
> of die space at .18u, or even less area on newer processes.
> I could start listing IBM/Moto/Mips SOC embedded chips some with and some
> without without fpu's which integrate:
>
> Multiple ethernet controllers,
> PCI controllers,
> Memory controllers
> L2 Cache.
> On-chip busses.
> UARTS,
> DMA's and more.
>
> These guys are not overly space constrained on the scale of an FPU, some
> of them are already dual-issue OoO chips. I would guess power consumption
> is probably more of a constraint regarding wider OoO implementations, c.f. the
> Broadcom/SiByte decision to go in-order, two core, quad issue.
>
> Peter
Uhh perhaps my stance was a bit perverted on a study/hobby project of
getting maximum general purpose computing performance with 275k
transistor budget, with future proof design and 32bit wide bus
interface.
Current stand is 64bit quad issue OOE with TLB memory protection. It
has some design tradeoffs are a bit uncontional and strange, but I
have hard limit that I'm going to follow. But givin up floating point
was mainly due the fact that FPU inst take very few % of executed
instructions on wide variety of apps, even those who use FPU,
improving integer should handle those better. And probably for
anything related to arrays it would saturate the FSB anyway.
This project comes 20 years too late, but is interesting learning
scenario for me. The ISA was designed in such way that adding FPU
there later generations should be easy...
Jouni Osmala
Helsinki University.
Electrical Engineering
-ps. I know that transitor count may be lame limit, instead of die
size, but laying out the chip should be another project. Just to get
it in my studies.
Jan C. Vorbrüggen
> branch hints -- and that it took 10 years before somebody realised they
> were being set exactly the WRONG way!
I believe an early version of Fortran from IBM had that feature, and the
code generator indeed had the bug mention.
Jan
Paul Repacholi
> seti@home has a deadline too - before they arrive. :)
Yes, but all the plans are in place to amend it to "Before they
leave.". There is also a secret backup to add "again" for issue
three. :)
--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
comp.os.vms,- The Older, Grumpier Slashdot
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.