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
