| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 448.1 | | TURRIS::lspace.zko.dec.com::winalski | PLIT Happens... | Fri Jan 17 1997 10:37 | 17 |
| 448.2 | | BHAJEE::JAERVINEN | Ora, the Old Rural Amateur | Fri Jan 17 1997 11:55 | 8 |
| 448.3 | Sorry | CIVPR1::valb01.cop.dec.com::Dale_White | | Fri Jan 17 1997 13:18 | 10 |
| 448.4 | Supporting C code on intel and alpha? | BIGCHZ::EZZELL | Mike Ezzell | Thu Jan 30 1997 17:00 | 18 |
|
> 3) There are significant differences between the Alpha and Intel
> compilers and thus the two products often have different sets of
> bugs. Fixes for the Intel version aren't necessarily relevant to the
> Alpha version and vice versa. Bug fixes, point releases, etc.
> may appear at different times for Intel and Alpha.
I had a customer tell me today that it has been 8 months since
the last version of Microsoft C for Alpha and there has been 3-4
Intel versions in that time period. This seems to jive with 3).
My customer's take on this was that the alpha version was not
up to date with the intel version and this makes it difficult
to support an application on both intel and alpha. They also
said that there was more to moving intel C code from Intel to
Alpha was more complex that simply recompiling. Could someone
help me understand the differences?
|
| 448.5 | | BIGUN::nessus.cao.dec.com::Mayne | Wake up, time to die | Fri Jan 31 1997 01:48 | 20 |
| Time between releases doesn't necessarily jive with 3) at all.
Suppose there's a bug in the x86 compiler such that a variable is stored in the
wrong CPU register. Microsoft have to produce a fix for this, but this bug has
absolutely nothing to do with the Alpha compiler: they're two entirely different
pieces of code. (Yes, I know that's not necessarily true, but I'm trying to make
a point. 8-)
If you read through other notes here, you'll find out how to map x86 point
releases to Alpha "patches".
What kind of code are they writing? I've written code on Alpha and compiled it
with zero changes on x86 and vice versa with zero changes as well (and unlike
UNIX, you won't find any ifdefs that just swap large chunks of code in and out).
I'll quite happily stand up and say "it *is* as simple as simply recompiling",
given that I don't write drivers and such.
Why do they think it's more complicated?
PJDM
|
| 448.6 | | 8153::tecotoo.mro.dec.com::mayer | Danny Mayer | Fri Jan 31 1997 09:47 | 12 |
| > My customer's take on this was that the alpha version was not
> up to date with the intel version and this makes it difficult
> to support an application on both intel and alpha. They also
> said that there was more to moving intel C code from Intel to
> Alpha was more complex that simply recompiling. Could someone
> help me understand the differences?
If this is true, then the chances are that their code is poorly
written. Unfortunately, you may have a hard time telling a customer
this. Properly written code should compile just fine.
Danny
|
| 448.7 | | DECWET::KOWALSKI | Time's not for saving | Fri Jan 31 1997 11:19 | 13 |
| My experience has been that the Alpha compiler catches
some interface problems that the Intel compiler doesn't.
For example, Intel will let this through while
Alpha warns you about the interface mismatch:
class Stuff
{
public:
Stuff(int, int, const CString&);
}
Stuff *pThing = new Stuff(1, 1, 0.);
|
| 448.8 | | BGSDEV::MORRIS | Tom Morris - Light & Sound Engineering | Fri Jan 31 1997 15:33 | 8 |
| I saw a report the other day that Microsoft will be dropping their
Visual C++ subscription services because, among other reasons,
developers didn't like the risk of upgrading several times a year.
Anyone know if this has been announced officially? It would certainly
help with the parity of releases issue.
Tom
|
| 448.9 | example, simple re-compile | MUCTEC::BECKER | Hartmut B., VMS & Languages, Munich | Mon Feb 03 1997 04:39 | 9 |
| Last year a partner came in in our walk in lab. He brought his input tablet and
an Intel version of his driver for this device. He compiled his sources on our
Alpha, no problem. Then he tried to install. One of the installation routines
supplied with VC++ failed. Debbuging the installation to find out if it was his
or our fault always ended in a hanging debugger. He changed his code not to
call our function. He re-compiled, installed, re-bootet and testet. It simply
worked. To say it more fashionable: pretty cool.
Hartmut
|
| 448.10 | It's getting better, and will continue to get better | DECWET::PETERSON | | Wed Feb 05 1997 14:05 | 22 |
| re .4
technically, the customer is right because there is no subscription
release for ALPHA. However, we have worked with Microsoft to provide
customers with equivalent releases that are technically patches.
Here is how the last year went:
10/95 - Intel VC V4.0
11/95 - Alpha VC V4.0
2/96 - Intel VC V4.1
3/96 - Intel VC41A (Intel patch)
4/96 - Alpha VC40A (new kit which included VC V4.1 and VC41A -
distributed as a patch)
6/96 - Intel VC V4.2
8/96 - Intel VC42A and VC42B (Intel patches - 42B fixed problems in 42A)
11/96 - Alpha VC42B (new kit which include VC V4.2 and VC42B, and
distributed as a patch)
VC V5.0 will be delivered on both Intel and Alpha in 1997
re .8
I believe it will be announced when Microsoft announces VC V5.0
in another month.
|