----- Original Message ----- From: Michael Park To: Sent: Wednesday, May 14, 2003 7:49 PM Subject: [PIC]: Atypical: a new PIC programming language > I've developed a programming language that I'm calling Atypical. It's > basically PIC assembly language notated to look sorta-kinda like a > high-level language. > > It's still in the experimental stage, but I invite you to visit > www.atypical.freeservers.com to get a taste (sorry about the ads; apparently > tanstaafs). > > I wrote it for myself, and I'm pretty happy with it, but I'm a PIC novice > and hobbyist. I'm curious as to what real PIC guys might think of it, so > please take a look and let me know. > > > --m > Hi Michael, Looks good so far. I also believe that there is a need for higher level assemblers. Looking at what you have already, your assembler would work well if the size of the accumulator matches the size of your index registers. However on the 14 bit PICs INDF consists of 9 bits, the IRP bit of STATUS and the 8 bits of FSR. With this in mind the code shown on your web page needs a little more thought w = &buff, -> FSR what happens when buff is at 0x120 ? You might like to consider the possibility of using w as a temporary register that is undefined on completion of an "atypical" high level instruction. You would then be able to write statements such as FSR = &buff and not worry about IRP. If you divide your language into high and low level statements you could guarantee the integrity of all registers in the low level statements and you could impose restrictions on the validity of registers in high level statements. Your high level statements would then behave like macros or subroutine calls in as much as the use of w, fsr etc are defined by the person that wrote the macros or subroutines. You would then be able to very quickly and easily allow 16 bit arithmetic. I have seen many projects written in assembler that implement mutliprecision arithmetic as pseudo 16 bit opcodes (a set of macros) that operate on pseudo 16 bit registers (predefined sets of 8 bit registers). You might end up with macros such as MOV16, ADD16 and SUB16 which might be implemented as: MOV16 .macro arg1, arg2 movf arg2+0,w movwf arg1+0 movf arg2+1,w movwf arg1+1 .endm ADD16 .macro arg1, arg2 movf arg2+0,w addwf arg1+0 btfsc STATUS,C incf arg1+1 movf arg2+1,w addwf arg1+1 .endm SUB16 .macro arg1, arg2 movf arg2+0,w subwf arg1+0 btfss STATUS,C decf arg1+1 movf arg2+1,w subwf arg1+1 .endm and you would write code like ;;; R1 = R2 + R3 - R4 MOV16 R1, R2 ADD16 R1, R3 SUB16 R1, R4 But if instead your assembler could directly work with 16 bit variables it could actually perform optimisation while it is generating the executable. This would be like having context sensitive macros that generate code depending on the context in which they are used. Regards Sergio Masci http://www.xcprod.com - Assemblers, simulators, compilers, CASE tools -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listserv@mitvma.mit.edu with SET PICList DIGEST in the body