bugs in samples?

[zmafoox]

Greetings,

It seems every time I'm about to release the next jalv2 version something crops up. Today I'm compiling all samples and ran into the following with sample/16f648a_serial_format.jal

lib/usart_common.jal:62: warning: boolean expression expected

it turns out this is caused by:

const usart_hw_serial = true    -- true = RS232, false = SPI;@jallib section serial

arguably this is indeed an error, what do others think?

[Rob Hamerling]

Hi Kyle,

On 07/12/12 06:21 pm, zmafoox wrote:

> It seems every time I'm about to release the next jalv2 version

Glad to hear there is still hope for a new compiler version ;)

> something crops up. Today I'm compiling all samples and ran into the
> following with sample/16f648a_serial_format.jal
>
> lib/usart_common.jal:62: warning: boolean expression expected
>
> it turns out this is caused by:
>
> const usart_hw_serial = true -- true = RS232, false = SPI;@jallib
> section serial
>
> arguably this is indeed an error, what do others think?
>

The compiler - at least the version you are working on - seems to be
stricter than previous versions: I don't get this warning with 2.4o, not
even with the latest published 2.4p-beta. It seems to insist on getting
a bit-value.

The compiler documentation is not completely clear in this: the
definition of 'lexpr' says that the result is '0' or '1', but it does
not say it must be a bit-value. The confusing part of the definition of
'lexpr' is:
'and 1 if the expression is anything other than 0'
I interpret this as: it must not be a bit value but I (the compiler)
treat every non-zero variable (regardless type) as a bit '1'.

Only if 'lexpr' must evaluate to a bit-value you can say the sample is
in error, and the proper declaration would then be:

const bit usart_hw_serial = TRUE

BTW: - this is the default in usart_common.jal when
usart_hw_serial is not specified by the program
- 'TRUE' is defined as bit in constants_jallib.jal

My �.02

Regards, Rob.



--
R. Hamerling, Netherlands --- http://www.robh.nl

[zmafoox]

Greetings,

On Thursday, July 12, 2012 11:54:01 AM UTC-7, RobH wrote:

Glad to hear there is still hope for a new compiler version ;)

The delay's is your fault :) I decided to fix record initialization to allow for constant records, and make things work better in general.

The compiler - at least the version you are working on - seems to be
stricter than previous versions: I don't get this warning with 2.4o, not
even with the latest published 2.4p-beta.  It seems to insist on getting
a bit-value.

The new initialization code works more consistently. Long ago (prior to June 2007) the controlling expression in a conditional could be anything and follows the C rules -- 0 meant FALSE, anything else was TRUE. Folks requested that I return to the original JAL behavior which required the controlling expression to be a BIT.

Only if 'lexpr' must evaluate to a bit-value you can say the sample is
in error, and the proper declaration would then be:

      const bit usart_hw_serial = TRUE

BTW: - this is the default in usart_common.jal when
        usart_hw_serial is not specified by the program
      - 'TRUE' is defined as bit in constants_jallib.jal

Right, that's why I think the bug is in the examples as they do not follow the library. Would anyone be offended if the new compiler causes warnings in the  existing samples?  There are ~50 cases of this.

--kyle

[Rob Hamerling]

Hi Kyle,

On 07/13/12 05:38 pm, zmafoox wrote:

> The new initialization code works more consistently. Long ago (prior to
> June 2007) the controlling expression in a conditional could be anything
> and follows the C rules -- 0 meant FALSE, anything else was TRUE. Folks
> requested that I return to the original JAL behavior which required the
> controlling expression to be a BIT.

That is probably before the time I got involved with JalV2.

>
> Would anyone be offended if the new compiler causes
> warnings in the existing samples? There are ~50 cases of this.

Difficult to say for sure, but I can hardly believe anyone would
protest. Hopefully most of these cases are in generated examples. That
would reduce the amount of work. Anyway it won't be a difficult job once
you provide a new (beta) compiler.