TIP: Click on subject to list as thread! ANSI
echo: rberrypi
to: GORDON HENDERSON
from: GARETH`S DOWNSTAIRS COMPU
date: 2018-04-23 12:33:00
subject: Re: Apologies where they

On 23/04/2018 09:16, Gordon Henderson wrote:
> In article ,
> Gareth's Downstairs Computer 
 wrote:
>
>> However, it remains that my computing interest, resulting
>>from my first real job 45 years ago, is to produce an
>> interactive programming language (the interactivity
>> of BASIC or FORTH) but that runs at the speed of compiled
>> code and yet is fully reconstructable as the original source.

> One of many issues regarding speed, might be the efficiency of the current
> compilers for e.g. C which can perform instruction re-ordering, register
> re-use and so on - de-compiling that into something that resembled the
> original source code may well be impossible - that is, if you're trying to
> achieve the speed and efficiency of a modern compiler. If you take a more
> linear/simplified approach then you might get something that can work.

Assuming that you have retained some symbol table, then at each access
of a variable you pick up its name in a string, eg FirstVariable.

Then, taking addition as an example, you build up another string
by concatenating the 1st access, the plus sign and the second access
to give you "FirstVariable + SecondVariable" and keep building
up the string in the same way until you have the complete expression.

This will still work after some optimisations, but you must no allow
dead code elimination because that code might be dead because it has not
yet been fully edited (in my scheme where the tokens of the source code
are the executable instructions)

>
> FWIW: My experience of BASICs over the past 40 years is that most of
> the interactive ones (but not all) tokenise the input, line at a time,
> as you enter it. So the LIST command essentially "de-compiles" the
> tokenised code. The tokenised code is effectively pseudo-code for some
> "perfect" BASIC CPU (or not, in some cases).

Same as my experience over a similar time period :-)

>
> Having written my own BASIC interpreter in recent years, I found that
> this way was not always perfect - you lose things like indentation and
> your own personal style of capitalisation (PRINT, Print, ?, GoTo and so on)
and
> you only need to look at something like AppleSoft BASIC for another example
> where it tries to line statements up on the left, but when you miss out the
LET
> command it looks weird... You type in:
>
>    100 REM Test
>    110 A = 5
>    120 FOR I = 1 to A
>
> and you get
>
>    LIST
>    100  REM Test
>    110 A = 5
>    120  FOR I = 1 to A
>
> and so on.

Indentation is determined by the program structure; not to me a problem.

>
> Then there's expression evaluation - In a fit of CompSci, I used Dijkstra's
> Shunting Yard ...

I never knew of that attribution, but I've been using it for years! One
of the side effects of a degree in electronics where one has to be
self-inventive as opposed to a comp sci degree where you'd get taught
all the attributions. eg, in PDP11 assembler re-invented the wheel
and discovered later its attribution as an Iliffe Vector.

> ... to turn expressions into an RPN stack when could then be executed
> at run-time, so
>    100 a = b + c * d
> becomes
>    c d * b + => a
> how to de-compile that into the original? It's harder as the ordering
> has now been changed.

Actually straightforward, and covered in a previous post, and with
the string based decompilation discussed above, is the reason
for wanting the two forms ...

ADD R2,R2,R3   and ADD R2,R3,R2 so that the correct original
ordering is maintained.

> I have looked at compiling my BASIC to native code - and there is more
> or less a 1:1 relationship with a line of BASIC and a Line/Block of ASM
> - it's no-where near efficient as C though (and 'compiling' BASIC into
> C is just as easy and may actually result in faster code, but that's a
> job for another day)

I agree with that, BTDTWTS !!!!!

> Another thing you might want to look at is the Gigatron computer. It's
> a kit computer project, but part of it features code for a virtual CPU
> which runs on-top of the (very) RISC 8-bit computer. The syntax is
> somewhat eseoteric though, but I suspect it could be de-compilable.
> This is a horizontal/or vertical line drawing function in their GCL
> (Gigatron Control Language)
>
> [def
> {-
>    DrawLine -- Draw line
> -}
>    Count i=   // Take value of Count, store in i
>    [do if>0   // While Acc > 0
>      Color Pos.   // Fetch Colour, store @ Pos: poke (pos, colour)
>      Pos Step+ Pos=  // Add Step to pos, store in pos.
>      i 1- i=   // i = i - 1
>      loop]
>    ret
> ] DrawLine=

My God! Thoght for a moment I was reading my CRAP language from 1986,
but the derivation from FORTH is instantly recognisable!

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | FidoUsenet Gateway (3:770/3)

SOURCE: echomail via QWK@docsplace.org

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.