Just to say, I appreciate your posts, Michael, although I have no thoughts or ideas!

Program flow instructions are needed for the language I have been describing. The question arises 'What are the most basic and useful flow control instructions?'

Here is the set I have:

GO TO Statement (GTx, where x is one of 15 stacks, labeled 0,1,2,3...F)

DO LP (Where the instructions inside the loop are repeated a fixed number of times.)

IF ELSE (Perform action after IF when true, otherwise action following ELSE)

The GO TO statement is easily implemented by jumping between keyboard stacks. The DO LP is implemented by setting up a counter at the word "DO" and incrementing and testing the counter at the word "LP". The IF statement looks for TRUE on the top of the stack and performs the action, otherwise skipping forward to the ELSE action. Simple stuff.

Here are some examples:

GT5 means starting using Keyboard Stack 5 (After resetting the pointer to zero)

H005 DO "HELLO" LP will print the word "HELLO" five times.

H0000 IF "TRUE" ELSE "FALSE" will print "FALSE" because the flag preceding the IF statement is False=0.

One disadvantage of the way these program flows work is that the DO LP and IF ELSE branches must appear on a single line of code. (The operations can not span multiple lines.) However, each keyboard stack can hold 255 characters, which is significant given the terse nature of the language.

So, that's where I am right now with the flow control. I'm considering the usefulness of nesting these instructions, allowing program flow operations that span across lines, setting precedence using parenthesis, allowing the DO LP index to be changed during execution, etc. Ideas welcome. This kind of reminds me of building a computer that only has NAND gates. Yes, you can do it, but at the expense of mind-numbing code. On the other hand, we have CPU's with hundreds of instructions available, and we end up using only a handful when writing actual code. Michael

It is not that CPU's have thousands of unused instructions, you have lost the concept of random access memory,
and a Von Neumann architecture. Now all your instructions are for saving a clock or memory cycle here and there
over the general case or filling some cache line, rather than doing real work. Then you have to be backwards compatable
with things like FORTRAN IV, and the COMMON data format using large data spaces or spagetti code and goto foobarxxx

Hi, I'm still working on the LALU (Lookup Arithmetic Logic Unit) Computer Project. Recently I have been writing an improved version of LANG, the interpretive language for the stack computer architecture. A notable development has been eliminating the Reverse Polish Notation (RPN) in favor of Infix Notation... to make the programs more readable. I have also improved the variable handling, and now offer arrayed variables. Presently the boot code, operating system and interpreter are about 3.5 KB of binary code for ROM.

In the meantime, I have created a large zip file (65 MB) archive that contains basically everything related to the LALU project up to now, including the PCB Gerber Files, 3 ROM images (ALU, CONTROLLER & LANG), Excel File development tools (ALU & CONTROLLER), WWA (Assembler written in C), Assembly Language Specification, Photos, Diagrams and LANG Source Code. The zip file includes a readme.txt to help navigate. I'm happy to answer any questions, as this is probably clear as mud! I've had a lot of fun with this project.

I hope to be saying more about the improved LANG interpreter soon. Thanks. Michael

http://tinyurl.com/45t38tmt

I have ever-so-slowly been writing and developing the interpretative language LANG for the stack computer LALU. The language is an abstraction layer written in LALU assembly language. I decided the Reverse Polish Notation was reducing program readability. Converting from RPN to Infix took me down an interesting path leading to the Shunting Yard Algorithm and the early days of ALGOL, among other things.

https://en.wikipedia.org/wiki/Shunting_yard_algorithm

https://www.cs.utexas.edu/~EWD/MCReps/MR35.PDF

Writing a language is a new experience for me, and consequently I have kept things simple. I find it interesting that at this layer of abstraction, the same language can easily be implemented on different machines and hardware. Something I had never really considered, but then seems obvious considering how a language like BASIC propagated across platforms. Presently the binary code for LANG is about 3.5 kilobytes.

Anyway, enough of the musings. Here is a short summary of LANG as it currently exists.

Interesting update, thanks!

(Are there obvious tricks or idioms for dealing with the lack of negative numbers? Does subtraction wrap around?)

When I wrote my BASIC some 12+ years back, I decided on using the Shunting Yard too. The tricky thing I found was detecting unary minus, but once my parser/tokeniser sorted that out, it was relatively straightforward (and writing it in C under Linux helped)

Looking at your equality operator and puzzling over it ...

What I did was to feed everything through the shunter then RPN evaluator - unless the = has been detected as an assignment and that detection works is there is an implicit LET statement or the first thing on a statement is a variable

10 variable = 5 = something

assigns the true/false value to 'variable' as everything to the right of the first = is fed into the shunter and '=' is just another operator with a precedence.

A sneaky thing you can do for speed (which requires extra logic and RAM) is to cache the shunted yard before you feed it into the RPN evaluator and remember you've done it and just feed the cached RPN stack into the RPN evaluator the next time - good for speeding up loops - although in your case you might need to cache the variable name rather than its value. Keeping track of the just-in-time cache is left as an exercise to the user

Also striking me as very Tiny-Basic like too with fixed name A-Z variables - although your fixed arrays add an extra bonus. Some TinyBasics just support one array - sometimes called just 'A' or '@' In my case a variable holding an address can be indirected, so if A held 1234, then B = !A would fetch the contents of A (1234) into B and !(A+6) = 42 would store 42 into the address formed by adding 6 to the value of A - that way every variable can be an array you just need a way to get the start of free RAM (which in my TinyBasic case is provided by the built-in instruction TOP).

Looking good though!

-Gordon

I suspect the shunting yard algorithm can also handle ALGOL parsing. A := .if bla .then foo .else foo bar ;
For an example. Reverse polish was not the advatage as everybody claims, but rather it is non recursive.
Very few computers before the 70's even had subroutines that stacked the return address. The PDP 11
could use recusive decent parsing.
Still looking for algorithm to parse the does not generate reverse polish
Algol could use a virtual stack machine and recusion was more a hidden option, than a normal feature.

Here is an update on the LALU Stack Computer. The original design for LALU was a slotted motherboard, with individual cards for each of the main computer sub-systems. Each of the individual cards went through numerous revisions (Most of which were layout mistakes, or simply because TTL design is new to me.)

I recently have combined all of the individual cards into a design for a LALU SBC (Single Board Computer). The resulting 2 layer board measures 10 inches x 15 inches. The approximate layout map for the SBC is shown in the attached photo.

The LALU operating system is integral with the interpretative language LANG running from ROM. LANG is written in the custom assembly language of LALU and assembled using a tool for the purpose written in C. The latest version of LANG is designed for headless operation using serial port I/O.

I also have spent a large amount of time exploring number systems. Presently I am working in only positive integers, but it is not for lack of trying! More on that later. Michael

Where is the power input? You might want to add some pins to the unused headers so you can check logic for ringing on sensitive lines,

What would be a good choice of equipment to monitor a TTL bus running at 1 MHZ? Total bus is 50 lines. I imagine there is old school equipment available, as well as new stuff. I've never done it before, but yes, would be very helpful to see.

Here is a view of the LALU Single Board Computer with the components installed. I am getting closer to getting it to run, having accomplished the following:
1. Connecting the positive and negative power supply connections in reverse.
2. Inserting an IC upside down in the socket and burning my finger testing for warmth.
3. Pulling all the IC's, reinserting them, and bending some leads preventing electrical contact.
4. Hooking up the TX and RX on the serial cable in reverse.
5. Forgetting to solder one of the IC sockets to the PCB.
Did I forget anything? Michael

Swaping hi-lo roms when burning them.
A TL886II+ PROGRAMMMER will test chips.

The LALU computer has been transferred from a multi-card system to SBC (Single Board Computer). This was a relatively painless process, except for the usual dumb mistakes. The SBC is operated in a headless configuration, using serial I/O for interfacing. (4800 baud N-8-1)

For serial communication I am using a simple software application called "Termite". This application has worked well for me in many projects. I've attached a screenshot. Here is a link to the free software.

https://www.compuphase.com/software_termite.htm

The 1 MHZ crystal oscillator is socketed. I'm hoping to experiment with the clock speed. I've never worked with a logic analyzer before. I posted a question asking about what people might suggest for equipment at VCF. There were some good suggestions. Here is a link to the discussion.

https://forum.vcfed.org/index.php?threa ... s.1247478/

I ran the Sieve benchmark (previously discussed in this thread) and calculation of prime numbers up to 1000 takes 19 seconds. I'm pretty happy with that, considering I'm at 1MHZ and running a self-written interpreted language. I'm considering increasing the number of keyboard stacks from 16 to 256. I've been spending alot of time reading about BCPL and C Compilers. Not ready to take the leap yet!

Michael

Great progress!