[Coco] type statements

[Wayne Campbell]

Until now, I have always asked a question, and then realized the answer, and ended up feeling foolish for the asking. This time, I am asking on purpose, just to see if I can realize the answer after asking. (Wierd, huh? Well, it didn't work. I still have no clue.)

OK here it is. I have associated record variables and field variables in the instruction code. So far, decode seems to be doing this step correctly. The difficulty is that a field can also be a record. For example, if you see:

var.fld1.fld2

in a procedure, it indicates that:

 * var is a record variable
 * fld1 is a field of var, and is also a record
 * fld2 is a field of fld1.

I am up to the point of determining the record variables' structures. To do this, I have to know:

 * the size of the record
 * the number of fields currently associated with the record
 * the offset within the record of each field
 * the size of each field

All of this data is contained in the variable reference file, but only as fields of a variable reference, and not connected. In other words, the record variable is set as a record, the field record variable is set as a field and a record, and the second field variable is set as a field. Each field contains the reference number of the record it is a part of.

What the references do not contain is how many fields have been associated to a given record, or where there are unidentified fields within that record. This is what I need to determine now. The DSAT will tell me what I need to know about unused fields, but not before I determine what is already identified. (Well, not exactly, since there can be entire records whose fields were never referenced. I have to figure those out differently.)

I think I need a record that contains the record reference #, the number of fields identified for that reference, the offset of each field within that record, and the size of each field. The problem is, this would be a variable length record, which Basic09 does not support. I could use an array for the repetitive data that varies in count, but then I have to decide how many possible references there could be. Type statements can contain any number of fields. If there is a limit, it is the limit of a record's max length, which I believe is 32767 bytes, and the max length of an instruction, which is 255 bytes.

There could be hundreds of references, especially if the record is composed of other records. I am at a loss for how to approach this. It just isn't making sense yet. Can anyone reading this post come up with a clue, or a possible way to begin the process?

What I am doing now is to go through the variable references and compile a list of records and fields. I'm thinking I can make these references records that contain the data I need from each reference, but this is going to end up using a larger amount of data memory to contain the array. And even more when I start adding other fields to give me the correlations I need to make.

What I get from the references right now are:

 * reference number for that variable record
 * if a field, reference number of record variable
 * 2 booleans denoting field and/or record reference
 * data memory address of the variable (offset within the record if a field)
 * size of record or field

I need to be able to build a "map" of the record variable that shows where in the structure the defined fields occur, and how much space within the record they use. This will allow me to determine how many "gaps" there are in the structure that have to be identified. If there are no field references for that record, then the entire size is a gap.

Then I need to read the data in the DSAT. I have to find, in the gaps in the DSAT, the integer value that is the size of the record. Then, using the fields already identified (if any), I can determine how many fields there are minimum, counting each gap as 1 field. Then, using the sizes of the gaps in the record, I can begin to determine how many integers in the DSAT indicate fields of that record. Once that is done, I have the record identified, and all of its fields identified. If any of the fields are structures (strings, arrays or records), the data for the shape to those fields occurs immediately before the record shape data. Because this data is not uniform length, it's not as simple as reading a preset number of integers. The number of integers read is determined by the type of structure it is. This data I can deal with, and have already written the base algorithm I will use to read it.

So, how do I build my record data to identify the fields with? And, how do I know when I have identified all fields? The data for the field shapes is different, and I do not know how to tell when I have identified all field representation integers. For example, here is a record defined in a procedure named createmsg:

TYPE format=board:BYTE; ln,number,dzone,dnet,dnode,dpoint,ref1,ref2,pmsg,nmsg:INTEGER; poss:REAL; f(8):BOOLEAN; to$,from$,sub$:STRING[32]; dt:STRING[20]

The DSAT data for this record looks like this (organized):

001A 0008 0008 <- f(8):BOOLEAN     <- 00B3 (integer in record shape)
0022 0020      <- to$:STRING[32]   <- 00B7
0042 0020      <- from$:STRING[32] <- 00BD
0062 0020      <- sub$:STRING[32]  <- 00C5
0082 0014      <- dt:STRING[20]    <- 00CC

0096 2020 6B 0073 0078 0196 0081 0088 019E 0090 0097 009E 00A5 00AC 00B3 00B7 00BD 00C5 00CC

TYPE format=
0096 <- SIZE(format)
2020 <- Unknown
6B   <- board:BYTE;
0073 <- ln,
0078 <- number,
0196 <- dzone,
0081 <- dnet,
0088 <- dnode,
019E <- dpoint,
0090 <- ref1,
0097 <- ref2,
009E <- pmsg,
00A5 <- nmsg:INTEGER;
00AC <- poss:REAL;
00B3 <- f(8):BOOLEAN;
00B7 <- to$,
00BD <- from$,
00C5 <- sub$:STRING[32];
00CC <- dt:STRING[20]

This record is already identified, since all of the structure data was referenced in the instruction code. It is a simple test to see what other fields were also addressed, and whether or not the entire structure is identified. Having the source code for the declarations helps identify what each field represents. In this procedure, there is another record structure immediately following this one. None of the fields were addressed in the instruction code:

TYPE id=iboard:BYTE; inumber:INTEGER; fi(8):BOOLEAN; ti$:STRING[32]

0003 0008 0008 <- fi(8):BOOLEAN  <- 00E9
000B 0020      <- ti$:STRING[32] <- 00EE

002B 6265 D6 00DF 00E9 00EE

TYPE id=
002B <- SIZE(id)
6265 <- Unknown
D6   <- iboard:BYTE;
00DF <- inumber:INTEGER;
00E9 <- fi(8):BOOLEAN;
00EE <- ti$:STRING[32]

When I read this in decode, I can identify the record structure by the SIZE integer. The next integer is of unknown purpose or use, and the field representations begin with a byte, followed by integers in ascending order. In this record, and since I began decoding I-Code, the values of the integers always remained ascending. The first integer to occur with a value less than the current integer indicated the end of the record. In this case, the same is true. 00EE is greater than the next data memory offset, which is record address + size of record.

In the previous record above, however, this is not true, as the fields containing the values 0196 and 019E are not only going to cause the previous calculation to end prematurely, these values are much larger than the value of the next data memory address. I do not understand how to figure this out.

Then there is the field structure data. In this record, none of the fields were addressed. This means decode does not know what that data is, or how to represent it. I have figured out an algorithm I believe will work, but I can't test it until I have correctly identified the record structure.

If there was a way to interpret the integers in the record data, and have it tell me what kind of field it is, I could more easily figure all of this out, but I do not know how to interpret the data that way.

There are 2 other areas concerning Typw data that I am unable to determine how to deal with. 1 of them may never be solvable. The first is the case of a record where neither the record variable nor any of its fields were addressed. I can determine that there is an unused variable, and an unused record. If the sizes match, I can assume the variable is a record of that type. Because the variable was never addressed, I have to figure out the entire record with no clues other than the field data in the record shape data.

The last area of concern is multiple different records of the same size. Since the primary key I am using in all of this is the record size, having more than one type of the same size makes it difficult to determine which record variable goes with which record data. For example:

TYPE REC1=myByte:BYTE; myInt:INTEGER; myReal:REAL
 SIZE=8
TYPE REC2=thisBool,thatBool:BOOLEAN; myString:STRING[3]; aByte:BYTE; aInt:INTEGER
 SIZE=8

The variables DIMed to these records would all have a size value of 0008. The record data in the DSAT, for both records, will have a size integer value of 0008.

I have no idea how to determine which variable is assigned which record structure. This is compunded if both types are the same size AND contain the same number of fields.