Labviewguru et. al:
FIRST LET ME SAY THAT I DO NOT WORK FOR NI AND NEVER HAVE. IF THERE
ARE ACTUAL NI ENGINEERS SITTING OUT THERE READING THIS BOARD WITH
EXPERIENCEE IN DEVELOPING THE LABVIEW PRODUCT WHO CAN CORRECT MY
ASSUMPTIONS IN THIS POST, PLEASE DO SO. IF I AM CORRECT IN MY
ASSUMPTIONS, PLEASE LET US KNOW THAT ALSO. I TOO WOULD LIKE TO KNOW
FOR CERTAIN THE ANSWERS TO THESE SORTS OF QUESTIONS..
...BATTERIES NOT INCLUDED...SOME ASSEMBLY REQUIRED...PRODUCT SOLD BY
WEIGHT NOT VOLUME, CONTENTS MAY HAVE SETTLED DURING SHIPPING...BEST IF
USED BY SEPTEMBER 30, 2002...CHECK WITH YOUR PHARMACIST BEFORE USING
THIS IN COMBINATION ANY OTHER PRODUCT...THERE IS A LOW OCCURRENCE OF
SIDE EFFECTS WITH USE OF THIS PRODUCT, AMONG SOME USERS THIS PRODUCT
MAY CAUSE DROWZINESS, IRRITABILITY, TREMORS, HEADACHES, BLURRED
VISION, LOSS OF HAIR, UNCONTROLLED BLEEDING, HEART PALPITATIONS,
RASHES, OR UPSET STOMACH....ELECTROCUTION HAZARD DO NOT USE NEAR
WATER...DO NOT USE NEAR POWER LINES...CALL BEFORE DIGGING...NO
ANCHORING OR DREDGING....SPARK HAZARD DO NOT USE NEAR FLAMMABLE
LIQUIDS OR VAPORS...DO NOT PLACE IN MICROWAVE...DO NOT DISPOSE OF IN
OPEN FLAME...READ ALL INSTRUCTIONS CAREFULLY BEFORE USING
PRODUCT....NOT RESPONSIBLE FOR MISUSE OF THIS PRODUCT.....CONSULT YOUR
PHYSICIAN OR THE NEAREST POISON CONTROL CENTER IF ACCIDENTALLY
INGESTED....THE CHECK IS IN THE MAIL....I HAD AN ACCIDENT...THE DOG
ATE MY HOMEWORK.....:)
With the above disclaimers about LabVIEW in PLAIN VIEW, here goes:
As far as I understand it, LabVIEW doesn't really "compile" at all as
you might think of it for C, FORTRAN, or Pascal programming, i.e.
compile source code into object files, link the objects, and set
addresses and create a binary executable file that can be handed
straight to the processor. This is called n-code compiling for
"native code".
LabVIEW as I understand it is a p-code compiler. The "p" stands for
"pseudo". What this means is that compiled "executable" LabVIEW code
is really being interpreted by the LabVIEW run-time engine in a manner
very similar to that used by the old MS-BASIC, QBASIC (don't jump on
me if you are a QuickBASIC programmer, I don't mean QuickBasic but
rather QBASIC that ships with MS-DOS), and GW-BASIC interpreters. For
all you young whipper snappers out there who've never heard of GW
BASIC, I'll give another example - PERL.
That is why LabVIEW executing processes are always so large and
sometimes slow, because the LabVIEW runtime engine is running in that
execution space. An interpreter is by it's nature is very general
purpose, it always has to be ready to support all of the features of
the implemented interpreted language. Also it has to implement a
parser to process the next line of code. What the "next line of code"
means to LabVIEW's processor is difficult for me to say. I guess it
means executing whatever is sitting at the other end of the current
wire.
The LabVIEW run-time engine / interpreter has to be pretty complex -
think about it, it suppports multiple parallel threads of execution
and dynamically launching VI's. This is a far cry from the good old
days of MS-BASIC interpreters. Of course all this complexity comes
with a price tag: size. Whether your program actually uses the
multi-threading features of LV or not, you pay for it with a larger
execution footprint.
C programs on the other hand is compiled to native code and it is up
to the developer to pick and choose libraries to include and whether
to link to them statically or dynamically. Dynamic linking is a
significant improvement in that it has significantly reduced the size
of executing C applications. On the other hand DLL's can have a
series of run time problems that statically linked libraries don't
usually suffer from. In any event, compiled n-code C source almost
always comes out smaller than p-code LabVIEW in terms of execution
footprint.
The actual LabVIEW VI's themselves are large because they have to
maintain a database of all the objects on the front panel and the back
panel including their graphical location and all the interconnecting
wires and their locations and how the various objects actually do
connect.
This is also why LabVIEW vi's, once corrupted are usually not
salvageable except for sometimes it workes to cut and paste into a new
diagram. This VI file size is the price we pay for being a graphical
programming language.
Douglas De Clue
LabVIEW programmer
ddeclue@bellsouth.net
Labviewguru wrote in message news:<506500000005000000E0900000-1027480788000@exchange.ni.com>...
> And I heard a rumor that LabVIEW 7 was coming out.
>
> Funny thing about rumors, they are just that.
>
> I think it would be an incredible thing of National Instruments were
> to expand the capabilities of LabVIEW in this way, and others. I have
> been hounding them to create a version of LabVIEW that allows the
> creation of smaller executables, by eliminating libraries that aren't
> needed in a particular application. It is my guess that LabVIEW
> compiles with the equivalent to a #include section that is always the
> same, and is a mile long. I have asked for the capability to pare
> this down with a #exclude, or allow #include, something to make the
> applications smaller when they are so simple (better yet, dynamic and
> automatic library inclusion based on the code hierarchy.)
>
> As for this rumor, I have heard nothing. Go to NI Week, (good idea
> anyway) you might hear something there. And if you don't hear
> anything that can be substantiated, then don't post it here. I'm
> probably not the only one that doesn't appreciate rumors, especially
> ones like this that offer false hope for a better version of LabVIEW.
