Proposed command line argument extraction for Kyan Pascal
A2CPM
The messages about "Problem with AppleWin" in
comp.emulators.apple2 have given me an idea for a solution. The
solution borrows heavily from Turbo Pascal. Example text:
(* begin Pascal source text *)
program sample;
type pString = record
len: char;
c: array[1..15] of char
end;
var count, max, i: integer;
answer: pString;
function ParamCount: integer;
begin
ParamCount := 0;
#a
; not yet coded
#
end;
procedure ParamStr(i: integer; var pS: pString);
begin
#a
; not yet coded
#
end;
begin { Main }
count := ParamCount;
if count = 0
then writeln('No parameters supplied')
else begin
ParamStr(1, answer);
max := ord(answer.len);
write('First parameter is "');
for i := 1 to max
do write(answer.c[i]);
writeln('"')
end
end.
(* end Pascal source text *)
In Turbo Pascal, 'ParamStr' is a function. In Kyan Pascal,
function results can only be of a scalar type so in the above example
'ParamStr' is a procedure with a 'VAR' parameter.
The above sample program was compiled successfully using Kyan
Pascal with AppleWin. Of course, it will not run because the guts of
'ParamCount' and 'ParamStr' do not yet exist. Also, code must be
added to "stdlib.s" so that the parameters in $0200 can be copied to a
place in memory where 'ParamCount' and 'ParamStr' can find them and
before anything overwrites $0200.
Willi
John B. Matthews
<e5ec3f2f-154b-4d49...@n10g2000vby.googlegroups.com>,
A2CPM <a...@wilserv.com> wrote:
> procedure ParamStr(i: integer; var pS: pString);
> ...
> In Turbo Pascal, 'ParamStr' is a function. In Kyan Pascal,
> function results can only be of a scalar type so in the above example
> 'ParamStr' is a procedure with a 'VAR' parameter.
Why not return a pointer?
const MaxString = 127;
type String127 = array [1..MaxString] of char;
StrPointer = ^StrRecord;
StrRecord = record
StrFound: String127;
NextStr: StrPointer
end;
function ParamStr(i : integer) : StrPointer;
> The above sample program was compiled successfully using Kyan
> Pascal with AppleWin. Of course, it will not run because the guts of
> 'ParamCount' and 'ParamStr' do not yet exist. Also, code must be
> added to "stdlib.s" so that the parameters in $0200 can be copied to
> a place in memory where 'ParamCount' and 'ParamStr' can find them and
> before anything overwrites $0200.
This seems like the essential problem. Why not adapt ParseLine to
allocate space on the heap and copy the input buffer? FixBuffer would
become CopyBuffer, copying as it clears high bits. ParseLine already
allocates space on the heap for the required number of StrRecords.
Just wondering out loud about other approaches.
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
A2CPM
On Jun 12, 11:03 am, John wrote:
<--- snip --->
> Why not return a pointer?
<--- snip --->
> Just wondering out loud about other approaches.
I'm a little pointer-phobic but you have made a good suggestion so
I'll probably implement 'ParamStr' as you've suggested.
I got something working this morning but doing it right will take
more work.
Willi
A2CPM
type pString = record
len: char;
s: array[1..15] of char
end;
pStrPtr = ^pString;
var max, i, j: integer;
answer: pStrPtr;
function ParamCount: integer;
begin
ParamCount := 0;
#a
LDA CLPCNT
LDY #5
STA (_SP),Y
#
end;
function ParamStr(i: integer): pStrPtr;
begin
ParamStr := nil;
#a
;
;
;
TXA
PHA
;
; Get high order byte of parm number
;
LDY #8
LDA (_SP),Y
;
; Branch if invalid
;
BNZ PSEXIT
;
; Get low order byte of parm number
;
DEY
LDA (_SP),Y
;
; Branch if invalid
;
CMP CLPCNT
BGE PSEXIT
;
; Multiply by two
;
ASL A
TAX
;
; Copy address to caller's variable
;
LDA CLPADR,X
LDY #5
STA (_SP),Y
LDA CLPADR+1,X
INY
STA (_SP),Y
;
;
;
PSEXIT PLA
TAX
#
end;
begin { Main }
for i := 0 to ParamCount - 1
do begin
answer := ParamStr(i);
max := ord(answer^.len);
write('Parameter number ', i, ' is "');
for j := 1 to max
do write(answer^.s[j]);
writeln('"')
end
end.
(* end Pascal source text *)
The above source file can be compiled with any existing Kyan Pascal
compiler but needs the new "STDLIB.S" to run correctly.
A big THANK YOU to John Matthews for upgrading my knowledge of
pointers.
Anton Treuenfels
"John B. Matthews" <nos...@nospam.invalid> wrote in message
news:nospam-306A99....@news.aioe.org...
>
>
> const MaxString = 127;
> type String127 = array [1..MaxString] of char;
> StrPointer = ^StrRecord;
> StrRecord = record
> StrFound: String127;
> NextStr: StrPointer
> end;
> function ParamStr(i : integer) : StrPointer;
Um - if the purpose of 'MaxString' is to hide the actual numeric value it
represents, doesn't it defeat the purpose to expose that value in the name
'Str127'? Would 'StrMax' be a better name, perhaps? That way if the value of
'MaxString' ever changes it wouldn't be necessary to change all the 'Str127'
references to match (technically they wouldn't have to change, but they'd be
fairly misleading names if left alone).
- Anton Treuenfesl
John B. Matthews
"Anton Treuenfels" <teamt...@yahoo.com> wrote:
Probably, but all such symbols are effectively global. The
(case-insensitive) symbol MaxString must be defined to use any of the
standard string manipulation routines:
{ /kix/bin/length.i }
{ /kix/bin/index.i }
{ /kix/bin/substring.i }
{ /kix/bin/concat.i }
The symbols String127, StrPointer and StrRecord are defined in
other.lib/parse.types.i specifically for use with other.lib/parseline.i.