Is there any upgrades for the P2 Propeller Tool editor?

Capt. Quirk · 2020-01-11 04:55

Any improvements for P2-Propeller Tool's:
find/replace, select all, or the workspace?

Bill M.

Cluso99 · 2020-01-11 05:00

You can edit P2 code in PropTool. If you call it xxx.spin instead of xxx.spin2 you will get the P1 code coloring. Of course PropTool does not know about the P2 instructions.

I'm starting to use VS Code to edit P2 code. I use it every day at work for Python programming.

cgracey · 2020-01-11 05:42

I've almost got the Spin2 compiler finished for the P2, and it's running in PNut.exe. Next week, we will start integrating it into the Propeller Tool for release soon.

Cluso99 · 2020-01-11 05:50

Chip,
Does that mean that a lot of P1 spin will just work on P2?

If yes, can you post an updated pnut so I can give it a try out please?

I've been trying to port Kye's SD_FAT code (the upper level which gives file access as I've done the PASM code already). It would be so much easier if I could just use spin2 and fix just the specific compile errors

And will you release the compiler code to Eric so he can put it into Fastspin?

rogloh · 2020-01-11 05:51

Any plans for non-Windows P2 users and Spin2?

cgracey · 2020-01-11 07:00

Cluso99 wrote: »

Chip,
Does that mean that a lot of P1 spin will just work on P2?

If yes, can you post an updated pnut so I can give it a try out please?

I've been trying to port Kye's SD_FAT code (the upper level which gives file access as I've done the PASM code already). It would be so much easier if I could just use spin2 and fix just the specific compile errors

And will you release the compiler code to Eric so he can put it into Fastspin?

The new language has some differences from the old one. I plan to make a language description soon that covers everything in Spin2 and has a section on the differences between Spin and Spin2. It's 95% the same. Mainly, we can accommodate multiple return values now and ABORT works a little differently. Also, a lot of operators have changed to more textual versions, but maybe all the old ones can be supported, as well, for compatibility.

I want to get it complete before I put it out, but I may only be a few days from that.

The compiler code is all in 80386, so maybe nobody would want to look at it. The language description will be quite sufficient to support compiler writers.

cgracey · 2020-01-11 07:01

rogloh wrote: »

Any plans for non-Windows P2 users and Spin2?

Not immediately. We are using what we have that works in Windows and updating it for Spin2, as a first effort.

rogloh · 2020-01-11 07:28

cgracey wrote: »

rogloh wrote: »

Any plans for non-Windows P2 users and Spin2?

Not immediately. We are using what we have that works in Windows and updating it for Spin2, as a first effort.

Pity.

Does the x86 compiler codebase use standard DOS/BIOS calls or does it make use of Windows API? I wonder if it might run in some DOSBox type of environment on non-Windows PCs?

Cluso99 · 2020-01-11 07:49

cgracey wrote: »

Cluso99 wrote: »

Chip,
Does that mean that a lot of P1 spin will just work on P2?

If yes, can you post an updated pnut so I can give it a try out please?

I've been trying to port Kye's SD_FAT code (the upper level which gives file access as I've done the PASM code already). It would be so much easier if I could just use spin2 and fix just the specific compile errors

And will you release the compiler code to Eric so he can put it into Fastspin?

The new language has some differences from the old one. I plan to make a language description soon that covers everything in Spin2 and has a section on the differences between Spin and Spin2. It's 95% the same. Mainly, we can accommodate multiple return values now and ABORT works a little differently. Also, a lot of operators have changed to more textual versions, but maybe all the old ones can be supported, as well, for compatibility.

I want to get it complete before I put it out, but I may only be a few days from that.

The compiler code is all in 80386, so maybe nobody would want to look at it. The language description will be quite sufficient to support compiler writers.

Thanks Chip.
There isn't anything in the code that will be difficult to convert if necessary apart from looking at the abort code.
So I'm looking forward to trying it

cgracey · 2020-01-11 08:19

rogloh wrote: »

cgracey wrote: »

rogloh wrote: »

Any plans for non-Windows P2 users and Spin2?

Not immediately. We are using what we have that works in Windows and updating it for Spin2, as a first effort.

Pity.

Does the x86 compiler codebase use standard DOS/BIOS calls or does it make use of Windows API? I wonder if it might run in some DOSBox type of environment on non-Windows PCs?

Neither. It communicates with the host application through data structures. The host application (written in Delphi Pascal) does the storage, I/O, and user interface.

Wuerfel_21 · 2020-01-11 09:17

How difficult would it be to create a command-line compiler for Linux?
(The big problem here is that most PCs these days have AMD64 CPUs and running 32bit x86 code on AMD64 Linux (multiarch) takes a bit of fiddling and package-installing)
If the compiler is decently quick this time round, it could also be ran on ARM/POWER/MIPS/whatever through QEMU emulation.

cgracey · 2020-01-11 09:29

Wuerfel_21 wrote: »

How difficult would it be to create a command-line compiler for Linux?
(The big problem here is that most PCs these days have AMD64 CPUs and running 32bit x86 code on AMD64 Linux (multiarch) takes a bit of fiddling and package-installing)
If the compiler is decently quick this time round, it could also be ran on ARM/POWER/MIPS/whatever through QEMU emulation.

I wonder how complex it is to turn 32-bit x86 code into ...into what? What is it even called? Is there some standard? What makes 64-bit code?

cgracey · 2020-01-11 09:31

Here is the answer:

https://software.intel.com/en-us/articles/introduction-to-x64-assembly

With SIMD instructions, you might as well not program in assembly, since you wouldn't want to be bothered with figuring out how to pack in multiple data operations. Better to have a smart compiler get you good performance. They say near the beginning that x64 assembly is good to know if you are needing to locate bugs from compiler output or analyzing malware, but it's more practical to write in C and let the compiler figure out the SIMD (single-instruction multiple-data) instructions for you, as most programmers won't be able to better the performance of C. Sigh...

Wuerfel_21 · 2020-01-11 10:15

l

cgracey wrote: »

With SIMD instructions, you might as well not program in assembly, since you wouldn't want to be bothered with figuring out how to pack in multiple data operations. Better to have a smart compiler get you good performance. They say near the beginning that x64 assembly is good to know if you are needing to locate bugs from compiler output or analyzing malware, but it's more practical to write in C and let the compiler figure out the SIMD (single-instruction multiple-data) instructions for you, as most programmers won't be able to better the performance of C. Sigh...

It's less about the SIMD instructions (which in the cases where they're most useful (vector/matrix operations) would obvious if their names weren't so cryptic) and more about the instruction pipeline and getting it to issue as many instructions at once as possible.
But yes, in most(but not all) cases, a C++ compiler will generate something about as good as you would have written.

PropGuy2 · 2020-01-11 14:46

Super excited to hear "I've almost got the Spin2 compiler finished for the P2" and also hoping there will be some new commands / key words for the Smart Pins included in the release.

cgracey · 2020-01-11 16:42

PropGuy2 wrote: »

Super excited to hear "I've almost got the Spin2 compiler finished for the P2" and also hoping there will be some new commands / key words for the Smart Pins included in the release.

Yes, the last things I need to add to the interpreter/compiler are some commands to facilitate smart pin usage. I need to think of what they ought to be and how much they should attempt to do.

I worked all night and got the last hard thing in the interpreter and compiler working: COGSPIN, which is like COGINIT for Spin. I could call it COGINIT, but then we'd have to put () around methods to force a PASM-style COGINIT, in case a method was used as the program-address parameter. Maybe better to keep them separate keywords.

Here is a little program I tested it with:

CON _clkfreq = 3_333_333

PUB go | i, stack[8*10]
  repeat i from 7 to 0
    cogspin(i,doit(56+i),@stack[i*10])

PRI doit(i)
  repeat
    pinnot(i)
    waitms(i*4)

Here's with a method pointer:

CON _clkfreq = 3_333_333

PUB go | i, j, stack[8*10]
  j := @doit
  repeat i from 7 to 0
    cogspin(i,j(56+i),@stack[i*10])

PRI doit(i)
  repeat
    pinnot(i)
    waitms(i*4)

I actually still need to code the for obj{[]}.pub{[]} case in the middle parameter. This is exceptional because it doesn't do what it looks like it does, as it never calls the method, but sets it up as an initial method to start the interpreter on.

Here's the interpreter code that does COGSPIN:

'
'
' COGSPIN(cog,method(parameters),stackadr)
'
' compile sequence:
'
'	cog
'	0..127 parameters
'	method pointer
'	stackadr
'	bc_hub
'	bc_cogspin
'	byte: parameter count
'	bc_coginit/bc_coginit_push
'
' on entry:
'
'	x	 = stackadr
'	ptra[-1] = method pointer
'	ptra[-2] = last parameter
'	ptra[-?] = first parameter
'	ptra[--] = cog
'	ptra[--] = prior top of stack
'
' on exit:
'
'	x	 = stackadr			ready for COGINIT(cog,pgm,ptr)
'	ptra[-1] = @launch_spin
'	ptra[-2] = cog | %10_0000
'	ptra[-3] = prior top of stack
'
cogspin_	mov	v,x			'save stackadr

		popa	y			'pop method pointer (vbase | method<<20) into y
		rdlong	x,y			'get pbase into x
		setq	#2-1			'write pbase and vbase at stackadr
		wrlong	x,v

		rdbyte	x,pb			'read #parameters
		add	pb,#1		wz	'advance pointer, z=0 for move_fwd_loop

		mov	y,x			'ptrb points to first parameter
		shl	y,#2
		subr	y,ptra			'(move_fwd_loop sets ptra to y and pops x)
		mov	ptrb,y

		mov	ptra,v			'ptra points to parameter destination
		add	ptra,#4*4

		call	#move_fwd_loop		'copy any parameters, x=cog and ptra=@cog after

		or	x,#%10_0000		'set cog to hub-exec
		mov	y,##launch_spin		'set pgm to @launch_spin
		setq	#2-1			'push cog/pgm
		wrlong	x,ptra++
	_ret_	mov	x,v			'get stackadr on top of stack, ready for COGINIT(cog,pgm,ptr)
'
'
' Launch Spin - runs via COGINIT
'
' on entry:
'
'	ptra[0]  = pbase
'	ptra[1]  = vbase | method<<20
'	ptra[4+] = any parameters
'
' on exit:
'
'	ptra[-4] = pbase | trap flag
'	ptra[-3] = vbase
'	ptra[-2] = dbase	@params...
'	ptra[-1] = return (w)	@COGSTOP(COGID)
'	ptra[ 0] = params...
'
launch_spin	setq	#2-1			'get pbase/vbase
		rdlong	pbase,ptra

		or	pbase,#%10		'set pbase 'trap' flag

		mov	dbase,ptra		'set dbase to @params
		add	dbase,#4*4

		mov	w,#@stopcog		'set return to COGSTOP(COGID) bytecodes

		setq	#4-1			'write pbase/vbase/dbase/w into stack
		wrlong	pbase,ptra++

		andn	pbase,#%11		'restore pbase address

		mov	dcall,dbase		'set dcall

		setq	#buff-cog_code-1	'load cog code
		rdlong	cog_code,#@cog_code

		setq2	#$200-1			'load lut code
		rdlong	$000,##@lut_code

		push	#wrf_rd			'return to wrf_rd to start xbyte after callinit

		skip	##%111100000000_000_0	'begin bytecode execution of method in vbase[31:20]
		jmp	#callinit

Capt. Quirk · 2020-01-12 06:37

In addition to the pictures, there is bug that causes
the Propeller tool to crash while closing the program.

Bill M.

cgracey · 2020-01-12 07:10

Capt. Quirk, those are great ideas, I agree. We can do all those things. Thanks for getting these pictures together. We will use them.

Wuerfel_21 · 2020-01-12 11:58

Oh while we're at it, there's some problems with the color scheme edit box:
- Can't change the "regular" background color despite there being a grayed-out box for it (is fixed as white)
- Text colors can not be relative to the block's default foreground (only exactly the same as block foreground OR relative to block background OR the same in every block type)
- Can't change colors of the line numbers and anything else outside the edit box (that may be difficult to accomplish, given most of the things outside seem like they are just regular ol' Windows built-in stuff)

These shortcomings work together to make it impossible to set a good light-on-dark scheme.

And yes, PLEASE make the find/replace box not modal.

Also, some bug reports:
- Sometimes, when you change resolutions while PropTool is running (or rather, when some program enters a low-res fullscreen mode?), the "Object Info" window gets super corrupted until you restart proptool. Haven't been able to reproduce it now.
- When you ...
1. Open a .binary/.eeprom file
2. click on the only entry in the object list inside the "Object Info" window (editor turns blank at this point)
3. Try to open another .binary/.eeprom file by double-clicking it in Explorer whithout closing the "Object Info" window first
... you won't be to open any files by double-clicking until you restart proptool. Super annoying when you're using an external compiler but need proptool to load the binaries (since it is the only loader I can semi-reliably use without DTR auto-reset on P1)

Seairth · 2020-01-12 14:52

Would it be possible to get the language definition in a formal language like BNF?

(note: I'm slowly working on a new set of compiler tools written in Typescript/JavaScript. To cut my teeth on the various libraries I'm using, I'm starting with support for P1. The lack of a BNF-like definition has made it a little challenging, though. For instance, a symbol is defined as /[_a-zA-Z]\w*/ using regex syntax, but that fails for local symbols in DAT sections. In that case, you need a separate production that includes the colon, which is not immediately clear from the propeller manual. A BNF-like definition would make this kind of thing very clear.)

cgracey · 2020-01-12 17:41

> @Seairth said:
> Would it be possible to get the language definition in a formal language like BNF?
>
> (note: I'm slowly working on a new set of compiler tools written in Typescript/JavaScript. To cut my teeth on the various libraries I'm using, I'm starting with support for P1. The lack of a BNF-like definition has made it a little challenging, though. For instance, a symbol is defined as /[_a-zA-Z]\w*/ using regex syntax, but that fails for local symbols in DAT sections. In that case, you need a separate production that includes the colon, which is not immediately clear from the propeller manual. A BNF-like definition would make this kind of thing very clear.)

Looks interesting. I just read up on BNF. I don't have time to do it, right now, but it shouldn't be too hard if someone wanted to do it.

Seairth · 2020-01-12 22:12

cgracey wrote: »

> @Seairth said:
> Would it be possible to get the language definition in a formal language like BNF?
>
> (note: I'm slowly working on a new set of compiler tools written in Typescript/JavaScript. To cut my teeth on the various libraries I'm using, I'm starting with support for P1. The lack of a BNF-like definition has made it a little challenging, though. For instance, a symbol is defined as /[_a-zA-Z]\w*/ using regex syntax, but that fails for local symbols in DAT sections. In that case, you need a separate production that includes the colon, which is not immediately clear from the propeller manual. A BNF-like definition would make this kind of thing very clear.)

Looks interesting. I just read up on BNF. I don't have time to do it, right now, but it shouldn't be too hard if someone wanted to do it.

I'd be happy to help out. And I completely understand why you don't want to do it right now.

These things can get quite involved for a non-trivial grammar. On the other hand, that's when these can be the most helpful.

Wuerfel_21 · 2020-01-17 20:56

Wuerfel_21 wrote: »

Also, some bug reports:
- Sometimes, when you change resolutions while PropTool is running (or rather, when some program enters a low-res fullscreen mode?), the "Object Info" window gets super corrupted until you restart proptool. Haven't been able to reproduce it now.

Ah, it happened again... not sure what I did to cause it.

Roy Eltham · 2020-01-17 21:30

BTW, Capt Quirk's "Exclude" option in the search is basically the same as "whole word". It should mean it will only match cases where your search term is the whole token.
So like searching for "foo" will match foo, but not food or foobar. It may be that proptool is not properly handling the = vs == case when Whole words is checked, so maybe just fix that?
Usually the whole word matching should only allow whitespace and certain key symbols to be touching the word, such as quote or comma or underbar. So == should be considered a "whole word" and thus not match a search for "=".

It's much easier than having to list all possible things to exclude.

Is there any upgrades for the P2 Propeller Tool editor?

Comments