Well, I haven't gone anywhere with this project, but -- so far -- this doesn't sound like a J implementation either.
But I suspect you might have misunderstood: in this context, "forth" was just the assembly language. And the point of the project would be to build architectural experience with that kind of machine architecture. Actual hands on work with specific hardware isn't where you go if you want to build a web page, but can be quite useful if you want to be building something physical. That said: progress is in the hands of those who make it. Thanks, -- Raul On Friday, June 21, 2019, Robert Bernecky <[email protected]> wrote: > Before heading down that road, it might be worth while looking at > what people are doing in the area of dataflow architectures of late. > The June 2019 issue of CACM has an article on just that topic, > where they discuss an architecture that can flip-flop > between control-flow and data-flow modes on the fly: > > "Heterogeneous Von Neumann/Dataflow Microprocessors" - Nowatzki, > et al. > > They are silent on the issue of eliminating control > flow by APLish methods, such as: (A≥0)×A+1 > Predicated execution, now present in most processors now, > can handle this sort of thing quite well. > > I am not convinced that tieing yourself to a specific > architecture or target language (e.g., Forth) is a good > use of one's time. > > If the idea is to write a J-to-Forth compiler, then I suggest > the following might be a more productive approach: > > The APEX compiler has multiple front ends and back ends, > so you can do: > > {APL, Plural} -> [apex phases] -> {SISAL, SAC, D} > > E.g., you could write a J front end for APEX, and have it crank > out SISAL, SAC, or D, with no source code (J) changes. > [Plural is a language that Walter Fil has under development.] > > Similarly, you could write a Forth back end for APEX, and > have your J code crank out Forth, as well as the other > target languages. > > This is a lot less work than writing an all-singing, all-dancing > compiler. > > Furthermore, if you generate SAC code, the SaC compiler > will happily generate single-thread, multi-thread (pthreads), > GPU [CUDA], and probably other forms of C code out its back end. > > The mode I use in my research of late is to compile APL to > SAC to multi-thread code; the results have been quite > encouraging. > > I am now maintaining APEX under git, on my local machine, > but intend to move it to either github or gitlab, hopefully > in the next month or so, and make it all available under > [I think] the MIT License. I'll send a note when it's available to > the public. > > Bob > > On 2019-06-21 9:28 a.m., Raul Miller wrote: > >> On Thu, Jun 20, 2019 at 7:17 PM Jose Mario Quintana >> <[email protected]> wrote: >> >>> Mind you, I am just thinking aloud and I have no expertise nor experience >>> on this matters. Most likely you have given more thought to this >>> subject. >>> If so, at least, I would like to hear about it. >>> >> Well... I must admit to having started some attempts a few times. >> >> But aiming too high is more likely to shoot yourself in the foot than >> hitting the broad side of a barn. Or... something like that. >> >> Anyways, I never really got anywhere. >> >> Right, but I was just wondering if I were to invest time and money on this >>> kind of project, what would be the chances to be worthwhile. >>> Nevertheless, >>> I find the thought of having a version of J running on multiple computers >>> in a chip, with no clocks, tantalizing. >>> >> Well... it would be a project. >> >> And, I would expect some initial disappointments (no hardware support >> for ieee floating point, and arithmetic might turn out to be a bit >> slow - but that's just the early part of the learning curve, ...). >> Anyways, probably some things would wind up being faster and other >> things could wind up being slower... But maybe the key value would be >> lessons learned during the attempts. >> >> Thanks, >> >> > -- > Robert Bernecky > Snake Island Research Inc > 18 Fifth Street > Ward's Island > Toronto, Ontario M5J 2B9 > > [email protected] > tel: +1 416 203 0854 > text/cell: +1 416 996 4286 > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
