A tiny Raspberry Pico shell with flash file system, vi, and c compiler.

[-Nathan-]

This is brilliant!

You've basically just created what I was starting to work on.

I've put in a pull request for a restart command, I use USB to program the Pico and find that testing changes is a lot easier if you can restart in bootsel mode without having to unplug USB. So by typing restart in the terminal without pressing enter, hold down bootsel and press enter, you are ready to upload the new uf2 file.

I'm in Australia and we can't get access to the Pico W version just yet, but can't wait to work on some network commands!

[-Nathan-]

Is there any chance of a version which supports serial over USB ?

In CMakeLists.txt change 0 to 1:

Code: Select all

pico_enable_stdio_usb(${PSHELL} 1)

[hippy]

pico_enable_stdio_usb(${PSHELL} 1)

More importantly; don't change "pico_enable_stdio_uart(pshell 1)" to 0.

I'm in the habit of swapping UART to USB, enabling USB, disabling UART. In this case disabling UART causes compilation to fail.

But thanks for your reply as it was enough to have me figure out what I was doing wrong. It now builds, and runs.

[HPCguy]

Couple of things:

I am not great at understanding make systems. With the right optimization flags, the code size should shrink significantly

For your recursive calculation of Pi example, you should have been able to pass float instead of int. Is that not working?

Squint adds these features over AMaCC (only the first two are critical to call out in your README file):

• * Floats
  * Support for array declarations, initializers, and sizeof operator (as opposed to pointer-only AMaCC).
  * Much stronger type checking, and syntax error detection, all calling out line number of error.
  * improved IR echo
  * many bug fixes I am trying to backport to AMaCC, but their review process for each one takes a lot of time. For example, pointer arithmetic outright fails a lot of the time in AMaCC. A pull request has been sitting in their repo for weeks and is at most 36 lines of code.

And as an aside, not important for the pshell project but to show I am not an AMaCC freeloader, I contributed these capabilities to the AMaCC repository. Anything that starts with "Implementation of" means the capability was not there at all until I added it:

• * Implementation of the do-while statement.
  * Restructuring all looping constructs for better efficiency.
  * Implementation of break and continue statements on all looping constructs with proper nested scoping and error messages when out of scope.
  * Implementation of goto and labels.
  * Implementation of Union.
  * Implementation of array indexing capability '[]' on struct/union pointers.
  * Implementation of error messages when case, break, default statements used outside of a switch statement.
  * Completed the support for all compound assign operators.
  * Implementation of power-of-two literal constant optimizations for *, /, % integer operators.
  * Many important bug fixes.
  * Greatly enhanced IR echo.
  * other cool unmentioned stuff having to do with compiled code that does not affect the pshell project.

[HPCguy]

Can you force gcc to use computed goto for switch statements? That may speed up your interpreter.

Also, I'll think about implementing the mc compiler generated switch statements as computed goto, not that it will affect your users unless they add switch statements to their programs. It may take me a few weeks because I have super high priority work to finish, but if an implementation I like comes together in the back of my mind, I'll implement it straight away.

[HPCguy]

Have you tried any Advent of Code tests? For instance, day 5 has a lot of division and modulo operators that the AMaCC/mc compilers optimize for.

[lurk101]

Squint adds these features over AMaCC (only the first two are critical to call out in your README file):

• * Floats

...

Yes, I acknowledged this important contribution in the current README. In fact, I wouldn't have undertook this project if not for float support.

[lurk101]

For your recursive calculation of Pi example, you should have been able to pass float instead of int. Is that not working?

Passing floats as parameters works fine. The parameter in question is a recursion depth counter so it's an int.

[JumpZero]

I struggled a bit but after updating my sdk I managed to compile.
However I had this error

Code: Select all

[ 24%] Building C object CMakeFiles/pshell_uart.dir/cc.c.obj
/home/pi/pshell/cc.c: In function 'cc':
/home/pi/pshell/cc.c:3543:13: error: a label can only be part of a statement and a declaration is not a statement
             int sysc = *pc++;
             ^~~
/home/pi/pshell/cc.c:3548:17: error: a label can only be part of a statement and a declaration is not a statement
                 int* stk = sys_malloc(a.i * 9);
                 ^~~
make[2]: *** [CMakeFiles/pshell_uart.dir/build.make:141: CMakeFiles/pshell_uart.dir/cc.c.obj] Error 1
make[1]: *** [CMakeFiles/Makefile2:1666: CMakeFiles/pshell_uart.dir/all] Error 2
make: *** [Makefile:84: all] Error 2

So to get out of it I modified the code: adding a semicolon at the end of lines 3542 and 3545.

Code: Select all

Before
        case SYSC:
            int sysc = *pc++;
            switch (sysc) {
            case SYSC_PRINTF:


After
        case SYSC: ;
            int sysc = *pc++;
            switch (sysc) {
            case SYSC_PRINTF: ;

I'm not sure if this is the right method, because I'm far from understanding all the details of this process.
But hey in the end I managed to have pshell working on a picow, format the filesystem and compile hello.c
All while accessing via the usb port because I set this to 1 in CMakeLists.txt

Code: Select all

pico_enable_stdio_usb(${PSHELL} 1)

So that's very nice

[ejolson]

I struggled a bit but after updating my sdk I managed to compile.
However I had this error

Code: Select all

[ 24%] Building C object CMakeFiles/pshell_uart.dir/cc.c.obj
/home/pi/pshell/cc.c: In function 'cc':
/home/pi/pshell/cc.c:3543:13: error: a label can only be part of a statement and a declaration is not a statement
             int sysc = *pc++;
             ^~~
/home/pi/pshell/cc.c:3548:17: error: a label can only be part of a statement and a declaration is not a statement
                 int* stk = sys_malloc(a.i * 9);
                 ^~~
make[2]: *** [CMakeFiles/pshell_uart.dir/build.make:141: CMakeFiles/pshell_uart.dir/cc.c.obj] Error 1
make[1]: *** [CMakeFiles/Makefile2:1666: CMakeFiles/pshell_uart.dir/all] Error 2
make: *** [Makefile:84: all] Error 2

So to get out of it I modified the code: adding a semicolon at the end of lines 3542 and 3545.

Code: Select all

Before
        case SYSC:
            int sysc = *pc++;
            switch (sysc) {
            case SYSC_PRINTF:


After
        case SYSC: ;
            int sysc = *pc++;
            switch (sysc) {
            case SYSC_PRINTF: ;

I'm not sure if this is the right method, because I'm far from understanding all the details of this process.
But hey in the end I managed to have pshell working on a picow, format the filesystem and compile hello.c
All while accessing via the usb port because I set this to 1 in CMakeLists.txt

Code: Select all

pico_enable_stdio_usb(${PSHELL} 1)

So that's very nice

Adding the semicolon seems correct to me. Strangely, everything compiles on my system using gcc 9.3.0 without any changes.

I have run a simple hello.c program by setting

Code: Select all

pico_enable_stdio_usb(${PSHELL} 1)

It would appear that I'm only getting line feeds on the command line, so the output looks like

Code: Select all

/: cc foo.c
hello world!

            CC=0

                /: cat foo.c
#include <stdio.h>

                  int main(){
                                printf("hello world!\n");
                                                                return 0;
                                                                         }

                                                                          /: 

The clear command also enters the editor, but that may be intentional.

Am I doing something wrong with the USB console on my system? Does anyone know how to cook the terminal driver so a carriage return is added?

Has Pascal been completely removed?

[Gavinmc42]

I had updated the wrong SDK, fixed that and checked that the SDK was pulling in the PicoW files and wifi/lwip libs.
It still compiled pshell

Going to be interesting to see if networking can be added to pshell.
If only I knew what I was doing

[JumpZero]

Adding the semicolon seems correct to me. Strangely, everything compiles on my system using gcc 9.3.0 without any changes.

I have run a simple hello.c program by setting

Code: Select all

pico_enable_stdio_usb(${PSHELL} 1)

It would appear that I'm only getting line feeds on the command line, so the output looks like

Code: Select all

/: cc foo.c
hello world!

            CC=0

                /: cat foo.c
#include <stdio.h>

                  int main(){
                                printf("hello world!\n");
                                                                return 0;
                                                                         }

                                                                          /: 

The clear command also enters the editor, but that may be intentional.

Am I doing something wrong with the USB console on my system? Does anyone know how to cook the terminal driver so a carriage return is added?

Has Pascal been completely removed?

Hi!
I also had the same output (line feed, no CR) at first boot. So I tried another machine: same result. Then I used minicom and added a CR in the settings. It was ok.
But now when I boot it on the Pi400 using "screen" as terminal emulation it's OK. The lines are correctly formatted without asking screen to add a CR.
Strange.. But working

[lurk101]

Ah, the eternal dilemma, whether or not to append CR after a LF on output.

BTW. You can create an .exrc file in the root folder that will be read by vi at startup. It can contain configuration items such as:

Code: Select all

set ts=4
set autoindent

[ejolson]

I struggled a bit but after updating my sdk I managed to compile.
However I had this error

Code: Select all

[ 24%] Building C object CMakeFiles/pshell_uart.dir/cc.c.obj
/home/pi/pshell/cc.c: In function 'cc':
/home/pi/pshell/cc.c:3543:13: error: a label can only be part of a statement and a declaration is not a statement
             int sysc = *pc++;
             ^~~
/home/pi/pshell/cc.c:3548:17: error: a label can only be part of a statement and a declaration is not a statement
                 int* stk = sys_malloc(a.i * 9);
                 ^~~
make[2]: *** [CMakeFiles/pshell_uart.dir/build.make:141: CMakeFiles/pshell_uart.dir/cc.c.obj] Error 1
make[1]: *** [CMakeFiles/Makefile2:1666: CMakeFiles/pshell_uart.dir/all] Error 2
make: *** [Makefile:84: all] Error 2

So to get out of it I modified the code: adding a semicolon at the end of lines 3542 and 3545.

Code: Select all

Before
        case SYSC:
            int sysc = *pc++;
            switch (sysc) {
            case SYSC_PRINTF:


After
        case SYSC: ;
            int sysc = *pc++;
            switch (sysc) {
            case SYSC_PRINTF: ;

I'm not sure if this is the right method, because I'm far from understanding all the details of this process.
But hey in the end I managed to have pshell working on a picow, format the filesystem and compile hello.c
All while accessing via the usb port because I set this to 1 in CMakeLists.txt

Code: Select all

pico_enable_stdio_usb(${PSHELL} 1)

So that's very nice

Adding the semicolon seems correct to me. Strangely, everything compiles on my system using gcc 9.3.0 without any changes.

I cloned the latest version and now I'm also getting

Code: Select all

/x/libb/ejolson/code/pshell/pshell/cc.c: In function 'cc':
/x/libb/ejolson/code/pshell/pshell/cc.c:3660:13: error: a label can only be part of a statement and a declaration is not a statement
 3660 |             int sysc = *pc++;
      |             ^~~
/x/libb/ejolson/code/pshell/pshell/cc.c:3715:17: error: a label can only be part of a statement and a declaration is not a statement
 3715 |                 unsigned us = *sp;
      |                 ^~~~~~~~
/x/libb/ejolson/code/pshell/pshell/cc.c:3727:17: error: a label can only be part of a statement and a declaration is not a statement
 3727 |                 unsigned ms = *sp;
      |                 ^~~~~~~~
/x/libb/ejolson/code/pshell/pshell/cc.c:3896:17: error: a label can only be part of a statement and a declaration is not a statement
 3896 |                 pwm_config* c = (void*)sp[0];
      |                 ^~~~~~~~~~
make[2]: *** [CMakeFiles/pshell_uart.dir/build.make:160: CMakeFiles/pshell_uart.dir/cc.c.obj] Error 1
make[1]: *** [CMakeFiles/Makefile2:1421: CMakeFiles/pshell_uart.dir/all] Error 2
make: *** [Makefile:91: all] Error 2

about 17 percent through the build. I guess I had an older version before. It would be nice to add the semicolons upstream. Does anyone want to try a pull request for this?

Woohoo! The carriage returns are working. Output now looks like

Code: Select all

file system automatically mounted

/: 

    cat - display file
     cc - compile C source file
     cd - change directory
  clear - clear the screen
     cp - copy a file
 format - format the filesystem
    get - get file (xmodem)
     ls - list directory
  mkdir - create directory
  mount - mount filesystem
     mv - rename file or directory
    put - put file (xmodem)
   quit - shutdown system
 reboot - Restart system
     rm - remove file or directory
 status - filesystem status
unmount - unmount filesystem
     vi - editor

/: ls

      72 foo.c

/: 

I wonder if this will work for the upcoming Advert of Code?

Since the first week is already reserved for OS9 on the SuperPET, maybe MVS on Hercules could move to week 3 so Pico Shell could have week 2.

[lurk101]

Since the first week is already reserved for OS9 on the SuperPET, maybe MVS on Hercules could move to week 3 so Pico Shell could have week 2.

Why do you insist on torturing yourself?

[ejolson]

Since the first week is already reserved for OS9 on the SuperPET, maybe MVS on Hercules could move to week 3 so Pico Shell could have week 2.

Why do you insist on torturing yourself?

I was just wondering that myself. Isn't Advent supposed to be a time of anticipation?

At any rate, the code

Code: Select all

/*  pmerge.c--Pico merge sort with Fido's favorite random numbers
    Version 1 Written 2022 by Eric Olson */

#define N 256
#include <stdio.h>

#ifdef LINUX
#include <time.h>
static struct timespec tic_start;
void tic() {
    clock_gettime(CLOCK_MONOTONIC_RAW,&tic_start);
}
float toc() {
    struct timespec tic_stop;
    clock_gettime(CLOCK_MONOTONIC_RAW,&tic_stop);
    float sec=tic_stop.tv_sec-tic_start.tv_sec;
    return sec+(tic_stop.tv_nsec-tic_start.tv_nsec)*1.0e-9;
}
#endif

#ifndef LINUX
int tstart;
void tic(){
    tstart=time_us_32();
}
float toc(){
    return (float)(time_us_32()-tstart)/1000000.0;
}
#endif

void fido(){}

void mergeserial(int m,int *x,int n, int *y,int *z){
    int i,j,k;
    i=0; j=0; k=0;
    while(i<m&&j<n){
        if(x[i]<=y[j]) z[k++]=x[i++];
        else z[k++]=y[j++];
    }
    while(i<m) z[k++]=x[i++];
    while(j<n) z[k++]=y[j++];
}

void msortserial(int n,int p,int *x,int *y){
    int m;
    if(n==1) {
        if(p%2) y[0]=x[0];
        return;
    }
    m=n/2;
    msortserial(m,p+1,x,y);
    msortserial(n-m,p+1,x+m,y+m);
    if(p%2) mergeserial(m,x,n-m,x+m,y);
    else mergeserial(m,y,n-m,y+m,x);
}

int hextoi(char c){
    if(c>='0'&&c<='9') return c-'0';
    if(c>='A'&&c<='F') return c+10-'A';
    if(c>='a'&&c<='f') return c+10-'a';
    return 0;
}

#define Lf 6
#define Lh 3

void out72(int *a){
    int i;
    for(i=Lf-1;i>=0;i--){
        printf("%03x",a[i]);
    }
    printf("\n");
}

void strto72(int *a,char *s){
    char *p;
    int i,j;
    for(i=0;i<Lf;i++) a[i]=0;
    for(p=s;*p;p++);
    i=0; j=0;
    for(p--;p>=s;p--){
        a[i]|=hextoi(*p)<<4*j;
        if(j<2) j++;
        else {
            j=0;
            i++;
            if(i>=Lf) break;
        }
    }
}

void add72(int *a,int *b){
    int i,r,s;
    s=0;
    for(i=0;i<Lf;i++){
        r=a[i]+b[i]+s;
        a[i]=r&4095;
        s=r>>12;
    }
}

void mul72(int *a,int *b){
    int c[Lf];
    int i,j,k,r,s;
    for(i=0;i<Lf;i++) { c[i]=a[i]; a[i]=0; }
    if(b==a) b=c;
    fido();  // add this or else mc-so -Op doesn't work
    for(i=0;i<Lf;i++){
        for(j=0;j<Lf-i;j++){
            s=b[i]*c[j];
            for(k=i+j;k<Lf&&s!=0;k++){
                r=a[k]+s;
                a[k]=r&4095;
                s=r>>12;
            }
        }
    }
}

void mtswap(int *a){
    int i,r;
    for(i=0;i<Lh;i++){
        r=a[i]; a[i]=a[i+Lh]; a[i+Lh]=r;
    }
}

struct {
    int x[Lf],w[Lf],s[Lf];
} rstate;

int rint24(){
    mul72(rstate.x,rstate.x); add72(rstate.w,rstate.s);
    add72(rstate.x,rstate.w); mtswap(rstate.x);
    return rstate.x[1]<<12|rstate.x[0];
}

void rseed(char *s){
    strto72(rstate.x,s);
    strto72(rstate.w,"0");
    strto72(rstate.s,"D9B5AD4ECEDA1CE2A9");
}

void pstate(){
    printf("x:"); out72(rstate.x);
    printf("w:"); out72(rstate.w);
    printf("s:"); out72(rstate.s);
}

int chksum(int *x){
    int k,r;
    r=0;
    for(k=0;k<N;k++) r+=x[k];
    return r&0x7FFFFFF;
}

int x[N],y[N];

int main(){
    int j,jmax,k,gold;
#ifdef LINUX
    volatile
#endif
    int total;
    float t;
    printf("pmerge--Pico merge sort with Fido's favorite random numbers\n"
        "Version 1 Written 2022 by Eric Olson\n\n");
    jmax=1;
    do {
        rseed("1234");
        total=0;
        jmax*=2;
        tic();
        for(j=0;j<jmax;j++){
            for(k=0;k<N;k++) x[k]=rint24();
            gold=chksum(x);
            msortserial(N,0,x,y);
            if(gold!=chksum(x)){
                printf("Checksum error in merge sort!\n");
                return 1;
            }
            total=(total+gold)&0x7FFFFFFF;
        }
        t=toc();
        printf("After %d iterations checksum is %d\n",jmax,total);
    } while(t<5.0);
    printf("\nIteration rate is %g per second.\n",(float)jmax/t);
    return 0;
}

runs in Pico Shell with the output

Code: Select all

/: cc pmerge.c

pmerge--Pico merge sort with Fido's favorite random numbers
Version 1 Written 2022 by Eric Olson

After 2 iterations checksum is 53595608
After 4 iterations checksum is 272151338
After 8 iterations checksum is 672710099

Iteration rate is 1.32768 per second.

and on a Ryzen 4650 APU as

Code: Select all

$ ./pmerge 
pmerge--Pico merge sort with Fido's favorite random numbers
Version 1 Written 2022 by Eric Olson

After 2 iterations checksum is 53595608
After 4 iterations checksum is 272151338
After 8 iterations checksum is 672710099
After 16 iterations checksum is 1284314404
After 32 iterations checksum is 38945480
After 64 iterations checksum is 207214098
After 128 iterations checksum is 2048724696
After 256 iterations checksum is 2143682573
After 512 iterations checksum is 576859642
After 1024 iterations checksum is 1558348822
After 2048 iterations checksum is 1831978477
After 4096 iterations checksum is 91641767
After 8192 iterations checksum is 1318630065
After 16384 iterations checksum is 1818025745
After 32768 iterations checksum is 1062175105
After 65536 iterations checksum is 754318714
After 131072 iterations checksum is 669559631
After 262144 iterations checksum is 1600807640

Iteration rate is 39707 per second.

It's satisfying that the first three checksums are the same.

Note that I couldn't sort arrays larger than about 256 elements. Could a table size be changed or does vi use all the memory?

[cleverca22]

I've put in a pull request for a restart command, I use USB to program the Pico and find that testing changes is a lot easier if you can restart in bootsel mode without having to unplug USB. So by typing restart in the terminal without pressing enter, hold down bootsel and press enter, you are ready to upload the new uf2 file.

you can do one better!

Code: Select all

reset_usb_boot(0, 0);

map that to the "bootsel" command, and you dont even have to touch the button!

[lurk101]

Note that I couldn't sort arrays larger than about 256 elements. Could a table size be changed or does vi use all the memory?

Certainly. Just pushed version 1.0.4. If you look in cc.c you'll find

Code: Select all

#define DATA_BYTES (4 * K)
#define TEXT_BYTES (16 * K)
#define SYM_TBL_BYTES (4 * K)
#define TS_TBL_BYTES (1 * K)
#define AST_TBL_BYTES (16 * K)
#define MEMBER_DICT_BYTES (1 * K)
#define STACK_BYTES (16 * K)

Other than the ast, there's no range checking on these tables and can easily over/underflow.

There's no OS and it's a monolythic chunk of code, so when they exit commands had better have freed all the memory they've allocated otherwise it's considered a leak. Vi doesn't get to hold memory when it's not running. Another side effect is that all commands need to reinitialize any global variables they use when invoked.

I had to add a malloc/free tracking mechanism to the compiler since compiled code supports the malloc and free functions and who knows how any program will behave.

[lurk101]

you can do one better!

Code: Select all

reset_usb_boot(0, 0);

map that to the "bootsel" command, and you dont even have to touch the button!

Ooh! I like that. There should be a command for that.

Sample code please. What does 'map that to the "bootsel" command' entail? Save me having to work though it.

Would this do it?

Code: Select all

watchdog_reboot(0, 0, PICO_STDIO_USB_RESET_RESET_TO_FLASH_DELAY_MS);

[lurk101]

you can do one better!

Code: Select all

reset_usb_boot(0, 0);

map that to the "bootsel" command, and you dont even have to touch the button!

Ooh! I like that. There should be a command for that.

Sample code please. What does 'map that to the "bootsel" command' entail? Save me having to work though it.

Would this do it?

Code: Select all

watchdog_reboot(0, 0, PICO_STDIO_USB_RESET_RESET_TO_FLASH_DELAY_MS);

doh! You already gave the answer.

Code: Select all

reset_usb_boot(0, 0);

Done, in dev branch.

[HPCguy]

Note that I couldn't sort arrays larger than about 256 elements. Could a table size be changed or does vi use all the memory?

Here are the decisions lurk101 made:

Code: Select all

#define DATA_BYTES (4 * K)
#define TEXT_BYTES (16 * K)
#define SYM_TBL_BYTES (4 * K)
#define TS_TBL_BYTES (1 * K)
#define AST_TBL_BYTES (16 * K)
#define MEMBER_DICT_BYTES (1 * K)
#define STACK_BYTES (16 * K)

Maybe try these settings?:

Code: Select all

#define DATA_BYTES (12 * K)
#define TEXT_BYTES (16 * K)
#define SYM_TBL_BYTES (4 * K)
#define TS_TBL_BYTES (1 * K)
#define AST_TBL_BYTES (16 * K)
#define MEMBER_DICT_BYTES (1 * K)
#define STACK_BYTES (8 * K)

Even a 20 deep recursive function with a combination of 20 local scalar vars/arguments only takes 3400 bytes of stack, so the stack seems pretty large compared to data.

What is the current space taken by the compiler itself? Has anyone tried aggressive compile optimizations to reduce the compiler executable size?

[HPCguy]

Please consider adding %d: to the front of your die() function to echo out the line number. Usability increases exponentially for the few bytes of memory you expend.

I tried to add this issue to your github repository, but didn't have permission:

use *f version of all math functions. They will likely be smaller, faster, and can possibly avoid the cost of casting. I don't have a pico to do the testing, so I can't make the pull request myself. tanf, sinf, etc.

[cleverca22]

Please consider adding %d: to the front of your die() function to echo out the line number

__builtin_return_address(0) will give you the address a function would have returned from
so you can then create a:

Code: Select all

void die() {
  printf("die called from %p\n", __builtin_return_address(0));
}

you can also use __FILE__ and friends like this:

Code: Select all

#define __STRINGIFY(x) #x
#define LINE_NUMBER(x) __STRINGIFY(x)
#define PANIC_LOCATION __FILE__ ":" LINE_NUMBER(__LINE__)
#define panic(ex, ...) \
        (panic)(# ex "@" PANIC_LOCATION, ## __VA_ARGS__)

or like this:

Code: Select all

#define panic(msg, ...) panic_real(__FILE__, __FUNCTION__, __LINE__, msg, ## __VA_ARGS__)


void panic_real(char *filename, char *func, int line, char *msg, ...) {
  printf("error at %p in %s: %s:%d\n", __builtin_return_address(0), filename, func, line);
  // TODO, print msg and use va_args to allow panic("ret is %d\n", ret);
}

[lurk101]

Please consider adding %d: to the front of your die() function to echo out the line number. Usability increases exponentially for the few bytes of memory you expend.

I tried to add this issue to your github repository, but didn't have permission:

Do you have a github account. I've already merged a pull request from a user here.

use *f version of all math functions. They will likely be smaller, faster, and can possibly avoid the cost of casting. I don't have a pico to do the testing, so I can't make the pull request myself. tanf, sinf, etc.

Good suggestions.

I need to get past all this niggly stuff and get to what I really want which is stand alone truly relocatable and executable (on the VM) compiler output and interrupt handling.

[HPCguy]

@cleverca22

There is a 'line' variable in cc that keeps track of position in the user input file to the c compiler.

That said, I may be able to make good use of your suggestion for my non-debuggable ELF files.