Same code, same data, different results

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.

Clifford Heath.

Microsoft will give you a VirtualBox virtual machine for nothing, limited for 90 days.

I have an XP virtual machine which I use for this sort of thing.

Andy

Is the 7/32 the same?

When did you last see one run?

-- glen

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...

See ya, Dave

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.

What guidance does NI give about toolchain for DLLs ?

It was running, but you saw it coming ;)

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.

Oh, probably not.

If that's what I think it is, it bit me - hard - last year.

--
Les Cargill

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).

40+ years ago! Yikes...

(snip on the Interdata 8/32, then I wrote)`

I saw one last month.

Anyone remember Unix from before the cd command, when you had to chdir, instead? (and before alias)

-- glen

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.