home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
RBBS in a Box Volume 1 #2
/
RBBS_vol1_no2.iso
/
007d
/
basicsub.doc
< prev
next >
Wrap
Text File
|
1983-10-31
|
4KB
|
77 lines
--------------------------------
THE CALL STATEMENT
--------------------------------
There have been a number of requests for clarification of the CALL statement
in the various Microsoft langauges. Hopefully, the following explanations
will clear up several misunderstandings. First, let's look at the "Microsoft
call standard". When any Microsoft program issues a CALL statement, such as
"CALL MYROUT", control is passed to the address specified by MYROUT. In all
cases except the BASIC interpreter, MYROUT must be the name of a subroutine
program, or a global/public label within a MACRO-80 routine. The calling and
the called program must be linked together by L80 into a single file. In the
BASIC interpreter (MBASIC), the variable MYROUT must be set to the beginning
address of the subroutine.
If we complicate things by adding a few paramaters to the CALL, such as: "CALL
MYROUT(A,B); the parameters are passed as follows: The *ADDRESS* of the first
parameter is passed in registers HL, the second in DE, and the third in BC.
If there are more than three parameters, BC points to a block of memory
containing the *ADDRESS* of parameters three through N. Note that the address
and *NOT* the parameter itself is passed. The arguments themselves correspond
to the standard MICROSOFT variable format, (2 bytes for an integer, 4 bytes
for single precision floating point, and 8 bytes for a double precision
floating point number) with two exceptions.
COBOL passes variables as they would appear to another COBOL program (display,
comp, or comp-3). Strings are also handled a bit differently. The address
pointed to by the register contains a three byte "string descriptor". This
string descriptor contains the length of the string in byte one, and the
address of the string in bytes two and three. When passing strings, take care
not to modify this string descriptor, or unpredictable results will occur.
In all cases, it is the user's responsibility to ensure that the arguments
correspond *exactly*, in both type and number. Also, be sure to preserve
*all* of the registers and use your own local stack when you call macro
routines.
With the preliminaries out of the way, let's look at which languages can call
which other languages. In the following table, "B" represents the BASIC
interpreter (MBASIC), "BC" the BASIC Compiler (BASCOM), "F" the FORTRAN
Compiler (F80), "C" the COBOL Compiler, and "M" the MACRO Assembler (M80). A
"Y" in the appropriate entry means that a CALL is possible.
CALLED PROGRAM
********************************
CALLING* ** ** ** **
PROGRAM*B** BC** F ** C ** M
********************************
B * ** ** ** ** Y
********************************
BC * ** ** 1 ** ** Y
********************************
F * ** ** Y ** ** Y
********************************
C * ** ** 2 ** Y ** Y
********************************
M * ** ** 3 ** ** Y
********************************
[NOTES:]
1 - When calling a FORTRAN routine from the BASIC Compiler, only one of the
two languages may be used to perform I/O. When the programs are linked, LINK
the BASIC program first, then search BASLIB, then load the FORTRAN program,
then search FORLIB. The multiply defined global message may be ignored.
2 - When calling FORTRAN from COBOL, remember that the variable types are
different. Only comp data items will be passed in such a way that FORTRAN can
deal with them without an encode statement.
3 - While MACRO-80 may not directly call FORTRAN subroutines, you may make use
of the routines in the FORTRAN library. For more information,see the FORTRAN
manual. Of course, from within M80, you may initiate execution of any other
.COM file by reading the file and then jumping to the appropriate address.
in M80, you may initiate execution of any other
.COM file by readin