Pascal - Githubissues

tcpipchip commented 2 years ago

Hi, unzip the Pascal on
osboxes@osboxes:~/nuttx$ ls
apps  nuttx  Pascal
osboxes@osboxes:~/nuttx$

in nuttx/apps i type
ln -s /home/osboxes/nuttx/Pascal

then
./tools/configure.sh esp32-devkitc:nsh

and got

mkkconfig in /home/osboxes/nuttx/apps/industry
make[3]: Leaving directory '/home/osboxes/nuttx/apps/industry'
mkkconfig in /home/osboxes/nuttx/apps
make[2]: Leaving directory '/home/osboxes/nuttx/apps'
make[1]: Leaving directory '/home/osboxes/nuttx/nuttx'
**/home/osboxes/nuttx/Pascal/papps/Kconfig.papps:23:warning: ignoring unsupported character '$'**
#
# configuration written to .config
#

in nuttx/apps i can see pascal

osboxes@osboxes:~/nuttx/apps$ dir
Application.mk  crypto      fsutils   include   LICENSE    mlearning  nshlib     system
boot        Directory.mk    gpsutils  industry  Make.defs  modbus     pascal     testing
builtin     DISCLAIMER-WIP  graphics  interpreters  Makefile   netutils   platform   tools
canutils    examples    import    Kconfig   math       NOTICE     README.md  wireless
osboxes@osboxes:~/nuttx/apps$ cd pascal
osboxes@osboxes:~/nuttx/apps/pascal$ 

And no Pascal on make menuconfig

But, after going into the pascal folder, i executed make menuconfig, then back to nuttx nutxx folder and now i can see on make menuconfig the pascal option

compiling but got this error

make[4]: Leaving directory '/home/osboxes/nuttx/Pascal/tools'
make[4]: Entering directory '/home/osboxes/nuttx/Pascal/insn16'
make[5]: Entering directory '/home/osboxes/nuttx/Pascal/insn16/libexec'
CC:  libexec_runloop.c
CC:  libexec_debug.c
libexec_debug.c:69:25: warning: 'enum command_e' declared inside parameter list will not be visible outside of this definition or declaration
                    enum command_e cmd, uint32_t value);
                         ^~~~~~~~~
libexec_debug.c:118:57: warning: 'enum command_e' declared inside parameter list will not be visible outside of this definition or declaration
 static void pdbg_ExecCommand(struct libexec_s *st, enum command_e cmd, uint32_t value)
                                                         ^~~~~~~~~
libexec_debug.c:118:67: error: parameter 2 ('cmd') has incomplete type
 static void pdbg_ExecCommand(struct libexec_s *st, enum command_e cmd, uint32_t value)
                                                    ~~~~~~~~~~~~~~~^~~
libexec_debug.c: In function 'pdbg_ExecCommand':
libexec_debug.c:122:5: error: 'struct libexec_s' has no member named 'lastCmd'
   st->lastCmd   = cmd;
     ^~
libexec_debug.c:123:5: error: 'struct libexec_s' has no member named 'lastValue'
   st->lastValue = value;
     ^~
libexec_debug.c:127:10: error: 'eCMD_NONE' undeclared (first use in this function); did you mean 'eOPEN_NONE'?
     case eCMD_NONE:   /* Do nothing */
          ^~~~~~~~~
          eOPEN_NONE
libexec_debug.c:127:10: note: each undeclared identifier is reported only once for each function it appears in
libexec_debug.c:130:10: error: 'eCMD_RESET' undeclared (first use in this function); did you mean 'ECONNRESET'?
     case eCMD_RESET:  /* Reset */
          ^~~~~~~~~~
          ECONNRESET
libexec_debug.c:134:9: error: 'struct libexec_s' has no member named 'lastCmd'
       st->lastCmd = eCMD_NONE;
         ^~
libexec_debug.c:137:10: error: 'eCMD_RUN' undeclared (first use in this function)
     case eCMD_RUN:    /* Run */
          ^~~~~~~~
libexec_debug.c:144:10: error: 'eCMD_STEP' undeclared (first use in this function)
     case eCMD_STEP:   /* Single Step (into)*/
.
.
.

Looks that now is config option on Make menuconfig, right 

Thanks!

tcpipchip commented 2 years ago

I enabled the debug and good a lot of progress on compile...

now got

CC: pfdlineno.c CC: pflabel.c CC: pflineno.c CC: pofferr.c CC: pfdbginfo.c CC: pfswap.c make[4]: Leaving directory '/home/osboxes/nuttx/Pascal/libpoff' make[4]: Entering directory '/home/osboxes/nuttx/Pascal/papps' make[5]: Entering directory '/home/osboxes/nuttx/Pascal/papps/pstart' make[5]: Nothing to be done for 'all'. make[5]: Leaving directory '/home/osboxes/nuttx/Pascal/papps/pstart' make[5]: Entering directory '/home/osboxes/nuttx/Pascal/papps/phello' phello.o1 make[5]: /home/osboxes/nuttx/Pascal/papps/phello/../../bin16/pascal: Command not found make[5]: [PasMakefile:74: phello.o1] Error 127 make[5]: Leaving directory '/home/osboxes/nuttx/Pascal/papps/phello' make[4]: [NxMakefile:77: phello/_all] Error 2 make[4]: Leaving directory '/home/osboxes/nuttx/Pascal/papps' make[3]: [tools/NuttX.mk:67: papps/_all] Error 2 make[3]: Leaving directory '/home/osboxes/nuttx/Pascal' make[2]: [Makefile:42: /home/osboxes/nuttx/apps/pascal_all] Error 2 make[2]: Leaving directory '/home/osboxes/nuttx/apps' make[1]: [Makefile:36: all] Error 2 make[1]: Leaving directory '/home/osboxes/nuttx/apps' make: [tools/LibTargets.mk:210: /home/osboxes/nuttx/apps/libapps.a] Error 2

patacongo commented 2 years ago

Thanks for your comments. I have not been running on NuttX over the past couple of weeks because I have been focused on language issues. I will look at this today and get back with you.

I was also using the Nuttx simulator. You can see the last configuration I used in pascal/configs/defconfig (unlabeld, undocumented).

And no Pascal on make menuconfig

That usually happens if NuttX in linked in after the apps_prefconfig or context make targets are run. You only get one shot to add applications. If you do 'make apps_distclean menuconfig' I think it should be there.

patacongo commented 2 years ago

Commit fc393cad668720d9ced20aa8375284a97a4e2684 should fix all of the issues that you list in the initial comments.

This error:

make[5]: /home/osboxes/nuttx/Pascal/papps/phello/../../bin16/pascal: Command not found

Has multiple causes which need to be addressed. These are discussed in https://github.com/patacongo/Pascal/blob/main/papps/pshell/README.md

As mentioned there, tasks are created currently only with posix_spawnp() which only runs files on in a mounted file system. For most standard embedded systems we need to use task_spawn() and run files from in-flash code. That is not implemented. For NSH, that is done with the logic in apps/builtin. At a minimum it needs the entry point which would be pas_main().

That would require a little more work to fix correctly. The posix_spawnp() call is in pascal/libexec/libexec_oslib.c. The correct fix will require some new configuration settings, but hacking in a work-around for now would be pretty easy. The work-around would just replaces posix_spawnp() with task_spawn() (and, of course adding the priority stack size parameter).

patacongo commented 2 years ago

This error:

make[5]: /home/osboxes/nuttx/Pascal/papps/phello/../../bin16/pascal: Command not found

The other think that needs to be addressed is building the file system image containing the Pascal executables (or developing an in-memory solution). There are lots of examples of creation of ROMFS image in the NuttX repository.

examples/bastest/Makefile:      $(Q) genromfs -f $@ -d $(TESTS_DIR) -V "BASTEST"
examples/elf/tests/Makefile:    $(Q) genromfs -f $@.tmp -d $(FSIMG_DIR) -V "ELFTEST"
examples/module/drivers/Makefile:       $(Q) genromfs -f $@.tmp -d $(FSROOT_DIR) -V "MODULETEST"
examples/nxflat/tests/Makefile: $(Q) genromfs -f $@.tmp -d $(ROMFS_DIR) -V "NXFLATTEST"
examples/posix_spawn/filesystem/Makefile:       $(Q) genromfs -f $@.tmp -d $(ROMFS_DIR) -V "POSIXSPAWN"
examples/romfs/Makefile:        @genromfs -h 1>/dev/null 2>&1 || { \
examples/romfs/Makefile:        @genromfs -f $@ -d testdir -V "ROMFS_Test" || { echo "genromfs failed" ; exit 1 ; }
examples/sotest/lib/Makefile:   $(Q) genromfs -f $@.tmp -d $(FSROOT_DIR) -V "SOTESTTEST"
examples/thttpd/content/Makefile.nxflat:        $(Q) genromfs -f $@.tmp -d $(ROMFS_DIR) -V "THTTPDTEST"
examples/unionfs/Makefile:      @genromfs -h 1>/dev/null 2>&1 || { \
examples/unionfs/Makefile:      @genromfs -f $@ -d atestdir -V "UNIONFS_FS1" || { echo "genromfs failed" ; exit 1 ; }
examples/unionfs/Makefile:      @genromfs -f $@ -d btestdir -V "UNIONFS_FS2" || { echo "genromfs failed" ; exit 1 ; }

There is discussion for these examples here: examples/README.md and here: nshlib/README.md and a tool that makes that easy at tools/mkromfsimg.sh

patacongo commented 2 years ago

I apologize for not having as much ready for you as I would have liked. I am developing the papps/Pshell which has forced me to disgress and focus on language issues. I am still on the same vector, just taking a little longer route than anticipated.

tcpipchip commented 2 years ago

No problem! unhurried! When have time, fix that last make[5]: /home/osboxes/nuttx/Pascal/papps/phello/../../bin16/pascal: Command not found Still fuzzy to me how to solve it. I am happy about all progress!

patacongo commented 2 years ago

I just built on the NuttX simulator and I saw the same problem. It is happening because it is trying to compile the Pascal programs under pascal/papps and cannot find the compiler:

make[5]: Entering directory 'bla-bla-bla/projects/pascal/papps/pstart'
CC:  pstart_main.c
make[5]: Leaving directory 'bla-bla-bla/projects/pascal/papps/pstart'
make[5]: Entering directory 'bla-bla-bla/projects/pascal/papps/phello'
  phello.o1
make[5]: bla-bla-bla/projects/pascal/papps/phello/../../bin16/pascal: No such file or directory

But of course we don't have a pascal compiler in the NuttX build (yet). In addition, the path to where the compiler binary is located is nonsense, The fix is very simple. It is in papps/NxMakefile; all of the calls into the Pascal Makefiles (the ones in PBUILDDIRS) must be disabled when CONFIG_PASCAL_TARGET_TOOLS is not defined.

CONFIG_PASCAL_TARGET_TOOLS probably should stay undefined until there is a want to invoke the memory-resident compiler (with task_spawn()).

tcpipchip commented 2 years ago

I have a question, Pascal folder has source code of a pascal compiler, the processor target GCC compiles this code, and creates a bin that will compile the source .PAS and get a bin to target processor ?

patacongo commented 2 years ago

First... with this commit: c1ef8cb36095bf9612816b4eda6700797d9d8654, I get a clean build on the simulator. It fails when I try to run because phello.pex does not exist on the simulator yet. This the the error I get at runtime:

ERROR: Error opening 'pshell.pex': 2
ERROR: Could not load pshell.pex

The errno "2" is ENOENT: the file or directory does not exist.

So, the next step to make progress would be to get the pascal executables on the target.

I have a question, Pascal folder has source code of a pascal compiler, the processor target GCC compiles this code, and creates a bin that will compile the source .PAS and get a bin to target processor ?

There are actually several tools needed produce executables. GCC also uses several tools ( for example, the compiler is cc1). GCC is just wrapper that coordinates all of the tools. Basically the Pascal compiler works like this:

pascal compiles .pas files to create .o1 temporary files. The compiler also produces a listing .lst file and and error file, .err file. the error output from the compiler itself is pretty primitive but I will, eventually, create a pretty error printer from the .err files.
The optimizer, popt, improves these and generates the .o object files
the linker, plink, links together mutliple object files to produce the pascal executable, the .pex file.
Other tools: plist dumps a pretty listing of the .pex file, prun is the run-time VM code.

There is some discussion in pascal/doc/PascalNotes.md but it is not very complete.

It would be friendly to have a wrapper program that hides all of this and removes the intermediate files but I do that with scripts.

I see two use cases:

The compiler resides on the host machine and only the run-time VM is on the target. In this case, we need to get the Pascal executable files onto the target in a file system or in memory (using xdd -include).
The compiler resides on the target and generates the executable on the fly as needed.

tcpipchip commented 2 years ago

Now I understood! Thanks to the complete info! Send some pictures of nuttx pascal emulator running

patacongo commented 2 years ago

I added a new configuration at pascal/configs/stm32f4discovery. This one resolves almost all issues by putting the .pex files on an SD card. But I was unable to test properly; I get read errors when trying to load the executable. Same SD card works fine with the same code on the host system so I am assuming a hardware issue.

All of my boards are very old and with the humidity here in Costa Rica, connectors don't last long. That is a frequent source of early hardware issues for me.

I suppose that the next thing to try would be an in-memory file system.

tcpipchip commented 2 years ago

Hi Nutt Wow, Costa Rica ! Then hablas Español tambien!¿ I am far 30 miles from beach, I have humidity problems too :) I am in Blumenau S.C, Brazil.

When goes all well, I hope make a pascal blog soon, in my list!

tcpipchip commented 2 years ago

hi, good morning

If i make again the GIT from Pascal, still do i need to make the git commit again ? Or did you already make the patch ?

tcpipchip commented 2 years ago

“ I suppose that the next thing to try would be an in-memory file system.”

Yes, that’s cool! I will intend to test here on stm32l071, esp32, nef52832 and finally nrf52840. If all ok, I have plans to offer on university the nuttx pascal programming

patacongo commented 2 years ago

I have basic functionality now, but there are a lot of quirks.

My biggest complaint is that it is so difficult to configure properly. I have updated several READMEs with tips, helps, and warning.
I am seeing instability. If you just run the simulator, it will fail with a segment violation.

$ ./nuttx.exe Segmentation fault (core dumped)
But if I use GDB and single step, I can see that most of the code is running fine and that the segment violation happens in closedir() which is passed a bad DIR pointer.
When I run under GDB, things runs almost normally: The Pshell prompt appears. There is normal output to stdout from Pascal WRITELN. Input on stdin is received okay with echo of the debugger character input on the console. Note that everthying you see after "/bin/Pshell.pex Loaded" is generated by Pascal running on the target.

    Thread 1 "nuttx" hit Breakpoint 1, pstart_main (argc=1, argv=0x6ffffc0231e0, envp=0x10042bbb0 <pstart_main>)
        at pstart_main.c:78

    (gdb) c
    Continuing.
    /bin/Pshell.pex Loaded
    psh>

All of the Pshell commands work. Like H[elp]:

    psh> h
    PShell Commands:
      H[elp]
        Show this text
      L[ist]
        Show Pascal Executables
      R[un] <PexFileName>
        Run a Pascal Executable
      D[bg] <PexFileName>
        Debug a Pascal Executable
      Q[uit]
        Exit

L[ist:

    psh> l
      phello.pex Size: 254
      Pshell.pex Size: 5811

R[un] and D[bg] also work

    psh> r phello.pex
    /bin/phello.pex Loaded
    Hello, World!
    Exit with code 0
    psh>

psh> d phello.pex
/bin/phello.pex Loaded
Commands:
  RE[set]   - Reset
  RU[n]     - Run
  S[tep]    - Single Step (Into)
  N[ext]    - Single Step (Over)
  G[o]      - Go
  BS xxxx   - Set Breakpoint
  BC n      - Clear Breakpoint
  WS xxxx   - [Re]set Watchpoint
  WF xxxx   - Level 0 Frame Watchpoint
  WC        - Clear Watchpoint
  DP        - Display Program Status
  DT        - Display Program Trace
  DS [xxxx] - Display Stack
  DI [xxxx] - Display Instructions
  DB        - Display Breakpoints
  H or ?    - Shows this list
  Q[uit]    - Quit
PC:0000  b4..0004          INDS  4
SP:0418  0000
   0416  0000
FP:040e CSP:0000
CMD: g
Hello, World!
Normal Termination
PC:0021  3f......          END
SP:0418  0000
   0416  0000
FP:040e CSP:0000
CMD: q
Goodbye
psh>

I can spawn multiple instances of the Pshell:

    psh> r phello.pex
    /bin/phello.pex Loaded
    Hello, World!
    Exit with code 0
    psh> r PShell.pex
    /bin/PShell.pex Loaded
    psh> r PShell.pex
    /bin/PShell.pex Loaded
    psh> [New Thread 17352.0x3ea4]
    [New Thread 17352.0x153c]
    q
    Exit with code 0
    psh> q
    Exit with code 0
    psh> q
    Exit with code 0

A possible issue is that I let the simulator set with no input until GDB spawns several more threads, then it hangs. I suspect this is a simulator issue, however.

tcpipchip commented 2 years ago

Hello Gregory

This is a formidable news! It´s alive!!!!!!!!

Wow, debug too ? Interesting!!!!

And instances too ? :)

Congratulations! Big progress!!!!!!!!!

Still running on the simulator, right ?

patacongo commented 2 years ago

Wow, debug too ? Interesting!!!!

The debugger is a P-code level debugger. It is very useful for Compiler development; I rely on it completely to determine if the compiler/optimizer/linker are generating correct code. But I am not sure how useful it would be Pascal application development. I could certainly extend it to execute at the level of Pascal program lines vs. P-Code instructions, but I haven't had the motivation to do that.

If you look at the POFF object format you can see that all of file and line number information is that. If you list the compiled .pex file with "plist -d" you can see that every group of P-code instructions is annotated with file name and line number.

Some things that source level debuggers do would be more difficult with Pascal because Pascal is so naturally nested and recursive. For example, examining variables. In Pascal, you would not only have to know the variables name and frame pointer offset, but also its static nesting level.

And instances too ? :)

Yes, each Pascal instance runs from its own "sandbox" so you can have as many as you like running concurrently. However, there is no way to wait and give other instances a chance to run (other than waiting for for I/O) and there are no IPCs (inter-process communications). The interactions between Pascal instances as needed to support a real system are not yet defined.

Still running on the simulator, right ?

Yes -- and that probably accounts for instabilities I see. Today I will check things out on hardware too. I don't see any reason why it should not work.

tcpipchip commented 2 years ago

Good news!

If the hardware user wants to use a peripheral, first must to thing about how to enable the /dev/userleds on Nuttx and then use the pascal open function, right ?

patacongo commented 2 years ago

If the hardware user wants to use a peripheral, first must to thing about how to enable the /dev/userleds on Nuttx and then use the pascal open function, right ?

Yes, you see the Pascal Open functions in pascal/doc/PascalNotes.md

I haven't tried this with a device driver. Well, I have: the Pascal INPUT and OUTPUT files use stdin and stdout which are usually /dev/console == /dev/ttys0.

My only concern is that I implemented the Pascal I/O on top of C buffered I/O: fopen, fread, fwrite, etc. The buffer is not optimal for a device interface because output stays buffered until a newline is printed or fflush() is called (Pascal has a procedure call Flush). That is motivation to switch to unbuffered I/O: open, read, write. That is really not such a big effort. The target I/O interface is only one file.

tcpipchip commented 2 years ago

yea, looks that will work!

tcpipchip commented 2 years ago

Gregory

Did you get success to compile pascal to ESP32 ?

tcpipchip commented 2 years ago

make[2]: Entering directory '/home/osboxes/nuttx/nuttx/boards/xtensa/esp32/common' CC: board/esp32_boot.c CC: board/esp32_bringup.c CC: board/esp32_appinit.c AR (create): libboard.a esp32_boot.o esp32_bringup.o esp32_appinit.o make[2]: Leaving directory '/home/osboxes/nuttx/nuttx/boards/xtensa/esp32/common' LD: nuttx xtensa-esp32-elf-ld: /home/osboxes/nuttx/nuttx/staging/libapps.a(builtin_list.c.home.osboxes.nuttx.apps.builtin.o):(.rodata.g_builtins+0x1c): undefined reference to `prun_main' make[1]: [Makefile:106: nuttx] Error 1 make[1]: Leaving directory '/home/osboxes/nuttx/nuttx/arch/xtensa/src' make: [tools/Unix.mk:509: nuttx] Error 2 osboxes@osboxes:~/nuttx/nuttx$

patacongo / Pascal

Pascal #1