New community dev tool uploaded: 8sh

[rje]

PROGRESS

Added strings and logical operators.

CURRENT WORK

Adding a hashtable so I can store variables.

 

[rje]

PAIN and SUFFERING

This is what I get for trying to implement a standard C project built for modern computers onto an 8 bit platform.

Pain!  

So, the scanner is great.  Tokenization is easy, well understood, and so on.

I suspect the interpreter is probably okay, as far as I've gotten with it anyhow.

But the compiler is a mess.  Back to the books to understand what's going on.

[rje]

I'm letting this sit on the backburner, thinking about it, before I rewrite it.

I'm starting to become interested in looking at it again, but I have to ask myself what I WANT out of 8shell.

The current work was implementing an interpreter using an existing C project designed for modern systems.  As a result there are two problems:

(1) The codebase, though not extravagant, is really too "big" / requires too much, for the X16.

(2) Partly to head off problems with (1), I made decisions that are a bit incompatible with the original.   And of course, one change often cascades into many changes.  And so I ran out of energy.

Now I'm coming back to it and asking what I WANT, and then planning how to get there.

 

SOFTWARE CONSIDERATIONS

• 
  It's a Shell
  
  
  
  This means it's a prompt that you interact with.  Call it a REPL if you prefer.
  
  
  
  This means it IS a command interpreter, even if it's a wimpy one.  This means scripting scripts... things that let it access the file system and manipulate data sources.  AWK and sed and Perl are my guides here.  The result won't be as powerful as them, but if I can capture some of that power in a bottle I think we'll have something.
  
   
  


• 
  It has to be Useful
  
  
  
  Being able to sed or awk a file and pipe the output to a new file, or concat an existing file, would just be nice, fun, and might be useful.
  
  
  
  Throwing other little tools in the mix would enrich this capability.  One thing at a time, though, I suppose.
  

 

HARDWARE CONSIDERATIONS

• 
  8SH is NOT made for a ROM Bank.
  
  
  
  8SH is greater than 16K, and thrives on calls to the KERNAL.  THEREFORE it is by definition something that lives in RAM.
  

• 
  8SH SHOULD leverage RAM banks.
  
  
  
  Tokenizing commands means storing small tokenized scripts, probably in one RAM bank.  In other words, the tokenizer will happily churn along until you reach that 8K limit, at which point the interpreter will fail with a "Bank Overflow" command and force you to cut your scripts down in size and chain them or something.
  
  
  
  Why only one bank?  Because that simplifies things.  I can make it more complicated later.
  
  
  
  Similarly, hashtables will be shoved into other RAM banks... and might not even be hashtables.
  

 

 

[desertfish]

oof, this sounds like a complex beast.... it looks useful for some complicated tasks, but at the same time, it feels like overkill for a simple 8 bit system. Do you really want to write shell scripts (this is my interpretation of what you're proposing) for the system?

[rje]

Well of course I do!  

But: you're right, a lot of things shells do, don't apply here.

Actually, much of it is not complex.  Tokenizing into Bank 1 is easy.  Symbol tables / hashtables are easy. Even a stack-based VM seems easy.

The bit *I* find challenging is compiling to bytecode.  I think it's a recursive descent parser, with an expression engine, and a bytecode emitter with forward referencing for handling blocks.  Or maybe I can use a stack?

Building it in pieces is the way to get it done.  ... And perhaps also the way to find out what is useful and what isn't.

 

[desertfish]

I'm sorry I didn't mean to talk down the idea.  By all means it would be a great tool, for some tasks, just personally I don't (yet) see them ?   That shouldn't stop you on this project ofcourse!

[rje]

No no, I get it.  I mean, C is not the 6502's native language, and a bytecode interpreter is heavy by definition.

But it will be a personal achievement, and if it works it will be fun, and JUST MAYBE useful.

 

I was talking with a C64/C128 guy who was writing a very low-level symbol table, with hopes of writing something like AWK from it.  And that sparked my imagination.

 

[rje]

20 minutes ago, desertfish said:

it would be a great tool, for some tasks, just personally I don't (yet) see them ?  

Quoted for truth. 

On my UNIX machine, scripts are used for creating, processing, and reporting on data, usually in files.

It's totally overkill on the X16.

But, I want to see it; some ideas may present themselves.

[ZeroByte]

I'd be happy if it just worked like DOS - dir, delete, rename, move, cd, etc... and execute a file by just typing its name.

This should be able to replace the BASIC environment if you so chose - i.e. burn a ROM with this shell in one of the unused banks, and make it executable by a SYS call or something. You could pick and choose which Kernal calls to use to make your life easier in building the thing. Last, just build in the command to return to BASIC be 'basic' and then it just does RTS. ?

[rje]

You know, Zero, we've got disk commands in the current MIST-modified KERNAL...