Example:
set I0, 1e20
end
Results in:
(error) line 2: parse error, unexpected IDENTIFIER, expecting '\n'
Didn't create output asm.
A larger example is BASIC's Connect-4 game:
c:> cd parrot\languages\basic\compiler
c:> compile.pl samples\conn4.bas
c:> ..\..\..\languages\imcc\imcc.exe TARG_test.pasm
Results in:
(error) line 4329: parse error, unexpected IDENTIFIER, expecting '\n'
Didn't create output asm.
Should it, though? Although it would be pretty convienient, I think
that handling scientific notation would be an unnecessary complication
for IMCC, and it would be better handled by the compilers that target
it. (As in, the compiler converts scientific notation to decimal form
during compilition to IMCC code.)
--
This message was sent using 3wmail.
Your fast free POP3 mail client at www.3wmail.com
Not my call. The current assembler does the Right Thing WRT this notation
and I'd want numeric constants handled somewhere. :)
First it's my understanding that the Parrot assembler does support
scientific notation, so IMCC should also. Second we need to handle
BigFloat values and I don't really want to have to express 1e12345
as a 12345+ length char string. On a related note does IMCC have a
token or line length limit?
--
Mark Biggar
ma...@biggar.org
mark.a...@attbi.com
> On a related note does IMCC have a
> token or line length limit?
Not currently, see BUGS. But there ought to be one. There are several
places where e.g. an intermediate string is fixed with size 512 or so.
We need some kind of notation for long string constants, that allow for
reasonable line length limit.
leo
>
> set I0, 1e20
Currently it has to be:
set I0, 1.e20 # dot inside
leo