Have you looked at the ARM + FPGAs offered by the mainstream FPGA vendors? The ARMs in the Xilinx and Altera/Intel parts are high end like the Cortex-A devices. The Microsemi part is a CM3 or CM4, I forget which.
I wouldn't even say the logic is comparable to a PLD type device other than a very, very simple one. It only includes two LUTs. This is more like a very lame Cypress PSOC device. Actually Cypress makes one sub-family of PSOC devices that actually have no programmable logic as such. They just have some peripherals that are very configurable, like it can be SPI or I2C or a couple of other serial devices, but no general logic.
It doesn't have to be 100's of millions to be cost effective. The GA144 isn't even in the running. But any practical MCU needs to be sold in sufficient quantities to make it affordable and for the company to keep running.
I don't know the "new" C, I don't work with it. What improved?
Like what? It is not really "limited". The GA144 assembly language is... well, assembly language. Would you compare the assembly language of an X86 to JAVA or C?
You keep talking in vague terms, saying the MARC4 was more "powerful". Address space is not the power of the language. It is the hardware limitation of the CPU. The GA144 was designed with a different philosophy. I would say for a different purpose, but it was not designed for *any* purpose. Chuck designed it as an experiment while exploring the space of minimal hardware processors. The capapbilities come from the high speed of each processor and the comms capability.
I compare the GA144 to FPGAs more than to ARMs. The CPUs are small, very fast and plentiful (relatively), like the LUTs in an FPGA. Communications are very fast and the processor can automatically halt for synchronization with the other processor. Letting a processor sit idle is a power advantage, not a speed disadvantage. Processing speed is plentiful in the GA144 so it does not need to be optimized. Like the XMOS using it requires some adjustment in your thinking... a lot more than the XMOS in fact.
Perhaps, but I would still emphasize the issue that MCUs in general and FPGAs in general cover a lot of territory. XMOS only excels in a fairly small region. The GA144 is optimal for a microscopically small region.
If the XMOS price were better, I would say they would be much more worth learning.
I can't tell you how many people think FPGAs are complicated to design, power hungry and expensive. All three of these are not true.
My only complaints are they tend to be in very fine pitch BGA packages (many with very high pin counts), only a few smaller devices are available and they don't integrate much analog. I'd like to see a small FPGA rolled with a small MCU (ARM CM4) with all the standard peripherals an MCU normally includes, brownout, ADC/DAC, etc. They could have done this affordably a decade ago if they wanted, but the FPGA companies have a particular business model that does not include this market. Lattice and Microsemi aren't as committed to the mainstream FPGA market and so offer some limited products that differ.
I have a laptop with a 17 inch screen and the fonts are smaller than my old desktop with a 17 inch monitor because the pixels are smaller (HD vs. 1280 horizontal resolution). The windows stuff for adjusting the size of fonts and such don't work properly across lots of apps. Even my Excalibur calculator is very hard to read.
Bottom line is don't bad mouth an API because it doesn't *please* you. Your tastes aren't the only standard.
No, it is functional, not just illustrating. It is in the *language*, not just the editor. It's all integrated, not in the way the tools in a GUI are integrated, but in the way your heart, lungs and brain are integrated.
That's what the color does.
I wouldn't know C++.
Yeah, Charles Moore isn't in the business of supporting language standards. He created Color Forth for himself and has shared it with others. GA is using it to support their products and they are the best source for information now.
You mentioned optimizing compilers, what was your point in bringing it up? Optimizations are not in any language that I'm aware of. You seem to think there is something lacking in the Forth language, but you don't say what that would be.
I don't know what is meant by "limited practicality for modern programming". By griping about the use of primary colors and large fonts, I consider that throwing a tantrum. How about discussing something important and useful?
Yes, I know. (Perhaps you interpreted me to mean "it would be nice if someone made an FGPA with a fast ARM core". I actually meant "an FPGA with a fast ARM core would be nice for this sort of application".)
It is programmable logic, even though it is small. And unlike the PSoC, it is a supplement to a range of normal microcontroller peripherals and the AVR's "event" system for connecting peripherals. The idea is that this logic can avoid the need of glue logic that you sometimes need along with a microcontroller. I think it is a neat idea, and if it catches on then I am sure later models will have more.
Again, I don't know the numbers here. XMOS has been running for quite a few years, with regular new products and new versions of their tools, so they seem to be doing okay.
Well, starting from pre-K&R C and moving to "ANSI" C89/C90, it got prototypes, proper structs, const, volatile, multiple different sized types, etc. I am sure you are very familiar with this C - but my point is that even though the history of C is old like that of Forth, even at that point 25+ years ago C had moved on and improved significantly as a language, compared to its original version.
Some embedded developers still stick to that old language, rather than moving on to C99 with inline, booleans, specifically sized types, line comments, mixing code and declarations, and a few other useful bits and pieces. Again, C99 is a much better language.
C11 is the current version, but does not add much that was not already common in implementations. Static assertions are /very/ useful, and the atomic types have possibilities but I think are too little, too late.
The size of the memories (data space, code space and stack space) is the most obvious limitation.
True - I was not clear in distinguishing the language from the hardware here. I meant the hardware in this case.
Minimal systems can be interesting for theory, but are rarely of any use in practice.
I agree with the principle - as I say, the GA144 has some interesting ideas and technology. But you need more power in each cpu to do something useful. If you want to use animal power to draw a plough, you want a horse. An army of ants might have a theoretically greater total strength and a better total-power to food cost ratio, but it is still hopeless as a solution.
Fair enough.
Also true.
That certainly /was/ the case. But yes, for a good while now there have been cheap and low power FPGAs available. As for complicated to design
- well, I guess it's easy when you know how. But you do have to know what you are doing. Tools are better, introductory videos are better, etc. - there are lots more learning resources than in the "old" days. And once you know (at least roughly) what you are doing, the modern tools and computers make the job a good deal faster than before. I remember some 20 years ago working with a large PLD - place and route took about 8 hours, and debugging the design was done by pulling a couple of internal signals out to spare pins and re-doing the place and route. (By that stage of the project it was too late to think about alternative chips.)
Variety of choices is always nice. I agree that devices like those could have a wide range of uses.
Surely you don't use that laptop for normal work? A laptop is okay for when you need a portable office, but I have three large monitors in my office. And most of my development is done on Linux, where font scaling works most of the time. (Though personally, I like small fonts with lots of text on the screen - my eyes are fine for that, when I have my contacts in. Without them, I can't focus further than my nose!).
My tastes are the most important standard for /me/, and the one that affects my impression when I look at a tool. Of course I realise that other people have other tastes. And perhaps some people have poor eyesight and a job that requires them to work entirely on a small laptop. But I find it hard to accept that an IDE should be designed solely on the basis of being clear to someone with bad eyesight who works with a tiny old monitor. The colorForth stuff seems to be designed by and /for/ a single person - Chuck Moore. That's fine for him for a personal project, but it is highly unlikely to be a good way to make tools for more general use.
No, it is syntax highlighting.
There is a 4 bit "colour token" attached to each symbol. These distinguish between variables, comments, word definitions, etc. There is /nothing/ that this gives you compared to, say, $ prefixes for variables (like PHP), _t suffixes for types (common convention in C), etc., with colour syntax highlighting. The only difference is that the editor hides the token. So when you have both var_foo and word_foo, they are both displayed as "foo" in different colours rather than "var_foo" and "word_foo" in different colours.
That is all there is to it.
The colour doesn't do it - the language makes a clearer distinction between compile-time and run-time, and the colour helps you see that. You had the same distinction in Forth without colouring.
Having a separation here is both a good thing and a bad thing, in comparison to the way C handles it, and the way C++ handles it. There is room in the world for many models of language.
Without going into details, you are probably aware that in C you sometimes need a "real" constant. For example, you can't make a file-level array definition unless the size is absolutely fixed:
int xs[16];
That's allowed. But you can't write this:
int square(int x) { return x * x; }
int xs[square(4)];
"square(4)" is not a constant in C terms. However, you would expect a compiler to calculate the value at compile time (assuming it can see the definition of the "square" function) for the purposes of code optimisation.
In C++11 onwards, you can write:
constexpr int square(int x) { return x * x; } int xs[square(4)];
This tells the compiler that it can calculate "square" at compile time if the parameters are known at compile time, but still allows the function to be used as a run-time function if the parameters are not known at compile time.
With all due respect to Chuck Moore and his creations, this is not a way to conduct a professional business.
I gave a list somewhere in another post. But my key "missing features" from Forth are good static checking, typing, methods of working with data of different sizes, safe ways to define and use structures, and ways to modularise the program.
For example, take the "FLOOR5" function from the Wikipedia page:
: FLOOR5 ( n -- n' ) DUP 6 < IF DROP 5 ELSE 1 - THEN ;
The C version is:
int floor5(int v) { return (v < 6) ? 5 : (v - 1); }
Suppose the Forth programmer accidentally writes:
: FLOOR5 ( n -- n' ) 6 < IF DROP 5 ELSE 1 - THEN ;
It's an easy mistake to miss, and you've made a perfectly valid Forth word definition that will be accepted by the system. But now the comment does not match the usage. It would be entirely possible for the language to provide a formalised and standardised way of specifying input and output parameters in a way that most cases could be automatically checked by the tools. Conventionalised comments are /way/ out of date as an aid to automated correctness checking.
And then suppose you want this function to work with 32-bit values - regardless of the width of a cell on the target machine. Or 64-bit values on a 16-bit cell system.
(If you have good answers here, maybe you will change my mind - at least a little!)
See above for a simple example.
But I am not griping about the use of colour - I am mocking the idea that adding colour to the IDE is a big innovation in the language.
To snip many points and bring together a few comments you made...
You have previously asked me to give you xC code snippets. When I provided direct references to xC concepts illustrated by /easily/ digestible code snippets, you completely ignored them.
I know it wouldn't be a good use of my time to /poorly/ duplicate /existing/ information in an attempt to "enlighten" you.
From your statements about what you /don't/ know, it appears you haven't seriously used modern languages i.e. those developed since the early 90s.[1]
In that case it is to be expected that you don't understand the valid points made by David Brown and others.
David Brown is making important and useful points. You have indicated probably reasons why you don't understand them. That's fine; we can't all be competent in everything, and I'm sure you are very competent within your experience.
[1] I'll note these facilities enabled by Java significantly exceed those offered by C/C++/etc, but Java isn't relevant in this context.
A less obvious limitation that goes right to the heart of the parallel processing that is claimed, is processor connectivity. I explored parallelism (with the parallel prime sieve) and the fixed rectangular grid is absolutely bonkers for any serious application where calculation power is needed. In this case I wanted to have two pipelines that come together. It starts as a puzzle, then it turns out to be hardly possible.
Two crossing pipeline have to pass through one processor. If there is any structure to the data, the one processor would fail the processing power to make that possible. On transputers you would have hypercube arrangements such that there is no need to do that. On top of that, it would be easy. You just define two unrelated pass-through processes.
A definitive measure for the quality of the GA144 would be a bitcoin calculator. That is the ratio between the cost of the electricity consumed and the value of the bitcoins generated. t would be *bad*.
Indeed.
100% agreed. Adding colour is equivalent to a prefix character. Then if you want to Vim can add the colour for you based on the prefix character.
Notations can be important innovations as Newton and Leibniz showed. The real big innovation they made was the differential calculus. If there is something underlying Colorforth it is tagged objects, hardly spectacular.
Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
You make some very good points here. The comparison has been made with FPGAs. A great deal of the work (the physical hardware, and also the development tool's work) in an FPGA is about connections - moving signals between different nodes on the device. Imagine an FPGA where each node (block of LUTs, registers, etc.) could only communicate directly with its immediate 2D neighbours.
The GA144 might work okay for problems that naturally fit a 2D grid that happens to fit the dimensions of the chip (8 x 18, I think). But it will be poor on anything else.
In comparison, on the XMOS any virtual cpu (hardware thread) can connect directly to any other - either with a "permanent" channel (existing for the lifetime of the program) or created temporarily as needed. Exactly the same software system is used whether you are communicating between hardware threads on the same core, threads on different cores on the same chip, or threads of different cores on different XMOS chips. Clearly there are latency and bandwidth differences, but the logic is the same.
Small is not the word. The PSOC is enormously more capable and *that* is small. I'm not sure of the purpose of the distinction when you say "supplement to a range of normal microcontroller peripherals". Why a need for "normal" peripherals? The point of the PSOC is they can offer flexibility so your design can use what it needs without a lot of wasted silicon for peripherals that aren't used. Instead they "waste" silicon by making the peripherals programmable. In the process you get a degree of flexibility not found other than in FPGA type programmable logic as well as analog programmability you can only find in discrete analog chips.
The issue I have isn't that they aren't stable, but that they don't seem to be able to produce a device price competitive with the lower end device. For me that make FPGAs a more viable solution economically for the large majority of designs. Combine that with the large learning curve and we end up with many users never taking the time to become proficient with them. If they get priced down to the $1 range, they will get a *lot* more users and sales.
Likewise, if they did a shrink to make the GA144 more cost competitive a lot more users would be interested in learning how to program the device. But it would still be a very ugly duckling requiring a whole new approach to complex systems. The inability to draw on the huge base of established software make the GA144 a non-starter for many apps.
What you get with the PSoC is a chip that can give you a couple of specialised custom-tuned peripherals if that is what your application needs, or 2 or 3 standard peripherals (timers, uarts, SPI, etc.) for the silicon, power and dollar cost of 20 standard peripherals on a "normal" microcontroller. A fixed UART or 16-bit timer is /much/ more efficient than one made from flexible digital cells and all the programmability needed to make them into the same type of peripheral.
When you need a custom peripheral of some sort, then the flexibility of a PSoC is (presumably) great. But only then.
I agree with you - and as I say, I don't really know why they can't make (or sell) the chips for a lower price.
Nah, the GA144 would not be popular even if they /paid/ people to use them. Less unpopular, perhaps, but not popular.
As has Forth. The 2012 standard is an improvement over the previous version, which is an improvement over the previous version to that and the initial ANSI version was an improvement over the multiple flavors of Forth prior to that for the standardization if nothing else.
I think the real issue is you are very familiar with C while totally unfamiliar with Forth.
As I said, that is not a language issue, that is a device issue. But you completely blow it when you talk about the "stack" limitation. Stacks don't need to be MBs. It's that simple. You are thinking in C and the other algol derived languages, not Forth.
That comment would seem to indicate you are very familiar with minimal systems. I suspect the opposite is true. I find minimal CPUs to be *very* useful in FPGA designs allowing a "fast" processor to be implemented in even very small amounts of logic.
You should save the poor analogs for other conversations. An army of ants can move a large pile of sand overnight by themselves. The horse will just complain it doesn't have enough food and water moving the sand only if you connect it to the right equipment and spend your day cracking the whip.
20 years ago maybe.
MCUs are no different. A newbie will do a hack job. I once provided some assistance to a programmer who needed to spin an FPGA design for his company. They wouldn't hire me to do it because they wanted to develop the ability in house. With minimal assistance (and I mean minimal) he first wrote a "hello, world" program for the FPGA. He then went on to write his application.
The only tricky parts of programming FPGAs is when you need to optimize either speed or capacity or worse, both! But I believe the exact same thing is true about MCUs. Most projects can be done by beginners and indeed *are* done by beginners. That has been my experience. In fact, that is the whole reason for the development and use of the various tools for programming, making them usable by programmers with lesser skills, enabling a larger labor pool at a lower price.
The only magic in FPGA design is the willingness to wade into the waters and get your feet wet.
Devices are not often made for broad markets. FPGAs in particular are designed for the comms market and everyone else is along for the ride. As I mentioned, Lattice and Microsemi are branching out a bit to address either a different market (Lattice ice40 parts are aimed at the cell phone market) or a broader market (Microsemi devices), but with limited success.
At this point my laptop is my only computer (other than a five year old netbook used for extreme emergencies). Its only problem is it's a Lenovo piece of crap. I don't have an office as much as I am portable. I don't spend more than half a week in one place running. I just wish I could find a reasonably priced attached oscilloscope. The model I'd like to have is $1,500. I'd like to spend more like $500 and then I'd be totally portable.
There you go with the extremes again. Colorforth isn't designed "solely" for people with bad eyesight. It is designed to be as useful as possible. It is clear you have not learned enough about it to know what is good and what is bad. You took one quick look at it and turned away.
You just said it is more than syntax highlighting. It is like type definitions in other languages. It is built into the language which won't work without it. That's the part you aren't getting. Compare Colorforth to ANSI Forth and you will see what I mean.
If you don't understand, learn how it is done in ANSI Forth and then tell me if THAT is part of the language or not.
Here is a perfect example of why you think Forth has not evolved. There is nothing in even the earliest Forth that precludes this computation from being done at compile time. So how do you improve on perfection?
Whatever. He isn't running a business by promoting Forth. As I've said, he wrote Forth for himself and others like the ideas he has come up with and learned them.
GA is a business that uses ColorForth. ANSI Forth is a standard that is widely used.
Is Arduino a standard? No, yet it is widely used even in business. Standards are useful in some cases, in other cases not needed.
This has been discussed before and some have experimented with writing code to do this. But it is only easy in simple examples like this one. Forth is a very flexible and powerful language which can make it hard to implement this for all cases.
Just as in other languages, like ADA and VHDL (both strongly typed) you would need to write different code.
I'm not interested in changing your mind, only in showing you your misunderstandings about Forth. I'm not actually the right person for the job being a relative amateur with Forth, so I crossposted to the Forth group so others could do a better job. That may bring in some wild cards however as discussions in the Forth group often go awry.
You still don't understand the issue. It isn't about the IDE, it is the fact that the use of color replaces words in the language that change how the other words are interpreted.
The only downside is that by making it an integral part of the language it becomes hard to use for color blind programmers. We can all live without color highlighting in an IDE, but in Colorforth it is not optional.
So programmability in the PSOC is a niche feature while programmability in the XMega E is somehow a big feature?
I think you may have missed some of the PSOC devices, like 90%. One subfamily of about four devices have programmable peripherals. The others have programmable logic and analog blocks. Much more powerful.
That much processing power in a very low cost device would become useful in many apps. It is odd and difficult to learn, but it is not without functionality and application.
Bad compared to FPGAs where the design is optimized at a very low level or compared to a custom ASIC which is optimized from the ground up for this application. I don't believe any other devices are currently used to mine bitcoin. Software became obsolete some time back.
Does that prefix character not take the place of a Forth word?
No, the small programmability of the XMega E is a nice addition to all the other peripherals. Without its timers, communications, ADCs, DMA, etc., it would be a very poor microcontroller.
The small programmability of the PSoC is niche because it has its programmable blocks /instead of/ ordinary microcontroller peripherals. If they were on top of a base of solid standard peripherals, the programmable blocks would be much more interesting.
Well, I disagree. I think the individual cpus are too weak to be practical. It does not really matter if they can do simple operations at 700 MHz if they can't do more than a few dozen lines of code. There are not nearly enough processors on the chip, a far, far too little communication channels between nodes, to be useful despite the small memory size.
I have looked through the Forth 2012 standard. Nothing much has changed in the language - a few words added, a few words removed. (Previous revisions apparently had bigger changes, according to a list of compatibility points.)
I certainly can't claim to be unbiased - yes, I am very familiar with C and very unfamiliar with Forth. I am not /totally/ unfamiliar - I understand the principles of the stacks and their manipulation, the way words are defined, and can figure out what some very simple words do, at least for arithmetic and basic stack operations. And I am fine with trying to get an understanding of how a language could be used even though I don't understand the details.
I program mostly on small microcontrollers. These days, I see more devices with something like 128K ram, but I have done more than my fair share with 4K ram or less. No, I am /not/ thinking megabytes of space. But a 10 cell stack is /very/ limited. So is a 64 cell ram, and a 64 cell program rom - even taking into account the code space efficiency of Forth. I am not asking for MB here.
If you have a specific limited task, then a small cpu can be very useful. Maybe you've got an FPGA connected to a DDR DIMM socket. A very small cpu might be the most convenient way to set up the memory strobe delays and other parameters, letting the FPGA work with a cleaner memory interface. But that is a case of a small cpu helping out a bigger system - it is not a case of using the small cpus alone. It is a different case altogether.
There are good reasons we don't use masses of tiny cpus instead of a few big ones - just as we don't use ants as workers. It is not just a matter of bias or unfamiliarity.
A /lot/ less than 20 years ago.
I will happily agree that FPGA design is not as hard as many people think. However, I do think it is harder to learn and harder to get write than basic microcontroller programming. The key difference is that with microcontrollers, you are (mostly) doing one thing at a time all in one place on the chip - with FPGAs, you are doing everything at once but in separate parts of the chip. I think the serial execution is a more familiar model to people - we are used to doing one thing at a time, but being able to do many different tasks at different times. The FPGA model is more like workers on a production line, and that takes time to understand for an individual.
I gave it several good looks. I have also given Forth a good look over a number of times in the past few decades. It has some attractions, and I would be happy if it were a practical choice for a lot of development. It is always better when there is a choice - of chips, tools, languages, whatever. But Forth just does not have what I need - not by a long shot. What you take to be animosity, ignorance or bias here is perhaps as much a result of frustration and a feeling of disappointment that Forth is not better.
It tags that you see by colour instead of as symbols or letters. Glorified syntax highlighting.
Hey, I never claimed C was perfect!
That's fair enough. But it does mean that the GA144 is not a serious choice for professional products. (And yes, I know that not everything made has to be serious and long lasting.)
We do a fair amount of business taking people's bashed-together Arduino prototypes and turning them into robust industrialised and professional products.
I appreciate the conversation, and have found this thread enlightening, educational and interesting - even when we disagree.
Interestingly, Java is supposed to be safe. I've seen dozens of discussions of Euler problems of Java problems who had problems with overflow and had wasted time debugging that. (Once you've solved one you're entitled to write about how you did it). Of course sometimes when you scale up a problem you get wrong results in Forth caused by overflow too. That was never a time waster, because that is the first thing to look at in such a case, and it is easy to detect and correct in Forth.
Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
I'm impressed with Java due to the constant stream of updates because of security issues.
Forth of course has its problems too, overflow is highly possible due to no error checking so I'm in favor of 256 byte integers less overflow and rounding issues there.
I would be much happier to see the language supporting such static checks in some way (not as comments, but as part of the language), and tools doing the checking. Spotting such errors during testing is better than spotting them when running the program, but spotting them during compilation is far better. (Better still is spotting them while editing
- IDEs for C usually do a fair amount of checking while you write the code.)
Yes, I realise that is a more compact version (and it's on the Wikipedia page too). It was just an example function to illustrate a possible stack error.
And there you have illustrated my point, to some extent - C has progressed as a language, to include new features for more modern systems, such as support for 64-bit types. Now I can use a C compiler for an 8-bit microcontroller and have 64-bit datatypes. (OK, not all implementations have such support - but that is a quality of implementation issue, not a language failure.)
And it is perfectly possible to write C code that is portable across
32-bit and 64-bit systems - precisely because of the zoo of integer types. When you want an integer that is exactly 32-bit, you have int32_t. When you want an unsigned integer that is exactly big enough to hold a pointer, you have uintptr_t. When you want something that can hold at least 16 bits of data and should be as fast as possible, you have int_fast16_t (or just "int"). This requires a bit of discipline to avoid making assumptions about different sizes just because they are true on the platform you are working on at the time, but it is entirely possible.
On the other hand, you don't seem to be able to write a FLOOR5 definition that will handle 32-bit values efficiently on both 16-bit cell systems and 32-bit cell systems.
I don't mean to be rude, but this shows your ignorance of Forth. In Forth, nearly everything is about the words.
When addressing the issues you raise with Forth none of these things are what Forth is about.
I don't know that you need to understand all the details of Forth to see it's power, but it would help if you understood how some parts of Forth work or at least could see how a significant app was written in Forth. Try learning how an assembler is usually written in Forth. This is easy to do as most Forths are provided with full source.
Again, I don't mean to be rude, but saying a 10 cell stack is too small shows a lack of understanding of Forth. You are working with your experience in other languages, not Forth.
I won't argue that 64 cells of RAM don't limit your applications, but the GA144 doesn't have 64 cells of RAM. It has 144 * 64 cells. External memory can be connected if needed. I won't argue this is not a limitation, but it is not a brick wall. Again, I suggest you stop comparing the GA144 to the other processors you have worked with and consider what *can* be done with it. What do you know that *has* been done with the GA144?
I really don't follow your point here. I think a CPU would be a terrible way to control a DDR memory other than in a GA144 with 700 MIPS processors. I've never seen a CPU interface to DDR RAM without a hardware memory controller. Maybe I'm just not understanding what you are saying.
Reasons you can't explain?
I designed a board almost a decade ago that was less than an inch wide and 4 inches long that provided an analog/digital synchronized interface for an IP networking card. It used a small, low power, low cost FPGA to do all the heavy lifting and made me well over a million dollars. At the time I built the board, that chip was already some three or four years old. So there is an example that was over 12 years ago. Other FPGAs that fit the same criteria were from closer to 2000 or 17 years ago. I didn't use them because I wanted to maximize the lifespan of the board.
What you just described is what makes FPGAs so easy to use. The serial execution in a processor to emulate parallel tasks is what makes CPUs so hard to use and supposedly what makes the XMOS so useful. FPGAs make parallelism easy with literally no thinking as the language and the tools are designed from the ground up for that.
I like to say, whoever came up with the name for water wasn't a fish. In FPGAs no one even thinks about the fact that parallelism is being used... unless they aren't fish, meaning software people can have some difficulty realizing they aren't on land anymore and going with the flow.
I will say you have expressed your unhappiness with Forth without explaining what was lacking other than vague issues (like the look of Colorforth) and wanting it to be like other languages you are more used to. If you want the other languages, what is missing from them that you are still looking?
You can't get past the color highlighting. It's not about the color. It's about the fact that parts of the language have different uses. Color highlighting in other languages are just a nicety of the editor. The tokens in Colorforth are fundamental to the language. The color is used to indicate what is what, but color is not the point.
That you are not perfect goes without saying...
I agree, but not because of colorforth. I think the chip has too many limitations along with the tools, but not because colorforth is inherently flawed, because it just doesn't cover enough of the development process. The rest of the toolset (if you can call it a toolset) is lacking in consistency and completeness. If/when I work with the GA144 I will want to do some of my own work in organizing the tools.
Yep, but they developed using the Arduino and they sell lots of them, likely a lot more than you sell of your industrialized products.
We don't learn much if we just agree. I'm glad we could disagree without making it an argument. The other Forth users are much more experienced than I am. They will likely have much better info although not too many actually use Colorforth. Many have learned about it though to learn from it.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.