I’ll interleave my responses ** below as Shlomi did (again, should anyone
care about this)...
From: Shlomi Fish shlomif_at_shlomifish.org [fc-solve-discuss]
Sent: Wednesday, July 15, 2015 7:02 AM
To: 'Gary Campbell' gary_at_numin8r.us [fc-solve-discuss]
Subject: Re: 1.47% Speed Improvement in the Benchmarks in the git HEAD
Hi Gary,
see below for my reply.
On Tue, 14 Jul 2015 10:03:35 -0700
"'Gary Campbell' gary_at_numin8r.us [fc-solve-discuss]"
<fc-solve-discuss_at_yahoogroups.com> wrote:
> I have a rather lengthy response to this if anyone cares to read it.
>
Was your response the E-mail you sent (because it wasn't too lengthy) or do
you
have a longer response?
**It’s long for me, maybe short for you.
> I’ve been retired from being a paid software engineer since 1991.
> Some 15 years before that I decided to tackle the problem of code
> (especially assembly language) being hard to read (and write).
> I developed a WYSIWYG block structured assembly language and
> an assembler for it written in itself.
You call your language "WYSIWYG" which means
https://en.wikipedia.org/wiki/WYSIWYG - "What you see is what you get", but
I
don't understand how it is applicable to source code, and furthermore I have
never found WYSIWYG a virtue in word processors. And like my old friend said
once after describing MS Word's misbehaviour "It's not what I see, and it's
not what I'm getting.".
** when programmers use a block structured language, they generally try to
indent to conform with the block structure, but the language doesn't require
it. My language uses indentation to actually control blocks structure,
rather
and using keywords. Therefore, the appearance of white space controls
program flow (what you see is what you get).
> In 2002 I finished a version of
> it and became interested in writing a Freecell Solver. I pursued that
> until around my 71st birthday, this June. My solver’s claim to fame
> is the very small amount of machine resources it takes to get very
> close on all performance scales to the best of the other solvers out
> there. But, I haven’t improved any of my benchmarks for years.
> All I can say for the past few years is that I’ve refined a lot of my
> solver’s components, and have a very nice table driven design.
>
What is a "table-driven design"?
** Various attribute are given to moves and positions. These attributes
are used for table lookup to assign priorities to moves. Various sorting
and pruning decisions are made based on lookup tables. This makes it
easier to adjust the design here and there.
> However, my solver only runs on the old version of Windows XP due
> to the fact that my assembler only outputs a .COM file which is no
> longer acceptable to the latest operating systems.
>
Well, you can still probably run it on DOS emulators such as
https://en.wikipedia.org/wiki/DOSBox (or one of its more active forks) as
well
as DOS implementations like
https://en.wikipedia.org/wiki/FreeDOS under
i586 Virtual Machines such as
https://en.wikipedia.org/wiki/VirtualBox (or on live hardware). That put
aside, what you describe is part of the risk of relying on proprietary
systems
to deploy your code to:
** Of course. That's what I have to do, but it would be nice to generate
code
for a normal out-of-the-box machine. Not everyone wants to run DOSBox, or
something similar, however, I do and have been ever since MS stopped the
support of the old XP operating system.
http://www.shlomifish.org/humour/fortunes/show.cgi?id=the-old-shareware-and-the-android-apps
> This made me decide to suspend work on Freecell and revisit my
> assembler. There is no doubt in my mind that it makes a unique
> contribution to assemblers, and even to the design of compilers
> and languages in general,
How so? What is your secret sauce?
** If anyone wants one of the main source modules of my Freecell Solver,
email me directly, and I'll attach it to a reply directly back to you. That
will enable you to see what it looks like. It is supported by a syntax
driven translator. What my next project will entail is to extend the
compiler generator and its meta language.
> so I’m off on another project to bring
> it up to date with 32-bit processors and the PE/COFF object file
> formats. This ought to keep me busy until I’m into my mid-to-
> late –70’s!
One should note that there are already 64-bit processors (e.g:
https://en.wikipedia.org/wiki/X86-64 ) and operating systems.
** Yes, but that will come right along with the 32-bit version.
The 64-bit extensions are pretty trivial compared to those that
extended 16 to 32 bit.
> Then, maybe I’ll bring my Freecell project onto the
> latest machines.
I see.
>
> If anyone is interested in any of this, you should probably contact
> me directly, since it diverges from the main intent of this group.
>
Feel free to discuss it here if you want.
** I'd rather make this my last post to the Freecell forum for awhile.
If anyone wants to take this off line, send me an email.
Finally note that given today's compilers and the complexity of the CPUs, it
is
likely that the vast majority of Assembly coders will code less optimised
code
than that of modern and optimising C/C++ compilers.
** If you believe this, I'm sure I could find a bridge somewhere to sell
you.
Regards,
Shlomi Fish
--
----------------------------------------------------------
Shlomi Fish http://www.shlomifish.org/
NSA Factoids - http://www.shlomifish.org/humour/bits/facts/NSA/
One of my most productive days was throwing away 1,000 lines of code.
— Ken Thompson (Attributed)
Please reply to list if it's a mailing list post - http://shlom.in/reply .
Received on Wed Jul 15 2015 - 10:41:32 IDT