Lua for TI99

[+arcadeshopper]

I'll mention that force command has a nice api set up to build/run applications using sams  the only issue would you would need to load fc first then load the programs etc.

 

 

[JasonACT]

14 hours ago, khanivore said:

I didn't forget ES - I just didn't know what we would use it for

How would you write an efficient memcpy?

[+TheBF]

7 hours ago, JasonACT said:

How would you write an efficient memcpy?

Excellent question. 

I had to explore this in a SAMS based editor. I ended up using two memory windows so I could copy records across page boundaries without a 3rd buffer.

If you have to do that byte-by-byte it is not be pretty.

 

My conclusion was that I wanted a memory card with some of the code:

1.  test if page in memory 

2. computation from virtual->real address,

in hardware.

 

[+MarkB]

7 hours ago, JasonACT said:

How would you write an efficient memcpy?

I never thought of that 🙂

[+FarmerPotato]

On 5/28/2024 at 8:14 AM, khanivore said:

Yes.  We could get gcc to emit extra code if given a switch.  I didn't forget ES - I just didn't know what we would use it for 🙂

I've thought about trying to do it automatically with hardware assists but it does get tricky with 16-bit ptrs if you've lost the context.  We looked at IAQ and decided it wouldn't work anyway since if a multi-word instruction requires extra fetches for the parameters these are in code but IAQ isn't set while fetching them AFAIR so.

Maybe you already thought of this, but here goes:
 

In a 4A, you might assume that sequential reads after with IAQ are an immediate operand. But you're right it limits your style by not permitting DATA after a BL or BLWP. .And it's only possible in a sidecar as IAQ doesn't make it to the PBOX or module port. You need a up-counter that loads in parallel, and a latch. That's a lot of extra ICs. 
 

It also requires an assembler to support DSEG/PSEG. 

 

No comfort here, but, the 99105 outputs bus status codes that can be used by glue logic.  Different BST codes allow code/data segmentation and tricks with operands.

 

An example is to block read-before-write on VDPWD.  
 

It's much trickier to implement segment registers. You can deduce when a register is used for indirect or indexed addressing, and  build off of that.   It's probably a nightmare to deduce in the 4A: you have to know what the WP is. 

 

[+FarmerPotato]

Lua:

 

I thought some more about what's distinctive in Lua. Rather than get 32-bit pointers to work in a C program, I think it would be better to write a new Lua interpreter/compiler from the beginning.  It might be a subset of the language, but still a novel thing on our computer. 
 

What's distinctive about Lua:

 

Numbers and strings are passed by value, everything else is an object reference. 
 

Tables are key-value, that is associative, arrays. You use keys 1,2,3 for arrays. A[1]    Strings are valid keys.  A["fred"] = 9

A.fred = 9

 

 

Functions are objects. So you can have a table of functions.  A module is a table where key=name of function and value=function object. 
 

Standard library modules are in tables: 
math.random() 

Nothing is statically typed.  Most behavior can be changed at run-time. 
 

Tables have meta-tables. Yikes.  Meta tables can redefine operators like _eq_ _lt_.   The __index iterator is called by a for loop. (Custom sort order.)  There's a global meta-table. 
 

Everything is scoped by an environment stack. There's global G, but local variables establish  a new frame.  You can really screw around here. 

 

 

It resembles JavaScript in several aspects. 

 

The garbage collection could be replaced by object reference-counting (some exceptions).  

 

Maybe some uses of meta-tables are too extravagant and could  be left out. 

 

You need a good hash  function for tables. 

So whether it's worth it depends on how much you want a dynamically typed language with function objects and polymorphism. Something not known for the 4A. 
 

 

 

Edited May 30 by FarmerPotato

[+MarkB]

10 hours ago, FarmerPotato said:

I thought some more about what's distinctive in Lua. Rather than get 32-bit pointers to work in a C program, I think it would be better to write a new Lua interpreter/compiler from the beginning.  It might be a subset of the language, but still a novel thing on our computer. 

Yes that is a possibility.  But I'd have a couple of concerns with that approach.  First if we can support a language that already exists then we get lots of free stuff including documentation and sample code as well as a mature and tested codebase that is maintained and updated.  Coding a new language is doable but is only part of the work.  I'll start a separate thread about 32-bit pointers.

Secondly I reckon you're going to hit the 64KB address bus limit anyway.  It's going to be very tricky to develop a language that can have stack, heap, code and user program all fitting into 32KB.  So bank support for SAMS is going to be needed one way or the other.

[+jedimatt42]

Anecdotal comment, back in college, I implemented a smalltalk interpreter. That implementation was made far easier due to knowing we needed a garbage collector, and implementing it first so that the constructs of the language implementation could also live in the garbage collector managed memory.

 

A second lesson gained from that was to only implement allocation and maybe deallocation, and save compaction for when the language implementation is about to run out of memory, so that you gain momentum in the language code. With 1meg I would imagine you could go quite far without implementing the compactor.