[Coco] error trapping

Sun Dec 6 02:29:53 EST 2009

I have done enough now to specify a few things. First, you cannot pass any structure by value. Attempting to do so results in a compiler error.

The parameter list is created by the calling procedure as a list of long integers. I assume each long represents the absolute memory address of the variable. Variables passed by reference are "seen" as update-able (you can modify the original variable's value), Variables passed by value (or parameters that are literals or expressions in the calling procedure) are "seen" as read-only, and are not modifiable.

When it comes to the size, variables of type BYTE, INTEGER, REAL or BOOLEAN are determined by their type. Strings and structures have their shape and size data contained in the DSAT of both procedures, though the shape in the calling procedure can be different from the shape in the called procedure. In these cases, it is only the size of the parameter that counts.

Byte variables cannot be passed by value. While Basic09 does not return a compiler error, the value received by the called procedure is 0. Boolean variables cannot be passed by value. You can, however, pass a boolean literal as a value (TRUE or FALSE).

In answer to your question, Aaron, I can compare all of the parameters by their sizes and determine if the order is correct, so long as all of the parameters passed equal the number of parameters received. I have not tested the idea of trying to pass more than one variable to a procedure expecting 1 parameter. In other words:

DIM a,b,c:INTEGER
RUN myProc(a,b,c)

PROCEDURE myProc
PARAM d(3):INTEGER

That comes next. heh

Wayne

________________________________
From: Wayne Campbell <asa.rand at yahoo.com>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Sat, December 5, 2009 3:12:34 PM
Subject: Re: [Coco] error trapping

>I'm no Basic09 expert, but I've read that it is pass by reference for
>function parameters.  If this is the case, won't you be able to see
>that the pointers into the variable table are identical in those two
>examples?  you should be able to ignore the type provided the
references are equivalent.  just a thought.

You are correct in that my example is passed by reference. Passed by value would look like this:

RUN myProc(myArray+0)

Now, understand that adding 0 to an array may produce an error. When I've done tests passing by value, it was always with atomic types (BYTE, INTEGER and REAL for +0, and STRING with +""). Because they are not structures, the value of the variable is passed instead of the pointer. Structures are different, and I have never seen an example of passing a structure by value.

When it comes to matching parameter variables, there are 2 things that have to be looked at, the poisition in the parameter list of that variable, and it's size. I can probably do it that way for everything, but I don't know what would be different if the parameter was passed by value. I'm still determining exactly what the parameter data looks like in the receiving procedure. I do know the receiving procedure has no clue what the passed data is or will look like, other than the type. You know, instead of doing all this conjecturing, I think I should write some code and see what the resulting I-Code looks like. That will answer that easily enough.

I'll post when I have something to report.

Wayne

________________________________
From: Aaron Wolfe <aawolfe at gmail.com>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Fri, December 4, 2009 3:58:27 PM
Subject: Re: [Coco] error trapping

On Fri, Dec 4, 2009 at 6:53 PM, Wayne Campbell <asa.rand at yahoo.com> wrote:
> That is the most true allegory I have ever read. In addition to assembly language programming, I can relate my efforts with Basic09 I-Code. Figuring out every step needed in the process requires breaking each part down to the most basic steps, then building the steps into the whole part. And each part is required to be complete in itself before the next part can be dealt with.
>
> I am now roughly 2/3 of the way through the second part of decoding I-Code. When this part is completed, I will be able to reproduce the variable declaration statements required by the procedure being decoded.
>
> The third part will reproduce the source instructions from the procedure. At that point, I will be able to fully decompile any I-Code module. After that, I plug that engine into unpack, and you will be able to deal with merged module files. unpack already contains the code for determining if a file is a program module or not, whether or not it is I-Code, and will skip over object-code subroutines that have been merged into the file.
>
> When unpack is complete, it will be time to start work on comparing parameter variables in one procedure with parameter variables in the corresponding called procedure. This will help with renaming variables that are common between procedures.
>
> That is going to be fun, because Basic09 allows this:
>
> PROCEDURE caller
> DIM myArray(32):BYTE
>
> RUN myProc(myArray)
>
> PROCEDURE myProc
> PARAM myString:STRING
>
> Because both variables are the same size, Basic09 will put the contents of myArray into myString.
>
> This going to take extra steps to ensure that the match is made between myArray and myString.
>

I'm no Basic09 expert, but I've read that it is pass by reference for
function parameters.  If this is the case, won't you be able to see
that the pointers into the variable table are identical in those two
examples?  you should be able to ignore the type provided the
references are equivalent.  just a thought.

> Wayne
>
>
>
>
> ________________________________
> From: Bob Devries <devries.bob at gmail.com>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Sent: Wed, December 2, 2009 10:51:21 PM
> Subject: Re: [Coco] error trapping
>
> That line I alluded to earlier goes like this:
>
> "Writing programs in assembly language is a lot like digging a fence post
> hole with a tablespoon. It takes a lot of steps, but you have complete
> control over all the dirt."-Jim K. Issel
>
> Regards, Bob Devries
>
>
>
> --
> Besides a mathematical inclination, an exceptionally good mastery of one's
> native tongue is the most vital asset of a competent programmer.
>
> Edsger W.Dijkstra, 18 June 1975
>
> ----- Original Message -----
> From: "Willard Goosey" <goosey at virgo.sdc.org>
> To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
> Sent: Thursday, December 03, 2009 12:43 PM
> Subject: Re: [Coco] error trapping
>
>
>> On Wed, Dec 02, 2009 at 04:48:39PM -0800, Wayne Campbell wrote:
>>
>>> I just got this post. I guess you posted it before I posted my own
>>> reply.
>>
>> Beware the bug.  The Param string needs to have a length or it'll
>> default to 32 bytes. :-(  I looked that up in the BASIC09 manual last
>> night.
>>
>>>You have sshown me something I didn't think about, or realize
>>> might be necessary. I've never cleared the cc field before making
>>> the call.
>>>
>> I don't know if it's really necessary.  I think that just got added
>> when I was chasing another bug, and left in.
>>
>> I don't know BASIC-09 that well, so debugging it can make me thrash
>> around wildly.
>>
>>> Also, my routine ended up being shorter than yours, so I need to
>>> compare the differences and see what you are doing that I didn't
>>> think about.
>>
>> Well, I'm aiming at a general case, and you might be looking for
>> something more specific.  Other than that, the only thing I can think
>> of is make sure the filename ends in a newline.
>>>
>>> Thanks for the help. :)
>>
>> No problem!
>> Willard
>> --
>> Willard Goosey  goosey at sdc.org
>> Socorro, New Mexico, USA
>> I search my heart and find Cimmeria, land of Darkness and the Night.
>>  -- R.E. Howard
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco