| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 491.1 | | DECWET::VOBA | | Tue Apr 08 1997 00:17 | 6 |
| Re .0, don't quite understand your questions... The latest/greatest
VC++ 5.0 is available on both Intel and Alpha NT. Is the numeric
identification what your questions were about? Or were you thinking
about something else?
--svb
|
| 491.2 | that was then, V5 is NOW! | HYDRA::SCHAFER | Mark Schafer, SPE MRO | Wed Apr 09 1997 13:49 | 1 |
| see 462.1
|
| 491.3 | All we need to do is make sure we keep talking (P.F.) | MQOOA::ras022p01.mqo.dec.com::courchesne | Bon renom et loyaut� | Wed Apr 09 1997 14:37 | 37 |
| RE: .1
My question is from an uninformed person.
I appreciate the clarification that the latest version is functionnaly
equivalent on both Alpha and Intel.
I suppose that:
- The code is the same on Alpha and Intel
- The program, when it runs, will act the same
- The library and system call have the same functionnality
- No modification is needed to the code from one platform to the other
Can I assume?:
- The binary code (.EXE) file needs to be different on each platform
- I'll need to recompile on each platform
- Once i've recompiled, I just execute withour any problems?
I'll be meeting with a customer that seems to have encountered some
differences between code generated on Intel and brought afterward to an Alpha
platform. I'm trying to anticipate the questions he'll have for ma and I'm
trying to find answers before I meet.
Wouls someone be willing to casually talk with me friday afternoon, 14h15EDT
(Eastern daylight saving time zone) to chat about the issues facing a
multiplatform development team.
DTN: 632-6365
Outside (514) 856-6365
Thanks a million
Andre J. Courchesne
Technical sales support
Digital Montreal
|
| 491.4 | | DECWET::VOBA | | Fri Apr 11 1997 01:10 | 29 |
| Re .3,
Re your suppositions:
The developed C++ code can be identical for Alpha and Intel, provided
it is user application level codes. Kernel codes are not (if someone
decides to use the IDE to develop device drivers, for example).
The program, when it runs should act the same, provided there have been
no special cases between Intel and Alpha and provided no bad
assumptions about data types.
Win32, et al. have the same functionality.
No modification needed to the code from one platform to the other,
provided the code was not already skewed to take advantage of one
platform at the expense of the other.
Re your assumptions:
The resultant (compiled & linked) binary code are different on each
platform. Intel and Alpha are not binary compatible. You'll need to
recompile for each platform.
You should be able to look up the phone numbers and call any one of the
moderators of this conference. They are all members of the VC++ team
at DECwest.
--svb
|
| 491.5 | | DECCXL::OUELLETTE | temerity time | Fri Apr 11 1997 09:54 | 5 |
| > moderators of this conference. They are all members of the VC++ team
> at DECwest.
Mmmm. Sort of. I'm not on the project anymore & I was never permanantly
located at DEC West (though it sometimes felt that way).
|
| 491.6 | Thanks Kim | MQOOA::dhcp006.mqo.dec.com::courchesne | Bon renom et loyaut� | Fri Apr 11 1997 09:59 | 6 |
| Kim Peterson agreed to help me out by Phone
Thanks Kim
I'll be calling
Andre J. Courchesne
|
| 491.7 | | RLTIME::COOK | | Tue Apr 15 1997 10:59 | 10 |
|
> No modification needed to the code from one platform to the other,
> provided the code was not already skewed to take advantage of one
> platform at the expense of the other.
There are only two platforms, intel or alpha.
Can you give some examples of something someone would normally do to take
advantage on an intel platform?
|
| 491.8 | a couple examples | DECCXL::OUELLETTE | temerity time | Tue Apr 15 1997 11:34 | 18 |
| Carefully crafted inline assembler code #ifdef'd for _M_IX66
with naive code in the #else case would be one way of stacking the deck.
Another would be excesive use of #pragma pack or /Zp, especially
if there were coding bugs which cause runtime fixups of alignment faults.
A third problem could occur when uninitialized floating point variables
are used in computation; -QAieee may be required to make these work
since a floating point trap handler needs to be invoked for some values.
A fourth problem comes with bad use of exception handling and/or setjmp
and longjmp... Exceptional code is not supposed to be a high performance
means of computing, and if you try to make it so x86 will appear better
than Alpha [Moral: don't throw a normal return value.]
The last three examples, I consider to be unnatural acts.
Hand crafted assembler is the only one that should "normally" show up...
well, maybe packed data is normal in the PC world where every byte is sacred,
but that should be able to run free of alignment faults (which are a symptom
of bugs in the source code), if somewhat more slowly than naturally aligned
data.
|