characters are sign-extended when they shouldn't

[GoogleCodeExporter]

I came across an UCS2 encoded source file which uses ASCII characters in the 
$80-$FF range. Those byte values get sign-extended and effectively corrupt e.g. 
the PASM insn (e4 ff ff ff vs e4 70 eb a0).

Another issue: The Euro sign is officially encoded as $20AC. The PropTool and 
bst seem to convert this to $A4 and work with that. The SPIN compiler treats it 
as $FFAC (sign-extended word).

Apart from the latter, shouldn't the compiler e.g. place $20AC into the table 
as intended rather than convert it to something else, i.e. $00A4?

Original issue reported on code.google.com by marko.lu...@kyi.biglobe.ne.jp on 2 Feb 2012 at 12:20

Attachments:

• bel-keyb.spin

[GoogleCodeExporter]

I'll handle this one.

Original comment by reltham on 4 Feb 2012 at 5:04

• Changed state: Accepted

[GoogleCodeExporter]

Changed to High Priority.

Original comment by reltham on 4 Feb 2012 at 5:04

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

The compiler itself only accepts what it calls PASCII. The wrapper code 
converts the unicode into PASCII by remapping the characters it "cares" about 
into the range 0 to 255. That's why the $20AC becomes $A4. My wrapper code was 
incorrectly using a signed word during the remapping. The fix will be in soon.

Original comment by reltham on 4 Feb 2012 at 6:23

[GoogleCodeExporter]

> The compiler itself only accepts what it calls PASCII ...

Fair enough. As long as it's consistent.

Original comment by marko.lu...@kyi.biglobe.ne.jp on 4 Feb 2012 at 7:04

[GoogleCodeExporter]

This issue was closed by revision r31.

Original comment by reltham on 6 Feb 2012 at 4:44

• Changed state: Fixed