Yikes Clifford! Interdata 8/32? The machine where running the selector channel corrupted division results due to microcode bugs? And where the backplane used inconsistent power pins, and an unkeyed extender board caused IC tops to fly like popcorn during careless maintenance? In 1975? Oh, the memories!
... I'm afraid proving we're getting a bit ancient...
Apparently I'm not quite that ancient. The port was done mostly by post-graduate students in 1979 I believe, but I graduated the next year. I dropped my "compilers" unit because I didn't need the points, it had a
3000-word essay on parsing theory, was I having too much fun porting the Ritchie C compiler to the Interdata 7/16. Later Perkin Elmer, of course... UniMelb had one that ran up to eight trains on a train-set, with RS232 datacomms superimposed on a 200KHz carrier through the power rails. I also dropped databases... which is funny because I've spent most of my career building languages and database technology. My theory now is that they are boring on the outside precisely because they're so fascinating on the inside.
IIRC from 40 years ago, the 8/32 was a slightly-enhanced 7/32, but I don't remember the difference. I remember colleagues trying to convince engineers from Perkin-Elmer to add MMU and paging support, to which the Perkin-Elmer guys said "Paging? that went out with the PDP-8!". I last saw one in 1975, as I was running faster than it was...
Does your customer system have MS Visual Studio compilers and at least debugger installed?
Could you arrange a Telnet/Remote Desktop access to their system ?
Try to arrange that with your customer.
Telnet/Remote desktop is your friend if the customer system is well supported.
If you can remotely compile your program at your customer's site and tools, please do that.
I just discussed a similar problem with one of my collages, who had to install several versions of MSVC compilers and find out required compiler switches (including stack frame issues) before getting things to work somehow together. If you are trying to get programs and DLLs from different vendors to work together, you have a much worse problems.
If you have fatal problems between parameter passing etc. other incompatible issues, just use some primitive stubs at the main program and use a separate process for your library.
The stub in the main program could then send e.g. UDP frames to a separate library main program, which then calls the actual library functions and then returns the result through an other UDP port.
Since the socket interface is these days more or less universal, it is easy to add a UDP silent into your main program and use a separate UDP server as the main program, which calls your specific library functions.
I have used this technique several times during the last three decades to handle incompatible run time systems.
I was thinking of doing something like your UDP suggestion. If Labview provides a mechanism for doing it without even interfacing with a DLL I may go there -- I'll have to see what NI says about it.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
1) If you mean UDP to a customer site 14 hours away by air, you probably better use TCP to not get further confused by lost packets. Visual Studio may supply some convenient drag and drop tools for this TCP wrapping, using what used to be called Windows Automation interfaces. Labview might also support that. I used Automation in the distant past but I'm way behind the times about how it's done now.
2) This doesn't sound like a calling format issue though, since the customer's installation works most of the time.
The 7/16 was a 16-bit machine, obviously. We learned low-level assembly language programming on it - and that train set sure could produce a lot of interrupts - every current spike from the wheels of eight locos rolling along any of the 30-ish segments of track. It was amazing that the low-priority (non-interrupt) code got anything done.
I think I used a 7/32 to write some microcode for fast graphics; we had a home-brew memory-mapped color display (super-high-tech for 1975). This was at the Architecture Machine Group, shortly after renamed the MIT Media Lab, working for Nicholas Negroponte, before I moved over to Project MAC (Laboratory for Computer Science).
The point was to run LabView and a separate application process in the customer's embedded machine and these would communicate with each other within that machine using UDP.
Then you use Remote Desktop or Telnet to communicate with that embedded system from the other side of the world.
On rare occasion i have seen weird results. Like - producing what is technically minus zero, and depending on the environment, it can act as a true zero or can make a program go t*ts up. Gotta look at the binary results to find that negative zero...
Doing fpvar1-fpvar2 when they are nearly but exactly as big will cause a lot of problems. There might be very few significant bits (perhaps only one) and the rounding/truncating mode might make things worse.
Result = BigMultiplier * (fpvar1-fpvar2) ;
Might give different results compared to
SmallDiff = fpvar1-fpvar2 ; /* Some other instructions */ Result = BigMultiplier * SmallDiff ;
Especially if the first example is executed on the x87 80 bit stack and then rounded or the latter with 32 bit SIMD instructions only.
Make sure you have proper divide by zero trapping also for 1/-0.
Also check that you handle NaN (Not a Number) cases properly.
You should try to rearrange your algorithms to avoid fpvar1 - fpvar2 cases in which both are nearly equal.
If you accept IEEE floating values from some external device (such as PLC), at entry to your system, check for NaN,+/-INF and non-normalzed values and handle it properly, before letting it go deep into your calculations, causing havoc like NaN * -INF calculations.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.