This discussion is ringing old memory bells. Way back in 1970, the IBM Palo Alto Scientific Center had a project that exploited the 370/145's willingness to let users modify microcode. The folks at the Scientific Center created microcode that dramatically speeded up loopy scalar APL programs. It was interesting that they called the system an APL machine with a software assist (the adapted APL\360 coded modified to exploit the microcode).
As I recall, it kind of encouraged APLTRAN but didn't fare well with carefully constructed APL applications - I'm not sure if it got much use inside IBM and I don't think it was ever released to customers. - joey > On 2021Aug 28, at 21:01, Henry Rich <[email protected]> wrote: > > Thanks for the reference. By my analysis, the beta-o parser would not be any > faster than it is if it had to verify the types of its arguments. > > Your last point is absolutely right, and yet I want to ignore it. Experienced > J programmers have learned ways to avoid sentences that do little work. > Programmers new to J write what I call JTRAN: FORTRAN code translated to J, > with lots of scalar arithmetic. With a little experience they will write > better J, but I don't want to lose them before they get the experience. I am > trying to make the parser execute JTRAN efficiently. > > And, most of us lapse into JTRAN occasionally. (maybe not Roger) > > Henry Rich > > > On 8/28/2021 11:37 PM, Elijah Stone wrote: >> On Sat, 28 Aug 2021, Henry Rich wrote: >> >>> Large improvement would require heroic intervention: parsing & caching >>> sentences on the fly & watching assignments to make sure the cached parse >>> is valid. I would rather avoid that. >> >> The technique has been implemented, to great effect - >> http://www.softwarepreservation.org/projects/apl/Papers/DYNAMICINCREMENTAL >> >> That implementation placed the invalidation in the parsed (and compiled) >> sentence itself, rather than invalidating existing sentences on assignment, >> which simplified matters; before a sentence is executed, the inferred >> nameclasses of its referents are verified. This is much simpler and easier >> to get right, and retains similar performance (especially with modern branch >> predictors). >> >> That being said, if the parser is a bottleneck for some code, then it is >> likely doing something wrong and should perhaps not be encouraged :) >> >> -E >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm > > > -- > This email has been checked for viruses by AVG. > https://www.avg.com > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
