Likely I just forgot. I see I also forgot it in the scanner...

I was quite depressed when I saw the RPI zero for five bucks. I could not come near that price for a single board computer of my own. Lately I saw the XMC4700 http://www.infineon.com/cms/en/produ...3c3e221b9d004f arm cortex computer. It has all the embedded peripherals I need with 2.5 MB flash and 512 KB ram. With that much ram you could have a multitasking 64kb stack machine of about 6 tasks with the extra used for the stacks and disk IO. I have been trying to get them give me a price for one up systems but the organization is so large that the person did not know they sold ARM machines. Now a days you have to sell the whole package in order to get money for software as everyone expect to get the software for free. With that size of ram and flash do you think I could get the lexer and parser in the machine or do you think I will still have to go with the lexer and parser c programs on the PC. My whole approach is to have a programming system on the single board computer without the need for a separate software development system on a PC. The person could write software that controlled the peripherals with a combination compiler that consisted of BASIC with some C added to increase the power. Call it CASIC. I would plan to have the whole machine free for development and only do context switching when the machine was in RUN mode.

The PI zero is basically just the two chips (memory and CPU) along with some standard sockets attached to the board. Not much there.

They tried a compute unit on a DIMM board, but I don't think that took off. The zero provided nearly the same interfaces that the first PI did, but didn't put all the USB sockets, no camera, or the pins for the GPIO, and that knocks off a lot of the assembly costs. Since everything present can be assembled automatically (surface mounts), it would cut the production costs. The thinner unit also reduces storage requirements too. The
box that contained the PI 2 should be able to hold 3 or 4 of the PI zero.

Of course, the missing pins would have to be put on there before it could become useful for anything other than a basic compute unit, so the cost just got shifted to the purchaser.

The profit comes from production runs rather than single units. A single unit would still be far more expensive (I would expect something in the $100 range).

2.5MB of permanent storage should be able to handle quite a bit of software. 512K is plenty of room for an OS + application + compiler even, though the application wouldn't be in memory at the same time as the application - a load-and-go operation would work fine (the compiler runs, outputs the application to either memory or storage, then chains to the application. The OS only provides the chain support and maybe runtime.

The real limitation of the m0 is not being able to replace the "secure os" piece which would be the ideal location for the OS and interpreter. That has a separate ROM and you don't have access (you would have make a different ARM chip for each OS and that would be expensive).

As long as the chip itself is fast enough for the applications it should work.

1 members found this post helpful.

I price off of one up so that economies of scale can take over. I might make two compilers - one for the PI and one for the infineon chip. I sell through www.apssoftwareandelectronics.com .

Long time since last communication. I have been looking over your code for the c compiler you made. You left out "not equal" (NE) (!=) in your relops. you should have:
You do not have NE anywhere in your compiler. Also, I can't find code_walker.c in you info that you gave me. I may be crazy but I am going to try to implement most all of C so that it will handle any C program as well as itself. This is a long term project just because I am interested in it. I found a DEC book titled "Engineering a Compiler" where they talk about TBL a table building language http://multicians.org/raf-tbl-definition.html which is used as an abstract machine for code generation. R. Freiburghouse used it to write PL/1 for multics. The URL has the grammar for which you build a TBL compiler that generates an array of ints that you feed to the abstract machine as the program. For the DEC VAX11 PL/1 compiler in "Engineering a Compiler" they used four different versions in the compiler. I think the TBL Abstract Machine was stack based. Let me know what you think. Alvin...

There are a lot of overlooked things... But code.c has the code_walker function that walks the tree to generate code. There is a debug version in in parse.c that basically just dumps the tree.

As for transating C, there are already grammar available. There is even a portable C compiler where you should only need to replace the code generator - IF you can follow their logic. I think "tiny C" is similar. I remember looking at it, and it had a single code function that would generate the target code; according to the documentation that was the only file needed to be replaced, but I didn't succeed at understanding it well enough to do so. The nice part would be avoiding all the tree handling stuff.

All of the translators I know of use a stack - sometimes it is part of the compiler application stack rather than a specific external stack. This is how recursive decent compilers maintain context for error messages. This was the first translation technique I learned - as that was how Pascal was implemented (and I got the task of maintaining the compiler and interpreter in college).

There are two ARM cortex processors with 64KB ram and about 256KB Flash that you could implement your Stack VM on. For $10 cypress offers a complete system at https://secure.cypress.com/?rID=108038 . TI offers the MSP432 for ~$12 at: http://www.ti.com/tool/msp-exp432p401r and Mouser offers: http://www.mouser.com/new/Texas-Inst...gaAmCKEALw_wcB and : http://www.mouser.com/ProductDetail/...5KHMfcHA%3d%3d The TI msp432 has two msp432 s on it. One is the computer you are writing code for and the other makes it easy to access and program the 432 main computer. TI also has a file system for free for FAT16 and FAT32 for SD cards. I have previously purchased the 432 and just bought the cypress. Plan a stack VM of my own and a DOS OS (possibly multitasking ) to implement a multi processor connection method I came up with in 1980.

And the Pi Zero is $5 (or there abouts), with more memory. But it depends on the peripherals you want to use. If they are GPIO or USB, I believe the connections are present.

Found a really good thesis on first and second generation stack machines. I think you will like this: http://fpgacpu.ca/stack/Second-Gener...chitecture.pdf

Believe it or not I am still designing the BASIC compiler. I have settled on a non line numbered Commodore 64 BASIC which has built in functions (log, sin, etc) as part of the expression definition. I will expand that for I2C SPI GPIO ADC control. I plan to use LEX and YACC (flex and bison) but what to generate code for has been a big hangup. I keep coming back to FORTH which works best in a Von Neaumann machine (its assembler) but will probably use a Harvard architecture. Moore came up with a BASIC compiler http://www.forth.org/fd/FD-V03N6.pdf (page 175) written in FORTH having the BASIC reserved words as FORTH words and writing the BASIC program as a colon definition ( : ) compiled program compiling down to the FORTH word RUN. This turns the BASIC program into a bunch of branches which will execute quickly as other forth words execute. I am planning to implement a subset of forth as primary words (located in flash) and have the compiler generate a FORTH compiler program like Moore did. My first machine will probably be the MSP432 TI ARM Cortex M4 as its memory is big enough (256k flash/ 64k RAM) and easy to work with in its launch pad form. But programming will be done under LINUX GCC implementing a Harvard architecture by forcing primitives to be in the code section and having separate dictionary (two) in code and data. Getting it to work under C in Linux will be easiest for me as I know that platform. Then when it is working I will put the C into the MSP432 and get that to work. I will add the words for I2C SPI etc in the MSP432 environment as I can then test them under the hardware. Also, a file system exists for the 432 which can be implemented with FORTH.

Good luck and have fun.

:-)

Sorry to bother you but I had a question about your work. When you developed your compiler and abstract machine you did automated testing. How did you do that? Did you use any packaged software to implement that? Thank you for your time and trouble.

Actually I used a rather simple form. First get the base syntax built. Bison provided a lot of the debugging for that as it identifies conflicts in the grammar. But once the base scanner (fairly easy with flex in the same way), the combination of the scanner and parser provided a syntax check on sample input files.

When I started generating the abstract syntax tree, I needed to see if it was done write, so I added a print function to diagram the tree. This "tree walker" provided the skeleton to use for generating the code...

At that point I needed the machine... So I wrote it with a basic loop using a single byte for the opcode.

The interpreter then printed out the results after running a given program... which ment I needed an assembler. The input to the interpreter was rather simple - a text file of one byte sized numbers in one column. That made it easy to track, and to hand edit.

Perl to the rescue :-). I already had an assembler I wrote for a different project (a CPU that had an ALU only supporting AND, OR, COMPLEMENT, and SHIFT operations), so I retargeted it by redefining the instructions (it was a table lookup translator, so very primitive, but did have some macro capability, was two pass to allow for forward addressing). Using that I could easily make a very small program for each instruction.

That allowed me to translate the assembly code to small text files that the VM would load and execute. For debugging a specific instruction it was actually simpler to put print statements in the op code interpretation with a problem.

After debugging I had the sample program, a sample machine version, and a reference output. For regression testing all I had to do was re-run each sample program and compare the output to the reference file saved. As long as they matched... it worked. So a shell script to do that.

As a side effect, I also had an assembler for the compiler.

Adding the code generator got a bit easier, I just had to translate the syntax tree to the assembler input, and I had the stack walker that printed out the tree as a prototype to start with.

I could then inspect the output, and see that the generated code looked right, and could then pass it to the assembler and the machine interpreter.

At this point MOST of the language was implemented (minus some relational operators and a couple of other things).

Essentially, I started development at the front (the scanner and parser), switched to the end (the vm), then the middle (the assembler).... and repeated the last two until most of the machine was working. Not quite everything, I was thinking about adding a "test" instruction that would discard the top element and then push a selected status bit for logical expressions but had not made final decisions on implementation. It was missing this that stopped the implementation of relational operators at the time).

As usual, a project taking longer than anticipated.

1 members found this post helpful.

Thank you for getting back to me with a very interesting reply on how you did your work.

No problem.

It was a fun project, and I might still redo the VM to try something different - like a hypothetical 64 bit CPU patterned after the PDP-11.