You can have one or the other but not both.
Tiny Pascal is another option, but they always hide the run-time source.
The version I am thinking about had a BASIC program comple the p-code on a 8080
computer.
https://archive.org/details/the-byte-book-of-pascal
other versions
http://www.trs-80.org/tiny-pascal/

19 seconds isn't bad, but I wonder if you're missing the "trick" of only checking up to the square root of the number of numbers? (31 in this case)

(Although I'm now wondering if you meant generate the first 1000 primes? If I change my code to do that the time does up to 882ms with 10,000 locations in the sieve)

This is my implementation of the old Byte Sieve program in BCPL - it includes an integer square root function and runs in just 84 milliseconds.

Below is the output of the source code, a compile and run on my Ruby 816 board - it's a 16Mhz 65C816 8/16 bit CPU running a bytecode interpreter for the BCPL compiled bytecode (CINTCODE). It runs at maximum of 400K instructions/second and usually much much slower. It's a 32-bit VM and spends a lot of its time overcoming the 64K banks of RAM that the '816 manages.

As for actually writing the compiler - I didn't do that - I just provided the run-time and bytecode interpreter/vm for it all. While I've written many interpreters I've yet to tackle a "proper" compiler for anything - maybe one day!

Still - designing your own CPU and computer from scratch, writing your own language for it is still very impressive. Well done.

-Gordon

I don't see why not.

e.g. under Linux I have C and BCPL.

if I had the time/energy/learning I could write a C (and Pascal and Basic) compiler in BCPL and have them output the same bytecode the BCPL compiler outputs so they'd all run on my system.

I'd really love to do that, but the closest I think I'll get is to re-write my existing C based BASIC interpreter in BCPL...

-Gordon

Now that is a book I've not yet seen and it looks to be very well worth the read - thanks.

From the description:



-Gordon

I went from "that can't possibly be right", to "of course it's right" after about 5 minutes of thought! Thank you for pointing that out. Here is the same thing explained over in a mathematics forum...

https://math.stackexchange.com/question ... -out-numbe

Also, here is a link an early description of this benchmark. Courtesy of BigEd, earlier in this thread.

https://archive.org/details/InterfaceAg ... 1/mode/1up

Byte code does work indeed for all, I guess.
I still think of compiling to machine code, with byte or word addressed machines.

Just a quick update on LALU. By using the suggested code improvement of only going to the square root of N, the time to execute the byte sieve was reduced from 19 seconds to 14 seconds. I also improved the coding in the parser and gained another 2 seconds, so the sieve benchmark is now executing in 12 seconds flat.

I wrapped up all my design files for the SBC version of LALU into a zipfile. Here is a link :

https://www.mtmscientific.com/lalu_sbc.zip

If anyone gets the crazy idea of building one of these let me know, I can likely help with a PCB or whatever. Thanks! Michael

Only when you get crazy and have 0xA bits per byte.
I have the crazy idea of building something and it works. Good to see you have a working product.
Ben.
The Byte Sive bench mark makes the IBM-PC look good, every thing else is slower .
The code for a long gone FPGA cpu, was about 30 seconds with a slow memory cycle.

Recent work on the LALU computer has been focused on serial communication. Two new commands were created in LANG for the purpose. (LANG is the interpretive language, written in LALU assembly.) Serial communication is at 4800 baud, N-8-1. No flow control. The Host computer is an old Dell Laptop running XP.

BRX is receive a byte.
BTX is transmit a byte.

The serial communication is asynchronous. To my surprise I found it is possible to simply write a receiving routine in LANG for receiving less than 10 bytes sent in row. However, more than ~10 bytes requires a delay between characters. Fortunately, I found a serial communication program called RealTerm that can send a file with programmable delay between characters. Screenshot attached.

https://sourceforge.net/projects/realterm/

Here is an example of a simple receiving program for serial bytes.

HF000=A H0006=B GT2 (Setup: Where A is starting address, and B is number of characters to receive)
#2 B DO A BRX A+1=A LP GT0 (Simple loop that receives a byte, increments storage location and loops)

The screenshot mentioned earlier also show a simple memory dump using a LANG routine. I am writing other routines in LANG as well. I can burn the utility routines into the ROM and load them when they are needed. Consequently LANG is being used to write something akin to an operating system.

Another thing I tried recently was swapping the 62256 SRAM on my LALU SBC with a non-volatile replacement. I thought this might be a nice way to get non-volatile writable storage. However it does not work. Possibly someone has an idea why. Details of the SRAM attached.

Michael

Timing maybe? Although it says it's a 70ns part, it's mentioned in the data sheet it has a cycle time of 130ns.

Here is an update on LALU Stack Computer. The coding for LALU originally began with
the assembly language. At first I used an Excel spreadsheet with a substitution
formula to convert assembly mnemonics to opcodes, with the addressing handled manually.
(Hard coded address jumps everywhere. It was challenging and prone to mistakes.)

From there I moved on to writing an assembler in C to do the same thing. However the
assembler added the great advantage of labels, which made addressing MUCH simpler.
I have become very familiar with writing assembly code for LALU using this tool.

With an assembler, I wrote an interpretive language called LANG. The main feature of LANG is
that it is written to handle 16 bits. The LANG interpreter was written in assembly. It is
an interpreted language, but still pretty fast. The programming style is something between
BASIC and FORTH.

Another major project milestone was moving from a multicarded computer inserted in a backplane,
to a Single Board Computer. Another milestone was going headless, to serial port input and output.

In my latest work I have started to write a simple compiler. The compiler accepts
LANG instructions and outputs machine code. The compiler is written in assembly. It has
taken a lot of effort on my part to think about how to do this! The compiler
parses the LANG instructions and builds machine code in SRAM. One nice thing
about this approach is all the coding is being done on the LALU SBC.

The compiler for LANG is invoked with the instruction "COM" for compile. The input is
one of the keyboard stacks, which is loaded with a source code text string for compiling.
I have also added a LANG instruction called "JUMP" which jumps to an address in SRAM
to execute the compiled code.

I am steadily adding additional LANG instructions to the compiler. This is slow going.
However, it is very exciting to see the compiler become more capable. My hope is to develop
the compiler to the point I can compile and run the prime number sieve benchmark.

excellent!

Quick Update: I built up 2 more of the LALU V2 Single Board Computers. (The minimum PCB order was 5 pieces.) Then I spent 2 weeks trying to figure out why the new builds didn't work! Dumb mistake... I used a 10K resistor to tie the active-low reset circuit to +5V. Not good idea for TTL. Anyway, I was happy to finally find the problem. Michael