On Sunday, October 11, 2015 at 7:05:13 PM UTC-4, Clifford Heath wrote:> The first (and only) thing that the Interdata 8/32 (big-endian) port said?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... See ya, Dave
Same code, same data, different results
Started by ●October 6, 2015
Reply by ●October 11, 20152015-10-11
Reply by ●October 12, 20152015-10-12
On 12/10/15 11:54, Dave Nadler wrote:> On Sunday, October 11, 2015 at 7:05:13 PM UTC-4, Clifford Heath wrote: >> The first (and only) thing that the Interdata 8/32 (big-endian) port said? > > 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. Clifford Heath.
Reply by ●October 12, 20152015-10-12
On 10/10/15 01:40, Paul Rubin wrote:> You can get a Windows remote desktop (not a super powerful one) for 3 > months for free here: https://www.runabove.com/deskaas.xml > > There are also tons of commercial providers who rent stuff like that for > a few cents an hour. I guess that doesn't help with Labview, but can't > you mock that out?Microsoft will give you a VirtualBox virtual machine for nothing, limited for 90 days. https://dev.modern.ie/tools/vms/windows/ I have an XP virtual machine which I use for this sort of thing. Andy
Reply by ●October 12, 20152015-10-12
Dave Nadler <drn@nadler.com> wrote:> On Sunday, October 11, 2015 at 7:05:13 PM UTC-4, Clifford Heath wrote: >> The first (and only) thing that the Interdata 8/32 (big-endian) port said?> 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!Is the 7/32 the same? When did you last see one run? -- glen
Reply by ●October 12, 20152015-10-12
On Monday, October 12, 2015 at 4:13:46 AM UTC-4, glen herrmannsfeldt wrote:> Dave Nadler wrote: > > On Sunday, October 11, 2015 at 7:05:13 PM UTC-4, Clifford Heath wrote: > >> The first (and only) thing that the Interdata 8/32 (big-endian) port said? > > > 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! > > Is the 7/32 the same? > When did you last see one run?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
Reply by ●October 12, 20152015-10-12
On Fri, 09 Oct 2015 18:22:47 -0500, Tim Wescott <seemywebsite@myfooter.really> wrote:>On Sat, 10 Oct 2015 01:08:11 +0300, upsidedown wrote: > >> On Tue, 06 Oct 2015 19:35:13 -0500, Tim Wescott >> <seemywebsite@myfooter.really> wrote: >> >>>This is about code that clings to "embedded" by it's fingernails -- it's >>>running on a fast PC-compatible single-board computer, under Windows, as >>>a DLL. So it's not exactly some little thing shoehorned into 4kB of >>>flash. >>> >>>At any rate: >>> >>>I have a rather complicated algorithm that I've coded up, to do >>>marvelous stuff for my customer. It recently grew quite a bit, and in >>>the process I've introduced some subtle bugs. I'm looking for ideas on >>>things to look for to see if I can figure out what's going on. >>> >>>Here's the deal: >>> >>>First, some time this spring I got a shiny new machine, and went ahead >>>and loaded 64-bit Linux onto it, with all its 64-bit appurtenances. >>>This did not, at the time, cause problems. >>> >>>I coded up a bunch of changes, tested it on my 64-bit machine, and >>>happily shipped it off to my customer -- who reported that it broke, >>>horribly. >>> >>>Oh drat. On top of this, at some point the MinGW stream library broke, >>>so my test code no longer worked under Wine -- I could only test with >>>the Linux version. >>> >>>After much trial and tribulation, I managed to get Linux 32 and 64-bit >>>versions, and Windows 32-bit versions all working. I tracked down my >>>problems (size_t and unsigned int are not the same size in gcc 64 bit >>>for Linux), fixed them, and shipped. >>> >>>So now I'm getting four different results from three different software >>>loads and two different circumstances. I can't go into detail, but I'm >>>going to give a general story 'cause I'm looking for general things to >>>look for: >>> >>>Under Linux 32-bit I get behavior A (correct operation) >>> >>>Under Linux 64-bit I get behavior B (correct operation, just different) >>> >>>Under Wine running a 32-bit Windows program I get behavior B >>> >>>My customer calls my DLL from Labview. Nine times out of ten he gets >>>some correct behavior -- he's not sophisticated enough that I can know >>>whether it's A, B or something else. The tenth time the thing fails to >>>work correctly. >> >> Does it crash every 10th time you run it with the same parameters or >> what ? > >On average, yes. > >> Anyway, if the fatal problems occurs on some Windows machine (desktop or >> embedded Windows ?) why do you insist on using Linux or some Windows >> emulator on Linux to try to figure out what is wrong in a Windows system >> ? > >Because I don't have any spare pots of money lying around with which to >buy a new machine, Labview, and Windows. >It may come to that, but I'd rather avoid the expense.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.>> If you can't get exactly the same configuration, at least use some >> native Windows version on your own test machine. >> >> Using different versions of MS compilers and you can end up in problem. >> If the .EXE and .DLL are compiled with a different version of the >> compiler, you may encounter problems, such as when allocating dynamic >> memory in .exe and freeing in it .dll. > >We are not there, thankfully.Telnet/Remote desktop is your friend if the customer system is well supported.>> You should find out at what compiler (and version) the LabView has been >> compiled with and preferably use the same compiler (with same version >> and settings) for compiling your DLL. We have had lots of problems due >> to different compiler versions settings. > >Thank you, no, I am not a Microsoft shop. If it comes to that I'll send >them code for them to compile.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.
Reply by ●October 12, 20152015-10-12
On Mon, 12 Oct 2015 23:53:13 +0300, upsidedown wrote:> On Fri, 09 Oct 2015 18:22:47 -0500, Tim Wescott > <seemywebsite@myfooter.really> wrote: > >>On Sat, 10 Oct 2015 01:08:11 +0300, upsidedown wrote: >> >>> On Tue, 06 Oct 2015 19:35:13 -0500, Tim Wescott >>> <seemywebsite@myfooter.really> wrote: >>> >>>>This is about code that clings to "embedded" by it's fingernails -- >>>>it's running on a fast PC-compatible single-board computer, under >>>>Windows, as a DLL. So it's not exactly some little thing shoehorned >>>>into 4kB of flash. >>>> >>>>At any rate: >>>> >>>>I have a rather complicated algorithm that I've coded up, to do >>>>marvelous stuff for my customer. It recently grew quite a bit, and in >>>>the process I've introduced some subtle bugs. I'm looking for ideas >>>>on things to look for to see if I can figure out what's going on. >>>> >>>>Here's the deal: >>>> >>>>First, some time this spring I got a shiny new machine, and went ahead >>>>and loaded 64-bit Linux onto it, with all its 64-bit appurtenances. >>>>This did not, at the time, cause problems. >>>> >>>>I coded up a bunch of changes, tested it on my 64-bit machine, and >>>>happily shipped it off to my customer -- who reported that it broke, >>>>horribly. >>>> >>>>Oh drat. On top of this, at some point the MinGW stream library >>>>broke, so my test code no longer worked under Wine -- I could only >>>>test with the Linux version. >>>> >>>>After much trial and tribulation, I managed to get Linux 32 and 64-bit >>>>versions, and Windows 32-bit versions all working. I tracked down my >>>>problems (size_t and unsigned int are not the same size in gcc 64 bit >>>>for Linux), fixed them, and shipped. >>>> >>>>So now I'm getting four different results from three different >>>>software loads and two different circumstances. I can't go into >>>>detail, but I'm going to give a general story 'cause I'm looking for >>>>general things to look for: >>>> >>>>Under Linux 32-bit I get behavior A (correct operation) >>>> >>>>Under Linux 64-bit I get behavior B (correct operation, just >>>>different) >>>> >>>>Under Wine running a 32-bit Windows program I get behavior B >>>> >>>>My customer calls my DLL from Labview. Nine times out of ten he gets >>>>some correct behavior -- he's not sophisticated enough that I can know >>>>whether it's A, B or something else. The tenth time the thing fails >>>>to work correctly. >>> >>> Does it crash every 10th time you run it with the same parameters or >>> what ? >> >>On average, yes. >> >>> Anyway, if the fatal problems occurs on some Windows machine (desktop >>> or embedded Windows ?) why do you insist on using Linux or some >>> Windows emulator on Linux to try to figure out what is wrong in a >>> Windows system ? >> >>Because I don't have any spare pots of money lying around with which to >>buy a new machine, Labview, and Windows. >>It may come to that, but I'd rather avoid the expense. > > 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. > >>> If you can't get exactly the same configuration, at least use some >>> native Windows version on your own test machine. >>> >>> Using different versions of MS compilers and you can end up in >>> problem. If the .EXE and .DLL are compiled with a different version of >>> the compiler, you may encounter problems, such as when allocating >>> dynamic memory in .exe and freeing in it .dll. >> >>We are not there, thankfully. > > Telnet/Remote desktop is your friend if the customer system is well > supported. > >>> You should find out at what compiler (and version) the LabView has >>> been compiled with and preferably use the same compiler (with same >>> version and settings) for compiling your DLL. We have had lots of >>> problems due to different compiler versions settings. >> >>Thank you, no, I am not a Microsoft shop. If it comes to that I'll send >>them code for them to compile. > > 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
Reply by ●October 12, 20152015-10-12
Tim Wescott <seemywebsite@myfooter.really> writes:> 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.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.
Reply by ●October 12, 20152015-10-12
On Monday, October 12, 2015 at 6:24:06 PM UTC-4, Tim Wescott wrote:> 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.What guidance does NI give about toolchain for DLLs ?
Reply by ●October 12, 20152015-10-12
On 12/10/15 23:55, Dave Nadler wrote:> I last saw one in 1975, as I was running faster than it was...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.
