oopic-compiler-devel

[Oopic-compiler-devel] OOpic firmware versions and code generation impact

[D. D. M. <Da...@Mc...>]

Something I received from Scott Savage, but had not passed on yet.

I asked:

>With regard to the 'OOPicObjectCommandList', am I correct in understanding
>that
>each newer firmware version only added objects or commands?
>
>In other words, to support multiple firmware versions, is it only a matter
>of
>filtering the commands/objects by the version they first appeared in?  If
>so,
>and for the case of the object commands, would you have available a
>cross-reference as to which firmware version the  object command became
>available.

and Scott replied on 07-MAY-2004:

<quote>
Yes new commands and object were added with each version.

However, the sales of the versions below II+ are only about 10% of total
sales.

Given that, I think it would be best to work with just the II+ version.

Give me a few more days on the Object database.
</quote>


Several points:

1. Although have not yet received the 'Object database', we do have some
information about the firmware differences.

2. Since firmware version II+ is 90% new sales, that is the reasonable first
target for the toolchain.  However, the statitistic does not comment to the
relative sizes of the shipped populations.

3. How would the project accomodate different versions of the firmware?  Is
it a matter of a different code generator for each firmware, or does one
generator handle the differences conditionally?

Daniel

Re: [Oopic-compiler-devel] OOpic firmware versions and code generation impact

[Neil D. <nd...@us...>]

D. Daniel McGlothin wrote:
> <quote>
> Yes new commands and object were added with each version.
> 
> However, the sales of the versions below II+ are only about 10% of total
> sales.
> 
> Given that, I think it would be best to work with just the II+ version.
> 
> Give me a few more days on the Object database.
> </quote>
> 
> Several points:
> 
> 1. Although have not yet received the 'Object database', we do have some
> information about the firmware differences.

It's certainly encouraging to see that it sounds like just a series of
extensions to the op-codes, rather than anything more fundamental.

Presumably there's zero difference between the C/BASIC/Java language
support when targeting different firmware versions?

> 2. Since firmware version II+ is 90% new sales, that is the reasonable first
> target for the toolchain.  However, the statitistic does not comment to the
> relative sizes of the shipped populations.

Agreed.

> 3. How would the project accomodate different versions of the firmware?  Is
> it a matter of a different code generator for each firmware, or does one
> generator handle the differences conditionally?

I think we should be able to use the same code generator.  I would suggest
that we pass in a parameter to the compiler to specify the firmware
version, and the parser will throw an error if the input code includes
stuff not allowed for that firmware version.  Once the parser has
successfully parsed the input code and generated an internal
representation, the code generator should just be able to do its stuff,
regardless of the firmware version (I think).  It sounds to me as though
the code generator should generate exactly the same code irrespective of
firmware version setting, as long as the input code is legal on the
respective firmware versions.

If I'm right about this, all we need to do is put some conditional logic in
the parser to disallow certain things, which I imagine would simply be the
instantiation of VC objects that aren't supported on a given version.

Neil
-- 
Neil Durant
<nd...@us...>

Re: [Oopic-compiler-devel] OOpic firmware versions and code generation impact

[D. D. M. <dd...@mc...>]

Neil,

> > 3. How would the project accomodate different versions of the firmware?
Is
> > it a matter of a different code generator for each firmware, or does one
> > generator handle the differences conditionally?
>
> I think we should be able to use the same code generator.  I would suggest
> that we pass in a parameter to the compiler to specify the firmware
> version, and the parser will throw an error if the input code includes
> stuff not allowed for that firmware version.  Once the parser has
> successfully parsed the input code and generated an internal
> representation, the code generator should just be able to do its stuff,
> regardless of the firmware version (I think).  It sounds to me as though
> the code generator should generate exactly the same code irrespective of
> firmware version setting, as long as the input code is legal on the
> respective firmware versions.
>
> If I'm right about this, all we need to do is put some conditional logic
in
> the parser to disallow certain things, which I imagine would simply be the
> instantiation of VC objects that aren't supported on a given version.

I think you are partly right.

The parser will need to filter by firmware so as to not allow unsupported
objects.

However, since the firmware commands (the op-codes) also vary by version,
won't the generator also need to be firmware aware?

Daniel

Re: [Oopic-compiler-devel] OOpic firmware versions and code generation impact

[Neil D. <nd...@us...>]

D. Daniel McGlothin wrote:
> > I think we should be able to use the same code generator.  I would
> > suggest that we pass in a parameter to the compiler to specify the
> > firmware version, and the parser will throw an error if the input code
> > includes stuff not allowed for that firmware version.  Once the parser
> > has successfully parsed the input code and generated an internal
> > representation, the code generator should just be able to do its stuff,
> > regardless of the firmware version (I think).  It sounds to me as
> > though the code generator should generate exactly the same code
> > irrespective of firmware version setting, as long as the input code is
> > legal on the respective firmware versions.
> >
> > If I'm right about this, all we need to do is put some conditional
> > logic in the parser to disallow certain things, which I imagine would
> > simply be the instantiation of VC objects that aren't supported on a
> > given version.
> 
> I think you are partly right.
> 
> The parser will need to filter by firmware so as to not allow unsupported
> objects.
> 
> However, since the firmware commands (the op-codes) also vary by version,
> won't the generator also need to be firmware aware?

Yes, you're right, I wasn't thinking straight.  We will need the code
generator to know which op-codes are permissible for a given version of the
firmware.  I imagine most of the code generation will use "standard"
instructions available on all firmware, but perhaps newer firmware supports
instructions that allow more optimisations to be made etc.

Looking at opcode 251, "CommandSet2", it looks like this might be where new
instructions have been added from previous firmware versions.

So it looks like each version of the firmware is backwards-compatible with
the older instruction sets at least.  I can confirm this because several
times I have successfully run code on my 2+ which I'd accidentally compiled
for an older version of the firmware.

We only have the B.2.x+ instruction set documentation at the moment, so I
guess that's all we can really target.  We should ensure that both the
parser and the code generator are capable of being aware of what input code
is legal and what output instructions are legal, for a given firmware
version.

For maintainability, I suspect it would be best to do this with conditional
logic, rather than having mutliple versions of the code generator.

At some point it would be nice if we could get hold of documentation for
the op-codes supported on older versions of the firmware.

Neil
-- 
Neil Durant
<nd...@us...>

Re: [Oopic-compiler-devel] OOpic firmware versions and code generation impact

[Neil D. <nd...@us...>]

D. Daniel McGlothin wrote:
> However, since the firmware commands (the op-codes) also vary by version,
> won't the generator also need to be firmware aware?

I've just spotted something else in the op-codes.  Look at op-code 128,
"Aversion_Version".  The description says:

  "Compares the top stack item to the firmware version. Resets the OOPic if
  not equal or above."

This suggests the OOPic is backwards-compatible with code targeting older
OOPics, otherwise this instruction would be pointless.

So this indicates that our code generator can be firmware-independent for
all of the op-codes supported on the first firmware version, and then we
can have conditional logic to allow the use of newer op-codes when
targeting newer firmware versions wherever it is appropriate.

My gut feeling is that the newly-added op-codes are either to allow
optimisations to be made, or special instructions needed for the newer VC
objects.

Neil
-- 
Neil Durant
<nd...@us...>