Jump to content
IGNORED

PL65 Code Generation


Alfred

Recommended Posts

With the current interest in the Action! I thought I would take a look at PL65. I had never heard of this language before, and after reading the manual I was quite interested in it. Similar to Action!, but some notable differences, particularly being able to use assembler mnemonics directly in your code.

 

I've spent some hours disassembling the PL65 compiler, and looking at the code it generates in a couple of programs. Sad to say, my initial excitement has waned as it has become apparent that PL65 just doesn't generate very good code at all. I suppose it's faster than Basic, but I expect Action! would beat it handily.

 

The main problem is that virtually everything is done via subroutine. While this is understandable for complex routines like 16 bit multiply or divide, it's rather wasteful when it's employed for simple calculations.

 

Main()

PChar(0,"Hello, World")

End

 

generates

 

Main()

PushByte(0) ; PChar(0,"Hello, World")
PushWord($2cF3)
PushByte(12)
Jsr Pchar
End;

which doesn't seem so bad. However for something a little more involved:

 

Func Str$(Int num)

String Sbuff[16]

Byte a,b

;Begin

jsr PopWord

sta num

sty um+1

;Sbuff[15]="0"

lda #15

jsr PushByte

lda #<addr("0")

ldy #>addr("0")
jsrPushWord

lda #1
jsr PushByte

lda #<sbuff+15

ldy #>sbuff+15
jsr PushWord
jsr Move ; Block copy routine used to move one character

; a= 16

lda #16

sta a

;Repeat

; Dec a

dec a ; handy to use asm code here

; B=num mod 10 + 48

lda num

ldy num+1

jsr Pushword

lda b

jsr PushByte

jsr Mod

lda #48

ldy #0

jsr Add2Stack

 

etc.

 

It's too bad. PL65 has some nice features, but all this stack juggling is wasted effort. It's hard to say, but with all the stack juggling and zero page use in the compiler, I could almost believe that PL65 was itself written in PL65.

 

Maybe if someone gets bored, they can upgrade the compiler.

Edited by Alfred
Link to comment
Share on other sites

I think in the "PL65 cracked" thread there was mention of merging segments of the PL65 produced object file. It's true, PL65 produces a horrendous binary, segments galore like the nonsense you see with Mac/65, except for one thing: IT'S WORSE !

 

Running a segment merger like Unify.com against a PL65 output binary is useless because PL65 doesn't output any of the filler bytes used as temporary variables in the code. Thes result is dozens or hundreds of segments which are separated from each other by one or two bytes in many cases. Loading this kind of binary is akin to watching paint dry and is a good reason all by itself for avoiding this compiler.

Link to comment
Share on other sites

With the current interest in the Action! I thought I would take a look at PL65. I had never heard of this language before, and after reading the manual I was quite interested in it. Similar to Action!, but some notable differences, particularly being able to use assembler mnemonics directly in your code.

 

I've spent some hours disassembling the PL65 compiler, and looking at the code it generates in a couple of programs. Sad to say, my initial excitement has waned as it has become apparent that PL65 just doesn't generate very good code at all. I suppose it's faster than Basic, but I expect Action! would beat it handily.

 

The main problem is that virtually everything is done via subroutine. While this is understandable for complex routines like 16 bit multiply or divide, it's rather wasteful when it's employed for simple calculations.

 

Main()

PChar(0,"Hello, World")

End

 

generates

 

Main()

 

PushByte(0) ; PChar(0,"Hello, World")

PushWord($2cF3)

PushByte(12)

Jsr Pchar

End;

 

which doesn't seem so bad. However for something a little more involved:

 

Func Str$(Int num)

String Sbuff[16]

Byte a,b

;Begin

jsr PopWord

sta num

sty um+1

;Sbuff[15]="0"

lda #15

jsr PushByte

lda #<addr("0")

ldy #>addr("0")

jsrPushWord

lda #1

jsr PushByte

lda #<sbuff+15

ldy #>sbuff+15

jsr PushWord

jsr Move ; Block copy routine used to move one character

; a= 16

lda #16

sta a

;Repeat

; Dec a

dec a ; handy to use asm code here

; B=num mod 10 + 48

lda num

ldy num+1

jsr Pushword

lda b

jsr PushByte

jsr Mod

lda #48

ldy #0

jsr Add2Stack

 

etc.

 

It's too bad. PL65 has some nice features, but all this stack juggling is wasted effort. It's hard to say, but with all the stack juggling and zero page use in the compiler, I could almost believe that PL65 was itself written in PL65.

 

Maybe if someone gets bored, they can upgrade the compiler.

 

I remember looking at the code PL65 generated back when that "PL65 Cracked" thread first popped up. The took an approach that made code generation fairly easy, but the tradeoff is very inefficient code. Action jumps through a lot of hoops get the code as tight as it does. 6502 is a challenging processor to write a compile for.

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.
Note: Your post will require moderator approval before it will be visible.

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.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...