Many are saying that VBDOS / QB dont compile but have an interpretter loaded in
the front of the EXE and the code loaded onto the back? (Is that it?) And that
these EXEs _are_ the stand-alone option?

If this is the case then I have some questions:
How does PDQ get the EXE so small?
Do the EXEs requiring BRUN /VBRUN work the same way except the interpretter and
all funcs are in the [V]BRUN file?

All my other doubts seem to have been answered.

: Many are saying that VBDOS / QB dont compile but have an interpretter loaded in
: the front of the EXE and the code loaded onto the back? (Is that it?) And that
: these EXEs _are_ the stand-alone option?

My guess is that it's (how the final EXE is generated) really a
combination of both approaches.

: If this is the case then I have some questions:
: How does PDQ get the EXE so small?

by replacing parts of the run-time library with a more compact version,
and then by replacing calls to routines with more compact ones.  Since
PDQ & stub files work, the public interface for all the built-in
functions are modelled just like any call.  Whether, within a function, a
p-code interpreter is used, is another issue. For example, if you compile
with the /a option to generate an assembler listing, for much of your
code, you get normal assembler print-out.  Then one of the B$ rtl
routines gets called-- some of these could be p-coded.

Too bad Ethan Winer (author of PDQ) is not on the net.  He could answer
this with some authority.  I'm just guessing, based upon what I've picked
up over the years...  

: Do the EXEs requiring BRUN /VBRUN work the same way except the interpretter and
: all funcs are in the [V]BRUN file?

I'd imagine the run-time code is similar whether you're using BRUN or /O.

: All my other doubts seem to have been answered.

--

On Wed, 20 Jul 1994 14:21:42 GMT,

Josh Roybal
University of Minnesota - College of Liberal Arts

Just compile your code with BC.EXE with the /A option and list the pseudo
assembler code that is generated.   You can see that the integer code executes
directly and the floating point and string code uses calls to library
routines.  That is why you uses integers whenever possible for speed.  Also
you can see how smart the compiler is in coding things like I=I+1 when I is an
integer and if it pulls stuff like j=5 out of loops.

MM> How does PDQ get the EXE so small?

Crescent Software did several things in PDQ to reduce the size of the
EXE (and speed up the execution):

1: Instead of combining several routines into large OBJ chunks, they
separated each function into it's own OBJ file. You can then link into
your EXE just the OBJ's you want (called improved granularity)

2: They went through each function and optimized it's assembly language
for size and speed.

3: They eliminated some of the error checking/hand-holding that QB does
ie in PDQ you can choose to LOCATE at row 3245 and column -457 without
an error (they're depending on the BIOS to save you from writing
electrons all over the neighbor's house <g>)

4: They give you several variations of many of the functions so you can
choose how many features of a given command you can live without and
they tell you what that will save you. (these are called STUB FILES)

5: They do not support some QB functions.  I don't use graphics (PSET,
DRAW...) so that doesn't matter to me, but I could sure use
PRINT USING... They do have a very versatile String formatting
function 'FUSING$' that I can use in the place of PRINT USING but
the hassle of converting a whole bunch (10K) PRINT USING statements
is just about the only thing stopping me from converting some of
my older projects.

I use PDS7 and Crescent Software's Quick Pack for most large projects so
that I won't come up with a surprise function causing a retreat from
PDQ. I use PDQ for small utilities - 1K to 10K, for projects when I
need the most speed I can get, when I need a quick, clean TSR, and also
when I need to produce a small, fast demo COM program to frustrate my
C and C++ friends <G>. I still can't beat the Assembly/C boys 57 bytes
for HELLO WORLD (mine is 900 bytes) but I can give them a good run for
a real world string handling utility.

* RM 1.3  * Eval Day 24 * RoboMail -- The next generation QWK compatible reader!

----
One Stop PCBoard = Eastern Washington's Electronic Information Service

-> Many are saying that VBDOS / QB dont compile but have an interpretter loaded
-> in the front of the EXE and the code loaded onto the back? (Is that
-> it?) And that these EXEs _are_ the stand-alone option?

Then many are wrong.  QB/QBX/VBDOS all produce true object code and
EXE files.  Only VB/WIN uses an interpreter front end.

Perhaps they are confusing the fact that the QB/QBX/VBDOS IDE's use a
form of interpreted p-code.  This is only in the IDE.

Daniel
---
 t DSE Online! t The Home of PB/VISION & PB/WORKSHOP for powerbasic 3.0

--
/\/  Daniel P. Stasinski      /\/    Voice: +1-707-459-4358  /\/
/\/  DSE Software Publishing  /\/  FAX/BBS: +1-707-459-4484  /\/

/\/  Willits, CA 95490-0096   /\/  FidoNet: 1:125/123        /\/

[several points on how it does it]

Yeah, I knew some of those methods (some of the others are interesting though),
but there are some people here (I think) who say the microsoft compilers put an
have a interpretter into the EXE (even stand-alone) that runs your code ie it
hasn't really compiled your src to machine code.

I should really have phrased the question as, how can there be an interpreter
in the EXE if PDQ can get it down to 900bytes (that is one impressively small
peice of code- MS are renowned for impressivly large peices of code). As you
listed all the methods PDQ uses I can safey say it's not another compiler - it
makes the MS compiler more efficient in what it links into the EXE etc.