• AVR Freaks

Helpful ReplyHot!Is MPASM intentionally killed?

Page: < 12 Showing page 2 of 2
Author
Mark Yampolsky
Super Member
  • Total Posts : 122
  • Reward points : 0
  • Joined: 2009/04/03 18:50:36
  • Location: Russia Fryazino Moskow reg
  • Status: offline
Re: Is MPASM intentionally killed? 2020/04/19 02:08:04 (permalink)
5 (1)
I do not pay attention to the merits of the interlocutor. I am only interested in the substance of the issue under discussion.
Therefore, when the interlocutor makes strange statements for me, I ask him “uncomfortable” questions.
In this case, I don’t understand what the warnings about the syntax of the register config have to do with Assembler XC16 problems.
By the way.
What does the issue with a non-working #pragma config have to do with new or old controllers? The #pragma config does not work with the assembler XC16 for ALL controllers and ALL config registers the same (for .S files).
post edited by Mark Yampolsky - 2020/04/19 02:31:45
#21
Mark Yampolsky
Super Member
  • Total Posts : 122
  • Reward points : 0
  • Joined: 2009/04/03 18:50:36
  • Location: Russia Fryazino Moskow reg
  • Status: offline
Re: Is MPASM intentionally killed? 2020/04/19 03:23:14 (permalink)
0
dan1138
As far as a library of example code I have posted some on github here: https://github.com/dsoze1138

Den! I am not greedy. Take the FFT butterfly code for your collection:
; W10=pA
; W11=pB
; W8=pW
; A=A+B
; B=(A-B)W
BtflCmplx:
mov #0x7FFF, W4 ; W4=0.99999
clr A, [W10]+=2, W6 ; W6=Ar, [W10]->Ai
clr B, [W8]+=2, W5, [W11]+=2, W7 ; W7=Br, [W11]->Bi, W5=Wr [W8]->Wi
;--- perform A
mac W4*W6, A, [W10]-=2, W6 ; ACCA=+(1*Ar), W6=Ai, [W10]->Ar
mac W4*W7, A, [W11]-=2, W7 ; ACCA=+(1*Br), W7=Bi, [W11]->Br
sac.r A, #-1, [W13++] ; Ar(new)=ACCA.rnd->buf
mac W4*W6, B, [W10]+=2, W6 ; ACCB=+(1*Ai), W6=Ar, [W10]->Ai
mac W4*W7, B, [W11]+=2, W7 ; ACCB=+(1*Bi), W7=Br, [W11]->Bi
sac.r B, #-1, [W13++] ; Ai(new)=ACCB.rnd->buf
;--- perform B
mpy W5*W6, A, [W10]-=2, W6 ; ACCA=Wr*Ar, W6=Ai, [W10]->Ar
msc W5*W7, A, [W8]-=2, W5, [W11]-=2, W7 ; ACCA=-(Wr*Br), W5=Wi, [W8]->Wr, W7=Bi, [W11]->Br
msc W5*W6, A ; ACCA=-(Wi*Ai)
mac W5*W7, A, [W8]+=2, W5 ; ACCA=+(Wi*Bi), W5=Wr, [W8]->Wi
sac.r A, #-1, [W13++] ; Br(new)=ACCA.rnd->buf
mpy W5*W6, B, [W10]+=2, W6 ; ACCB=Wr*Ai, W6=Ar, [W10]->Ai
msc W5*W7, B, [W8], W5, [W11]+=2, W7 ; ACCB=-(Wr*Bi), W5=Wi, W7=Br, [W11]->Bi
mac W5*W6, B ; ACCB=+(Wi*Ar)
msc W5*W7, B ; ACCB=-(Wi*Br)
sac.r B, #-1, [W13] ; Bi(new)=ACCB.rnd->buf
mov [W13--], [W11--] ; save Bi
mov [W13--], [W11] ; save Br
mov [W13--], [W10--] ; save Ai
mov [W13], [W10] ; save Ar
return
 
#22
Jerry Messina
Super Member
  • Total Posts : 539
  • Reward points : 0
  • Joined: 2003/11/07 12:35:12
  • Status: offline
Re: Is MPASM intentionally killed? 2020/04/19 04:17:22 (permalink)
5 (4)
Ok, so now that we've gone from discussing MPASM for 8-bit parts to config issues with dual-core 16-bit parts and MPLABX/XC16 and who has better/more code examples...
 

Is MPASM intentionally killed?

#23
dan1138
Super Member
  • Total Posts : 3729
  • Reward points : 0
  • Joined: 2007/02/21 23:04:16
  • Location: 0
  • Status: offline
Re: Is MPASM intentionally killed? 2020/04/19 09:56:08 (permalink)
5 (3)
Jerry Messina
Ok, so now that we've gone from discussing MPASM for 8-bit parts to config issues with dual-core 16-bit parts and MPLABX/XC16 and who has better/more code examples...

Is MPASM intentionally killed?


First let me say that I apologize for my part in the recent digression in this topic.

To sum up my point, if I have one, Microchip appears to intentionally support firmware development for their controllers using high level languages like C and C++. Project development in pure assembly language does not seem to be important to Microchip.

Microchip has history of keeping controllers in production as long as they can sell them for a profit.

Should they do the same for MPASM or just stop adding support for new controllers?

So far Microchip has not made any statements beyond that the assembler tool will not be ported to run on 64-bit operating systems.

The worst case would be that MPASM gets frozen in time like MPLAB version 8.

I doubt that Microchip cares that much about developers using only assembly language with their controllers. They do care about attracting new developers to their controllers. For that goal easy to use code generators are now a requirement.

Before the MCC and Harmony code generators Microchip created and maintained source code and object libraries for their controllers. As controller architectures evolved these libraries must have become a maintenance nightmare. So now we get code generators and frameworks.

I doubt that Microchip will make its intentions known with regard to MPASM any time soon.

So the original question: "Is MPASM intentionally killed?" seems unanswerable.
#24
Jerry Messina
Super Member
  • Total Posts : 539
  • Reward points : 0
  • Joined: 2003/11/07 12:35:12
  • Status: offline
Re: Is MPASM intentionally killed? 2020/04/19 13:20:58 (permalink)
5 (1)
Thanks, Dan. That wasn't necessarily aimed at you... I always appreciate your well-thought out posts and examples.
 
It's more frustration with Microchip. As of late they seem to be dropping support/changing more and more things.
It wouldn't be so bad if the alternatives were compatible w/existing stuff but in many cases that's not true without a lot of work.
 
I use a number of third-party tools that use MPASM to generate code and porting these over to use a different assembler likely isn't going to happen.
 
As controller architectures evolved these libraries must have become a maintenance nightmare. So now we get code generators and frameworks.

And from the number of posts about those we see how well that's all working out.
 
Gotta love progress I suppose. I just wish it was forward.
 
#25
ric
Super Member
  • Total Posts : 28004
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: online
Re: Is MPASM intentionally killed? 2020/04/19 13:23:32 (permalink)
5 (1)
dan1138
I doubt that Microchip cares that much about developers using only assembly language with their controllers. They do care about attracting new developers to their controllers. For that goal easy to use code generators are now a requirement.

Pity they don't have them yet. ;)
 

I also post at: PicForum
Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
NEW USERS: Posting images, links and code - workaround for restrictions.
To get a useful answer, always state which PIC you are using!
#26
jtemples
عُضْوٌ جَدِيد
  • Total Posts : 11933
  • Reward points : 0
  • Joined: 2004/02/13 12:31:19
  • Location: Southern California
  • Status: offline
Re: Is MPASM intentionally killed? 2020/04/19 13:50:57 (permalink)
0
I use a number of third-party tools that use MPASM to generate code

 
What sort of tools?
#27
Jerry Messina
Super Member
  • Total Posts : 539
  • Reward points : 0
  • Joined: 2003/11/07 12:35:12
  • Status: offline
Re: Is MPASM intentionally killed? 2020/04/19 15:32:57 (permalink)
5 (1)
What sort of tools?

melabs PicBasicPro, Proton PDS, and Swordfish to name a few.
 
I also have custom tools to generate config and header info that use the MPASM files. There are other ways to get this data but using the MPASM database files was convenient.
#28
ematicon
Junior Member
  • Total Posts : 55
  • Reward points : 0
  • Status: offline
Re: Is MPASM intentionally killed? 2020/04/20 15:32:28 (permalink)
5 (1)
dan1138
So now we get code generators and frameworks.

That's another story of frustration.
Situation. You started a new project using framework and generator. Complete. Production. After couple of years you need to modify/bugfix/add_feature. Then hopefully this does not require generator. Because for other recent projects you decided to use newer version of framework so and generator. Newer generator requires newer IDE. So you need to keep installed several versions of IDE with corresponding set of generators or edit manually generated sources, that were not likely intended for. Last time I tried to change clock frequency I needed to change two files (after some searching of course): one with #define SYS_CLK_FREQ and other with unconnected to that variable #pragma config. Maybe it is much to ask but I see a difference investigating sources that were wrote by competent programmer for himself ;)
 
From my point of view a generator if exists must generate sources that could be successfully independent from that generator. And life of sources is not only to take up space in archive, but also to be maintained over years. Do the microchip developers understand this, or they just young?
 
MPASM is not perfect and never was. But it works. While for newer project I could try ASPIC (at least concatenation in macros is easier there) the ease of my work depends also on tools long supported by Microchip.
#29
Page: < 12 Showing page 2 of 2
Jump to:
© 2020 APG vNext Commercial Version 4.5