Shop OBEX P1 Docs P2 Docs Learn Events
flexspin compiler for P2: Assembly, Spin, BASIC, and C in one compiler - Page 10 — Parallax Forums

flexspin compiler for P2: Assembly, Spin, BASIC, and C in one compiler

178101213116

Comments

  • msrobots wrote: »
    Now have another one. Is the terminal used by spin2gui part of fastspin or is it part of the loader?
    It's part of loadp2. The division of labor is:

    - fastspin takes source code (Spin, PASM, BASIC, C) and turns it into a binary file that the P2 can execute
    - loadp2 talks to the P2; it downloads the binary produced by fastspin and then (optionally) listens for serial communication
    - spin2gui puts a GUI in front of those two
    Because it looks like the terminal is just half-duplex, while receiving characters it does not send any back.
    What exactly do you mean? Do you mean that while there are bits being transmitted by the P2 that the PC is not transmitting? It seems like this would be tricky to test with the built in terminal.

    I'm pretty sure loadp2 just uses the operating system serial port I/O routines, which should be full duplex (the OS has some kind of buffer, if only one character in the UART hardware).
    One other thing you got me with is changing the terminal baud rate from 2_000_000 to 230_400.
    Sorry! I forgot to highlight that in the release notes. It's for compatibility with the Mac and with p2gcc.

    Thanks,
    Eric
  • "half-duplex" was used as a terminal mode that would be selected when the data device would not echo characters back to the terminal. Now it is referred to more appropriately as "echo on".

    Wow, I'm old :disappointed:
  • Cluso99Cluso99 Posts: 18,066
    ke4pjw wrote: »
    "half-duplex" was used as a terminal mode that would be selected when the data device would not echo characters back to the terminal. Now it is referred to more appropriately as "echo on".

    Wow, I'm old :disappointed:
    Only if you know what an ASR33 is ;)
  • Cluso99 wrote: »
    ke4pjw wrote: »
    "half-duplex" was used as a terminal mode that would be selected when the data device would not echo characters back to the terminal. Now it is referred to more appropriately as "echo on".

    Wow, I'm old :disappointed:
    Only if you know what an ASR33 is ;)

    LOL
  • Only if you know that teletype hot oil smell.... Mmmmm
  • ke4pjw wrote: »
    "half-duplex" was used as a terminal mode that would be selected when the data device would not echo characters back to the terminal. Now it is referred to more appropriately as "echo on".
    That may be an informal usage of "half-duplex", but technically "half-duplex" means that the communication channel can transmit in only one direction at a time -- you can send, or you can receive, and you can do each in turn, but you can't do both simultaneously. @msrobots was testing a full duplex serial implementation for P2, so I'm sure he meant the technical definition. As I said, the loadp2 terminal uses the operating system's routines, which as far as I know should support full duplex -- but it'll be hard to actually make the loadp2 terminal do full duplex. Maybe cutting and pasting a bunch of text into the terminal while the P2 is sending would be a good test for that.

    Let's not get too far off-topic though, please :)
  • ersmith wrote: »
    ke4pjw wrote: »
    "half-duplex" was used as a terminal mode that would be selected when the data device would not echo characters back to the terminal. Now it is referred to more appropriately as "echo on".


    Let's not get too far off-topic though, please :)

    Sorry. I should be the LAST one to pull OT.
  • ersmith wrote: »
    There are new releases of fastspin(3.9.16) and spin2gui.

    @AntoineDoinel : I removed the call to _wfopen_s and just used fopen. This may cause some problems with file names that are encoded in UTF-8 which don't fit in the current Windows code page, but I don't think that's a big issue.

    Now it works on the little EeePC too! :smile:
    Eric, again thanks a lot for looking into this.
  • msrobotsmsrobots Posts: 3,701
    edited 2019-01-30 21:27
    Yes, exactly, I am testing full duplex and the terminal does not accept any chars from the user to send to the P2 while the P2 is outputting data to the PC to display. Thus half-duplex.

    Last night I spend some time to figure out how to use @Cluso99's con section to calculate the values for clkset() in fastspin.

    I got stuck for some moment until I realized that you use OSC

    _XOSC = %01 '15pF ' %00=OFF, %01=OSC, %10=15pF, %11=30pF

    while @Cluso99 uses 15pF

    _XOSC = %10 '15pF ' %00=OFF, %01=OSC, %10=15pF, %11=30pF

    what exacly is the difference there, what would be better and why?

    I really like the calculation with constants @Cluso99 did here a copy for reference
    CON
      _XTALFREQ     = 20_000_000                                    ' crystal frequency
      _XDIV         = 4             '\                              '\ crystal divider                      to give 5.0MHz
      _XMUL         = 64            '| 160MHz                       '| crystal / div * mul                  to give 320MHz
      _XDIVP        = 2             '/                              '/ crystal / div * mul /divp            to give 160MHz
      _XOSC         = %01                                   '15pF   ' %00=OFF, %01=OSC, %10=15pF, %11=30pF
      _XSEL         = %11                                   'XI+PLL ' %00=rcfast(20+MHz), %01=rcslow(~20KHz), %10=XI(5ms), %11=XI+PLL(10ms)
      _XPPPP        = ((_XDIVP>>1) + 15) & $F                       ' 1->15, 2->0, 4->1, 6->2...30->14
      _CLOCKFREQ    = _XTALFREQ / _XDIV * _XMUL / _XDIVP            ' internal clock frequency                
      _SETFREQ      = 1<<24 + (_XDIV-1)<<18 + (_XMUL-1)<<8 + _XPPPP<<4 + _XOSC<<2  ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_00  ' setup  oscillator
    '  _ENAFREQ      = _SETFREQ + _XSEL                                             ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_ss  ' enable oscillator
    
      _clkfreq = 160_000_000
      _clkmode = $010c3f04
    
    

    using _XOSC = %01

    _CLOCKFREQ gives the same value you use as _clkfreq
    _SETFREQ gives the same value you use as _clkmode

    do you use the constants
    _clkfreq = 160_000_000
    _clkmode = $010c3f04
    somewhere else in the code or would I be fine to use


    clkset(_SETFREQ, _CLOCKFREQ)
    instead of
    clkset(_clkmode, _clkfreq)

    and be OK?

    Enjoy!

    Mike
  • msrobots wrote: »
    Yes, exactly, I am testing full duplex and the terminal does not accept any chars from the user to send to the P2 while the P2 is outputting data to the PC to display. Thus half-duplex.
    Hmmm... I see that the loadp2 code does wait for all characters to be emptied from the serial buffer before trying to read the keyboard. But I think that should happen pretty quickly, at least on a reasonably fast PC. Have you tried a lower baud rate? In principle it should be possible to do full-duplex, but I don't know the Windows serial code well enough to know what kind of timeout is the default.
    Last night I spend some time to figure out how to use @Cluso99's con section to calculate the values for clkset() in fastspin.

    I got stuck for some moment until I realized that you use OSC

    _XOSC = %01 '15pF ' %00=OFF, %01=OSC, %10=15pF, %11=30pF

    while @Cluso99 uses 15pF

    _XOSC = %10 '15pF ' %00=OFF, %01=OSC, %10=15pF, %11=30pF

    what exacly is the difference there, what would be better and why?

    I honestly don't know the difference -- I think I saw in the video thread that people were using OSC, so I used that, but I don't claim to be an expert. There still seems to be an ongoing discussion about which settings are best. Which is one reason I thought we should make clock settings explicit on P2, at least for now.
    do you use the constants
    _clkfreq = 160_000_000
    _clkmode = $010c3f04
    somewhere else in the code or would I be fine to use

    clkset(_SETFREQ, _CLOCKFREQ)
    instead of
    clkset(_clkmode, _clkfreq)

    Yes, you can use any names you like for the clkset(). Someday _clkfreq and _clkmode will be used for the default clock settings, but it'll always be possible to override them with an explicit clkset(). And of course you can define them any way you like.

  • Dave HeinDave Hein Posts: 6,347
    edited 2019-01-30 22:28
    @msrobots, I tried the following program using p2gcc, and it seems to work OK.
    #include <stdio.h>
    #include <propeller.h>
    
    int val = '?';
    int stack[100];
    
    void serialin(void *parm)
    {
        while(1)
            val = getch();
    }
    
    void main()
    {
        sleep(1);
        cogstart(serialin, NULL, stack, sizeof(stack));
        while (1)
        {
            putch(val);
            if (val == '~')
                sleep(5);
        }
    }
    
    Cog 0 prints the value of "val" in a loop, and cog 1 saves the value it reads from the serial port into "val". I can type in characters, and I see the output echoing what I type in. I tried pasting text into the window, and that work also. I added the test for the "~" character so I can pause the output for 5 seconds.
  • Dave Hein wrote: »
    @msrobots, I tried the following program using p2gcc, and it seems to work OK.
    #include <stdio.h>
    #include <propeller.h>
    
    int val = '?';
    int stack[100];
    
    void serialin(void *parm)
    {
        while(1)
            val = getch();
    }
    
    void main()
    {
        sleep(1);
        cogstart(serialin, NULL, stack, sizeof(stack));
        while (1)
        {
            putch(val);
            if (val == '~')
                sleep(5);
        }
    }
    
    Cog 0 prints the value of "val" in a loop, and cog 1 saves the value it reads from the serial port into "val". I can type in characters, and I see the output echoing what I type in. I tried pasting text into the window, and that work also. I added the test for the "~" character so I can pause the output for 5 seconds.

    I will post later today on my full-duplex thread, this is not a fastspin issue, so off topic. But basically my smart pin driver hammers the terminal with output as soon as it can output and the terminal gets no sleep(5) in between. Then it never sends a char back. Putting some waitx in the code did let the terminal finish the transmit and then it send back the user input. I am running some stress tests for the serial driver on other cogs, display the result (constantly) and wait for a key press to stop the test. And if I do not throttle/wait in between my outputs I never get a key press.

    Enjoy!

    Mike
  • ersmith wrote: »
    msrobots wrote: »
    Yes, exactly, I am testing full duplex and the terminal does not accept any chars from the user to send to the P2 while the P2 is outputting data to the PC to display. Thus half-duplex.
    Hmmm... I see that the loadp2 code does wait for all characters to be emptied from the serial buffer before trying to read the keyboard. But I think that should happen pretty quickly, at least on a reasonably fast PC. Have you tried a lower baud rate? In principle it should be possible to do full-duplex, but I don't know the Windows serial code well enough to know what kind of timeout is the default.
    Last night I spend some time to figure out how to use @Cluso99's con section to calculate the values for clkset() in fastspin.

    I got stuck for some moment until I realized that you use OSC

    _XOSC = %01 '15pF ' %00=OFF, %01=OSC, %10=15pF, %11=30pF

    while @Cluso99 uses 15pF

    _XOSC = %10 '15pF ' %00=OFF, %01=OSC, %10=15pF, %11=30pF

    what exacly is the difference there, what would be better and why?

    I honestly don't know the difference -- I think I saw in the video thread that people were using OSC, so I used that, but I don't claim to be an expert. There still seems to be an ongoing discussion about which settings are best. Which is one reason I thought we should make clock settings explicit on P2, at least for now.
    do you use the constants
    _clkfreq = 160_000_000
    _clkmode = $010c3f04
    somewhere else in the code or would I be fine to use

    clkset(_SETFREQ, _CLOCKFREQ)
    instead of
    clkset(_clkmode, _clkfreq)

    Yes, you can use any names you like for the clkset(). Someday _clkfreq and _clkmode will be used for the default clock settings, but it'll always be possible to override them with an explicit clkset(). And of course you can define them any way you like.

    OK then that is it to calculate both values needed for clkset()
    CON
      _XTALFREQ     = 20_000_000                                    ' crystal frequency
      _XDIV         = 4             '\                              '\ crystal divider                      to give 5.0MHz
      _XMUL         = 64            '| 160MHz                       '| crystal / div * mul                  to give 320MHz
      _XDIVP        = 2             '/                              '/ crystal / div * mul /divp            to give 160MHz
      _XOSC         = %01                                   '15pF   ' %00=OFF, %01=OSC, %10=15pF, %11=30pF
      _XSEL         = %11                                   'XI+PLL ' %00=rcfast(20+MHz), %01=rcslow(~20KHz), %10=XI(5ms), %11=XI+PLL(10ms)
      _XPPPP        = ((_XDIVP>>1) + 15) & $F                       ' 1->15, 2->0, 4->1, 6->2...30->14
      _clkfreq    = _XTALFREQ / _XDIV * _XMUL / _XDIVP            ' internal clock frequency                
      _clkmode      = 1<<24 + (_XDIV-1)<<18 + (_XMUL-1)<<8 + _XPPPP<<4 + _XOSC<<2  ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_00  ' setup  oscillator
    

    cool.

    Mike
  • Cluso99Cluso99 Posts: 18,066
    _XOSC
    This is a hardware option to match the oscillator or crystal used.
    If it is a crystal, what loading capacitance is applied by the P2 (off, 15pF or 30pF).
    If it is an oscillator, use %01=OSC. This also worked too for a crystal on the P2-ES board.

    If you select the wrong capacitance for your crystal, it will most likely still work, just slightly off-frequency.
  • Dave HeinDave Hein Posts: 6,347
    edited 2019-01-31 02:45
    msrobots wrote: »
    I will post later today on my full-duplex thread, this is not a fastspin issue, so off topic. But basically my smart pin driver hammers the terminal with output as soon as it can output and the terminal gets no sleep(5) in between. Then it never sends a char back. Putting some waitx in the code did let the terminal finish the transmit and then it send back the user input. I am running some stress tests for the serial driver on other cogs, display the result (constantly) and wait for a key press to stop the test. And if I do not throttle/wait in between my outputs I never get a key press.
    The sleep(5) in my program only happens when it receives a "~" character. That's so I can freeze the screen for a few seconds to look at it. If I don't send a "~" then the program hammers the terminal with output similar to yours. However, I don't see a problem with receiving characters. One difference with my setup is that my loadp2 was built using Cygwin, and the one that comes with spin2gui is most likely built under MinGW. I'll try the MinGW version to see if that makes a difference.

    EDIT: I tried the MinGW version of loadp2, and seem to work the same as the Cygwin version. I tried increasing the baud rate from 115200 to 1000000, and it worked OK until I pasted in some text. There terminal hung after that. It's may be an issue with the Windows serial driver at high baud rates.
  • jmgjmg Posts: 15,140
    msrobots wrote: »
    I got stuck for some moment until I realized that you use OSC

    _XOSC = %01 '15pF ' %00=OFF, %01=OSC, %10=15pF, %11=30pF

    while @Cluso99 uses 15pF

    _XOSC = %10 '15pF ' %00=OFF, %01=OSC, %10=15pF, %11=30pF

    what exacly is the difference there, what would be better and why?

    That field sets the Xtal load capacitance, and below are the measured changes in ppm, from an ideal 20.000MHz, on a coolish board.
    (A warmer board drops slightly in MHz.)

    %CC     XI status   XO status       XI/XO Z   XI/XO caps        Measures      ppm change  PLL                                   
    %00     ignored     float           Hi-Z      OFF
    %01     input       600-ohm drive   1M-ohm    OFF            -> 1000.1439Hz   +144   ppm     
    %10     input       600-ohm drive   1M-ohm    15pF per pin   ->  999.9933Hz   -6.700 ppm 
    %11     input       600-ohm drive   1M-ohm    30pF per pin   ->  999.9472Hz   -53 ppm      
    

    All work, but the best value for the Xtal on the P2-Eval is 15pF, but even 0pF does still oscillate but with the highest error.

    0pF would not usually be selected with a Xtal, unless you were testing frequency effects or margins.
    You would select 0pF when AC-Coupling a clipped sine (VC) TXCO

  • ersmithersmith Posts: 5,900
    edited 2019-02-03 13:24
    There's a new spin2gui release: now with a Lisp interpreter as one of the samples (so in one package you get PASM, Spin, BASIC, C, and Lisp).

    To run a lisp program, load up samples/proplisp/lisp.c and compile and run. You'll be presented with a ">" prompt. You can then enter something like:
    (while #t (begin (pintoggle 58)(waitms 100)))
    
    to blink pin 58. Press CTRL-B in the terminal to break out of the while loop. There's a bit of documentation in the samples/proplisp/README.md file.

    Hello world is:
    (print "hello, world" nl)
    
    or even just
    "hello, world"
    

    The Lisp interpreter itself is nothing special; it's pretty slow and doesn't have a lot of features. Mainly it's useful because it's written in C and doesn't use much of the standard library, so it was a good platform for testing fastspin's C support and shaking out bugs (which it did a lot of).
  • jmgjmg Posts: 15,140
    ersmith wrote: »
    There's a new spin2gui release: now with a Lisp interpreter as one of the samples (so in one package you get PASM, Spin, BASIC, C, and Lisp).

    ...The Lisp interpreter itself is nothing special; it's pretty slow and doesn't have a lot of features. Mainly it's useful because it's written in C and doesn't use much of the standard library, so it was a good platform for testing fastspin's C support and shaking out bugs (which it did a lot of).

    Wow, even more impressive ! :)
    That means the C support must be moving along quite quickly.
    How does it go now compiling the Blockly-generated C code ?

  • jmg wrote: »
    Wow, even more impressive ! :)
    That means the C support must be moving along quite quickly.
    How does it go now compiling the Blockly-generated C code ?

    To be honest, I've never used Blockly in any form -- it's not something that appeals to me personally, and I suspect that there won't be a lot of demand for it among early adopters of the P2. That said, eventually of course I'd like to make sure that fastspin can compile Blockly generated code. It just hasn't been a priority yet.
  • ersmith wrote: »
    jmg wrote: »
    Wow, even more impressive ! :)
    That means the C support must be moving along quite quickly.
    How does it go now compiling the Blockly-generated C code ?

    To be honest, I've never used Blockly in any form -- it's not something that appeals to me personally, and I suspect that there won't be a lot of demand for it among early adopters of the P2. That said, eventually of course I'd like to make sure that fastspin can compile Blockly generated code. It just hasn't been a priority yet.
    I think the Simple Libraries will have to be ported to fastspin before BlocklyProp output will compile.
  • ersmith,
    The BlocklyProp generated code itself is quite simple, I bet your compiler would already handle that part. However, there are a couple of things that will be issues, one is that, like SimpleIDE, it handles all the linking of libraries and multiple c files based on what headers you include, and two, a bunch of the libraries used have spin modules with P1 pasm hooked in via the propgcc mechanism for that. It uses SimpleIDE and the Simple Libraries (Learn folders) to compile the C code generated by the blocks via it's cloud compiler setup.

    So, in order to compile BlocklyProp generated code, we'd need all the Simple Libraries ported to P2, and either add in the auto-linking thing, or require manually adding in all the linking information for a given program. If you have the same builtin names as propgcc (I think you do), then a lot of the libraries will likely work as is, just need to sort out the ones that use Spin modules with P1 PASM.

    BTW, fantastic work on this compiler/ide so far! I'm thinking we should just all get behind this effort and use it as the "official" one... I'm not sure why I should spend the time to update OpenSpin for P2, when this is already better than that would be.
  • David BetzDavid Betz Posts: 14,511
    edited 2019-02-03 21:55
    Roy Eltham wrote: »
    BTW, fantastic work on this compiler/ide so far! I'm thinking we should just all get behind this effort and use it as the "official" one... I'm not sure why I should spend the time to update OpenSpin for P2, when this is already better than that would be.
    I agree that fastspin could be the official Spin native compiler for P2 as well as the official C compiler. However, some people will still want a byte code compiler. At least that is what people here keep saying. If that is true then there is still a place for OpenSpin once Chip gets his Spin2 compiler working to use as a reference. I haven't heard much lately about Chip's compiler. Has he said anything about when it might be available?
  • Roy ElthamRoy Eltham Posts: 2,996
    edited 2019-02-03 22:13
    Also, I think the new Target thing to compile is MicroPython (or maybe CircuitPython (Adafruit's variant of it)). It's written in C/C++ C99. I know Ken would like that since education seems to love Python now thanks to the BBC micro:bit and other things.
  • Roy Eltham wrote: »
    Also, I think the new Target thing to compile is MicroPython (or maybe CircuitPython (Adafruit's variant of it)). It's written in C/C++. I know Ken would like that since education seems to love Python now thanks to the BBC micro:bit and other things.
    Hmmm... I don't think Eric intends to implement C++ in fastspin so I guess that means we need GCC after all. It's too bad that there might end up being two C compiler efforts needed. We have few enough tools resources as it is without having to spread them across two similar projects.
  • Roy ElthamRoy Eltham Posts: 2,996
    edited 2019-02-03 22:12
    David,
    Eric has said he intends for his compiler to have a subset of C++ stuff. Might be enough? I have not looked at the MicroPython/CircuitPython code at all, it may not use much C++ at all? I will have to take a look at it and see.

    Edit: Just looked at their homepage, and it says MicroPython is written in C99. So I think we may be good.
  • Roy Eltham wrote: »
    David,
    Eric has said he intends for his compiler to have a subset of C++ stuff. Might be enough? I have not looked at the MicroPython/CircuitPython code at all, it may not use much C++ at all? I will have to take a look at it and see.

    Edit: Just looked at their homepage, and it says MicroPython is written in C99. So I think we may be good.
    That's encouraging. We just need to check to see if Eric intends to support C99. I'm not sure what C standard he is currently following. In any case, I think fastspin is Parallax's best path to getting C and maybe some C++ for the P2 since Eric is already working on it and has C mostly done. The remainder of the work is implementing or porting the libraries.
  • jmgjmg Posts: 15,140
    ersmith wrote: »
    .... Mainly it's useful because it's written in C and doesn't use much of the standard library, so it was a good platform for testing fastspin's C support and shaking out bugs (which it did a lot of).

    Do you know which C version that Lisp interpreter required ? Maybe that is already a C99 test ?

  • Roy Eltham wrote: »
    The BlocklyProp generated code itself is quite simple, I bet your compiler would already handle that part. However, there are a couple of things that will be issues, one is that, like SimpleIDE, it handles all the linking of libraries and multiple c files based on what headers you include,
    I think we should be able to handle that. Fastspin currently has a way to specify in a header file that a library file needs to be included, e.g. in time.h there are defines like:
         time_t  time(time_t *) _IMPL("libc/time/time.c");
        double  difftime(time_t time2, time_t time1) _IMPL("libc/time/difftime.c");
    
    which says that if an unresolved reference to "time" is found then we should load "libc/time/time.c", for "difftime" we load "libc/time/difftime.c", and so on. We still have to see how well this performs for large libraries, but for small ones it seems to work.
    and two, a bunch of the libraries used have spin modules with P1 pasm hooked in via the propgcc mechanism for that. It uses SimpleIDE and the Simple Libraries (Learn folders) to compile the C code generated by the blocks via it's cloud compiler setup.
    Well, compiling Spin modules with fastspin isn't a problem :) so if the original Spin code is still available we can use that directly. For example the C code for the Lisp interpreter uses SmartSerial.spin2 via:
    struct __using("PropSerial/SmartSerial.spin2") fds;
    ...
    fds.start(63, 62, 0, 23400);
    
    BTW, fantastic work on this compiler/ide so far! I'm thinking we should just all get behind this effort and use it as the "official" one...

    Thank you very much! It'd be great if some more people could start work on porting libraries to fastspin (and finding bugs in it :) ). I need to work on some "internals" documentation as well, but there hasn't been time yet :(.

    Thanks,
    Eric
  • David Betz wrote: »
    I agree that fastspin could be the official Spin native compiler for P2 as well as the official C compiler. However, some people will still want a byte code compiler. At least that is what people here keep saying.
    There's no reason in principle that fastspin couldn't generate bytecode. I didn't see any point in doing that for P1 (there was already a perfectly good bytecode compiler in the form of openspin), and haven't had time to look at it for P2 yet.

    Doing a kind of CMM mode (where we use PASM instructions, but compressed) should be very easy in fastspin; again, I just haven't had time to get to it. That would just be a slight variation of the existing ASM backend. For real bytecode like the Spin2 interpreter we'd want a new backend. I've tried to make the compiler modular enough to make that possible (there are already backends to produce C code and ASM) but I'm sure there will be details that'll need working out.

  • David Betz wrote: »
    Roy Eltham wrote: »
    Edit: Just looked at their homepage, and it says MicroPython is written in C99. So I think we may be good.
    That's encouraging. We just need to check to see if Eric intends to support C99.
    Yes, I do intend to support C99, and I think it's most of the way there. There are still some significant missing pieces:

    - structure assignment / return (this may partially work, but it's definitely not done)
    - nested scopes (e.g. "int n" inside an if() block is different from "int n" at the start of the function)
    - bitfields
    - static functions aren't working properly right now (if there are two static functions in different files with the same name they will conflict). That's more of a bug than missing feature, since the parser handles it and it's supposed to work
    - standard library support
    - long long support (not strictly required for C99, I think, but a lot of programs use it)
    - true double support (right now "double" is treated the same as "float"; we may be able to get away with that in practice, lots of PropGCC programs were compiled with 32 bit doubls)
    - many, many bugs I'm sure!

Sign In or Register to comment.