Jump to content

X16 apex 3GL: "ALGOL X16" / Structured BASIC


rje
 Share

Recommended Posts

I've thought about Paul Scott Robson's Structured BASIC, and I think that's pretty much a kind of ALGOL, and also pretty near the apex for any imperative language "running" "native" on the X16.

* * *

Suppose I were to migrate an imperative language to the X16.

import java.util.regex.*;
  
public class GFG {
    public static void main(String[] args)
    {
        // Get the regex to be checked
        String regex = "Geeks";
  
        // Create a pattern from regex
        Pattern pattern = Pattern.compile(regex);
  
        // Get the String to be matched
        String stringToBeMatched = "GeeksForGeeks";
  
        // Create a matcher for the input String
        Matcher matcher = pattern.matcher(stringToBeMatched);
  
        // Get the Pattern using pattern() method
        System.out.println("Pattern: " + matcher.pattern());
    }
}


1. I'll start with Java, JavaScript, or, yes, Python or Smalltalk or other OO-like languages.  First, I suspect that resources are too limited for a class and object system, though I could be wrong.  So the syntax of these critters effectively reduces to that of Perl or C, perhaps with some special extra types for things we lose when leaving OO.

import java.util.regex.*;

void main(int argc, String[] argv)
{
    // Get the regex to be checked
    String regex = "Geeks";
  
    // Create a pattern from regex
    Pattern pattern = Pattern_compile(regex);
  
    // Get the String to be matched
    String stringToBeMatched = "GeeksForGeeks";
  
    // Create a matcher for the input String
    Matcher matcher = pattern_matcher(stringToBeMatched);
  
    // Get the Pattern using pattern() method
    println("Pattern: " + matcher_pattern());
}


2. Now we're at Perl, C, and related things.  These will experience the same reductions when porting to the X16: braces don't exist, and significant regular expressions don't either, and so we reduce scope while also moving to syntax brackets like BEGIN and END.  Thus the syntax of these tend to merge with Pascal.

import java.util.regex.*;

void main(int argc, String[] argv)
begin
    // Get the string to be checked
    String regex = "Geeks";
  
    // Create a pattern from regex
    pattern_compile(regex);
  
    // Get the String to be matched
    String stringToBeMatched = "GeeksForGeeks";
  
    // Call the simple pattern matcher on the input String
    simple_pattern_matcher(stringToBeMatched);
  
    // Get the match using matcher_pattern() method
    println("Pattern: " + matcher_pattern());
end

 

3. Now we're at some variant of Pascal, and we find we probably have to lose slices, strong "do it yourself" type systems, structures (?), any sense of an object system, and probably the general use of hashtables.  Maybe we can save an "environment" table, which may have interesting environment variables and be partly useable as one general purpose hashtable.  Maybe.  This moves us to some version of ALGOL -- complete with capital letters.

 

IMPORT JAVA.UTIL.REGEX.*;

VOID MAIN(INT ARGC, STRING[] ARGV)
BEGIN
    // GET THE STRING TO BE CHECKED
    STRING REGEX = "GEEKS";
  
    // CREATE A PATTERN FROM REGEX
    PATTERN_COMPILE(REGEX);
  
    // GET THE STRING TO BE MATCHED
    STRING STRING_TO_BE_MATCHED = "GEEKS_FOR_GEEKS";
  
    // CALL THE MATCHER WITH THE INPUT STRING
    SIMPLE_PATTERN_MATCHER(STRING_TO_BE_MATCHED);
  
    // GET THE PATTERN USING MATCHER_PATTERN()
    PRINTLN("PATTERN: " + MATCHER_PATTERN());
END

 

4. Now we're somewhere in ALGOL.  The type system is next to be simplified.  

After using CC65 and considering Paul Scott Robson's posts and S-BASIC, I recommend throwing out floating point.  Also, we use something like the ALGOL key word REF, (or the more obvious PTR), to indicate a pointer.  The word itself isn't important.

IMPORT JAVA.UTIL.REGEX.*;

PROC MAIN(INT ARGC, PTR STRING ARGV) // ??
BEGIN
    // GET THE STRING TO BE CHECKED
    STRING REGEX = "GEEKS";

    // CREATE A PATTERN FROM REGEX     
    PATTERN_COMPILE(REGEX); 
    
    // GET THE STRING TO BE MATCHED
    STRING STRING_TO_BE_MATCHED = "GEEKS_FOR_GEEKS";
  
    // CALL THE MATCHER WITH THE INPUT STRING
    SIMPLE_PATTERN_MATCHER(STRING_TO_BE_MATCHED);
  
    // GET THE PATTERN USING MATCHER_PATTERN()
    PRINTLN("PATTERN: " + MATCHER_PATTERN());
END

5. The X16 doesn't really have a shell environment, so we change MAIN to be a regular PROC with params.

I doubt libraries will exist, so that goes.

Maybe (not sure) sigils come back in.  If it reduces the complexity or resource use of the runtime, then sigils are an obvious choice.  If not, then no need to have them.  But if so, it would plant us firmly back in a form of Structured BASIC.

CALL MATCH_TEST( "GEEKS", "GEEKS_FOR_GEEKS" );
END

// REGEX$: THE STRING TO BE CHECKED 
// STRING_TO_BE_MATCHED$: THE STRING TO BE MATCHED
PROC MATCH_TEST(PTR REGEX$, PTR STRING_TO_BE_MATCHED$)
BEGIN  
    // CREATE A PATTERN FROM REGEX    
    PATTERN_COMPILE(REF REGEX$); 

    // CALL THE MATCHER WITH THE INPUT STRING
    SIMPLE_PATTERN_MATCHER(REF STRING_TO_BE_MATCHED$);
  
    // GET THE PATTERN USING MATCHER_PATTERN()
    PRINTLN("PATTERN: " + MATCHER_PATTERN());
END
Edited by rje
Link to comment
Share on other sites

Are you just talking about the compilation / translation running on the hardware?

Also, I think these are all still examples of imperative programming languages. Declarative is more you tell the language what you want and it figures out how to do it. Imperative is you tell it how to accomplish the task. I guess by that definition all high level languages are in some sense declarative as well (as they figure out how to generate the tokens or machine language) but you are still expressing algorithms, where you don't with declarative (like SQL).

  • Thanks 1
Link to comment
Share on other sites

  • rje changed the title to X16 apex 3GL: "ALGOL X16" / Structured BASIC

Yes, I'm old and distracted.

Quote

Are you just talking about the compilation / translation running on the hardware?

I guess I have to be talking about compiling and/or interpreting on the hardware.

Which is kind of moot:  I find it very hard to think of a reason to write code directly on these machines.

(1) Batch-like coding, e.g. testing something or launching something else.

(2) There doesn't appear to be a #2.

I had thought that perhaps some filtering could be done on the X16.  E.G. an AWK-like program that sifts file contents.

Not sure.

 

Edited by rje
Link to comment
Share on other sites

It's harder to justify writing code on these machines given the relative performance we can get from even 10 year old computers at this point. But sometimes you do it just because you can. Because it's fun. In my opinion, the ideal way to write code on these (based on some stuff I did with my C=64 back in the day) is to write stuff in BASIC. Be able to run and test without a lengthy compile / assemble / link / transfer / run cycle. Then use a BASIC compiler to create the optimized version in the end.

Link to comment
Share on other sites

Yes, and I'm always looking for something to give that old BASIC 2.0 a bit of a boost.

Adding DOS was absolutely required and appreciated, as is subdirectory support, and hexadecimal numbering.

I admit the idea of compiled BASIC makes my skin crawl tho'.

 

Edited by rje
Link to comment
Share on other sites

It's not "the best" language if you're trying to eek out performance. I'd rather see something more like BASIC 7 with some structured commands and such, but still with the ability to compile to some intermediate form. Even if it isn't fully compiled directly to machine language, there are so many things that can be done to improve performance if you don't have to fully reinterpret a line every time it comes up.

When I wrote my (really crappy) C=64 BBS, it's how I did it. It was nice having the interactivity of editing the program in BASIC as I always would and the ability to run it (though more slowly) without compilation.

Is the idea of compiled BASIC skin crawly because of the BASIC or is there another reason?

Link to comment
Share on other sites

I found pretokenising more seriously helped quite a lot. These days the only actual ASCII I have is text - strings and comments (that's why in my BASICs the REM / Comment is always in quotes). Identifiers are tokenised using an identifier marker, usually at the start (say codes 0-27 allowing for A-Z _ and maybe .). Constants are tokenised using 5 or 6 bits of the byte, which reduces size and saves you a lot of multiplying by 10.  Strings are usually put in with a length prefix e.g. <String Marker> 5 H E L L O so you don't have to scan over the ruddy things.

 

Link to comment
Share on other sites

On 9/29/2021 at 12:04 AM, rje said:

Yes, and I'm always looking for something to give that old BASIC 2.0 a bit of a boost.

Adding DOS was absolutely required and appreciated, as is subdirectory support, and hexadecimal numbering.

I admit the idea of compiled BASIC makes my skin crawl tho'.

 

It actually doesn't really work. It is the classic 6502 problem. If you use a VM it's compact but you get a 90% speed hit on that VM. If you use code, it's very long winded. Adding two 16 bit numbers in 6502 assembler is 19 bytes - three loads, three adds, three stores and CLC if you don't use zero page, which you really can't for general use variables.  Interim solutions like JSR <add> .WORD v1 .WORD v2 don't work well either.

Link to comment
Share on other sites

On 9/29/2021 at 6:10 AM, paulscottrobson said:

It actually doesn't really work. It is the classic 6502 problem. If you use a VM it's compact but you get a 90% speed hit on that VM. If you use code, it's very long winded. Adding two 16 bit numbers in 6502 assembler is 19 bytes - three loads, three adds, three stores and CLC if you don't use zero page, which you really can't for general use variables.  Interim solutions like JSR <add> .WORD v1 .WORD v2 don't work well either.

What doesn't really work, and in what way does it not work?

As I read this thread and from my perspective "work" means "write a more performant program". Compiling a high level language to some other form that need not be interpreted byte by byte definitely works. Yes, 16 bit arithmetic on an 8 bit CPU is going to be verbose. Yes, a VM is going to be out performed by machine language. But those choices are a huge part of software engineering: picking from a palette of options to create the best program within the constraints provided.

Link to comment
Share on other sites

What exactly the Basic is used for? For doing the ultimative first steps in programming it is OK. But for writing real nontrivial programs or games with it, it would be much too cumbersome for me (I'm used to IntelliJ IDEA since nearly 20 years).

Whatever language I would use for developing serious software for the X8/16 hardware using a PC (even if it is just assembler) - it would be very cool to have some kind of hardware debugger available that allows me to step through the commands (in the language I use), see all the registers and memory contents. I had a disassembler and debugger on my 8-bit machine - without them I would not have been able to write that much code.

Link to comment
Share on other sites

BASIC has three uses:

1. Small programs that don't require speed.  Classic "business simulation" games from the 1970s.  Some PETSCII games like Lunar Lander.

--> Ambitious programs like Temple of Apshai can be written, but we're better off doing them in something other than BASIC.

2. Prototyping, as you mentioned.

3. Batch scripting.  In other words, as the pseudo shell command interpreter for Commodore machines.

 

  • Like 1
Link to comment
Share on other sites

On 9/29/2021 at 12:43 PM, Ju+Te said:

Whatever language I would use for developing serious software for the X8/16 hardware using a PC (even if it is just assembler) - it would be very cool to have some kind of hardware debugger available that allows me to step through the commands (in the language I use), see all the registers and memory contents. I had a disassembler and debugger on my 8-bit machine - without them I would not have been able to write that much code.

There's two things for the X16.  First, there's a built-in machine language monitor.  Second, the emulator has a debugger.  Third, there's a rather nicely featured assembly development environment that's .. well I thought it was in Downloads, but perhaps not.

Link to comment
Share on other sites

On 9/30/2021 at 9:36 AM, Ju+Te said:

Would it technically be possible to have a debugger work on the 6502, e.g. by setting an ultra short timer that fires an interrupt after having executed one command?

The simple method of step debugging without hardware support is to inject a BRK opcode immediately following the statement being executed. The BRK handler then  pulls the CPU state off the stack and replaces the original opcode. Obviously, your debugger needs to know the length of each opcode, but any decent debugger includes a disassembler, so the step debugger can look that up in the disassembler's opcode length table.

 

 

 

 

Edited by TomXP411
Link to comment
Share on other sites

On 9/28/2021 at 3:21 PM, rje said:

Yes, I'm old and distracted.

I guess I have to be talking about compiling and/or interpreting on the hardware.

Which is kind of moot:  I find it very hard to think of a reason to write code directly on these machines.

(1) Batch-like coding, e.g. testing something or launching something else.

(2) There doesn't appear to be a #2.

I had thought that perhaps some filtering could be done on the X16.  E.G. an AWK-like program that sifts file contents.

Not sure.

 

#2 Coding on a system that doesn't have a web browser to distract you from programming.

#3 Tinkering with hardware without an other system compile / transfer / test / edit / other system compile ... loop

Edited by BruceMcF
  • Like 1
  • Haha 2
Link to comment
Share on other sites

On 9/30/2021 at 9:33 AM, rje said:

There's two things for the X16.  First, there's a built-in machine language monitor.  Second, the emulator has a debugger.  Third, there's a rather nicely featured assembly development environment that's .. well I thought it was in Downloads, but perhaps not.

Are you thinking of this environment? - https://sites.google.com/view/x16asmenv/home
The roadmap suggest that it will be in the ROM for the shipping version.


 

  • Like 2
Link to comment
Share on other sites

  • 3 weeks later...
On 9/30/2021 at 12:41 PM, Ju+Te said:

So this won't work for debugging the ROM?

PS: Sorry for having hijacked this thread.

THAT topic is worth hijacking this thread for.

 

The emulator has a debug console.  So... potentially... you might be able to use it to debug the ROM.  In fact I betcha that's what was used to debug the emulator as it was being written, so to speak.

 

So for instance, I could monkey with the ROM -- say, replace a KERNAL routine with one of the open source ones -- then fire up the emulator.  I *think* I would be able to TEST that KERNAL routine by inspecting memory with the debugger after that routine is called -- some of them are called when the system starts up, and some I'd have to set up and trigger myself (probably with a little C program).

 

In fact one might could write a little C program that can run a test suite on the KERNAL.

 

Maybe?

Edited by rje
Link to comment
Share on other sites

On 10/19/2021 at 1:41 PM, rje said:

So for instance, I could monkey with the ROM -- say, replace a KERNAL routine with one of the open source ones -- then fire up the emulator.  I *think* I would be able to TEST that KERNAL routine by inspecting memory with the debugger after that routine is called -- some of them are called when the system starts up, and some I'd have to set up and trigger myself (probably with a little C program).

Do you really need to mess with the ROM? IIRC you can changes some vectors in page 02 or 03 to use your own API rather than the Kernel. 

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use