After installing MPLABX 5.35 I've got a Configuration Loading Error:
 
"MPASM is not supported on 64 bit Operating Systems. Please consider migrating your project XXXXX configuration YYYYY to XC8 Assembler or continue to use a previously released IDE."
 
While in MPASM readme just stated that parallel build is no more functioning. That is also very sad (changing one inc file in almost hundred asm files project will take a time to build). 
 
I have some old but alive and continuing projects made in assembly with extensive usage of macros and other mpasm specifics. And recent versions of MPLABX gradually improves, support of 4K among them (and I hope finally will solve issues). So from my perspective to discard MPASM is a strange and destructive idea. 
 
If that trend will continue maybe someone already has a successive and hopefully painless experience porting asm project from MPASM to XC8 Assembler and ready to share?

Here's a recent thread:  https://www.microchip.com/forums/m1131714.aspx

<rant>
IMHO MPASM is being neglected to death.

It seems that for years Microchip has acted as if assembly language programming is no longer useful for their controllers.

This point of view is hard to argue with as the vast majority of revenue must be coming from the 16 and 32 bit PIC and Atmel controllers.

With MPLABX the Microchip tools group appears hard pressed to fix the Java craplet bugs in Netbeans that cause it to crash let alone add things to the tools that actually help developers write less buggy code.

Having used the Microchip PIC assembler from when it was first released as something that ran only on PC/MSDOS. I doubt it was much different than the General Instruments assembler it came from.

The changes made to the assembler of over the decades have been extensive but little effort has ever been focused on making it a better assembler for developing code with. To really appreciate what I mean you would need to have used the Intel assembler for the 8086 and the Microchip assembler in the same years. The Intel assembler supported declaration of data structure as complex as anything that a C compiler could do. The Microchip assembler still cannot tell the debugger the size of of the data a symbolic definition references.

There is nothing NOTHING that the Microchip assembler does that actually helps a developer avoid creating buggy code. In almost every way possible the syntax creates situations where bugs are likely, and don't get me started on "warning 302". This was a stupid diagnostic on a PIC16C54 and it only has one bank.

The one and perhaps only thing at present useful about MPASM is the legacy of know good code written with it.

The XC8 assembler (ASPIC) has a different origin. This was one of several target specific assemblers created by Hi-Tech that would accept output from their C compiler for various controllers. Remember back in the day Hi-Tech's business was selling code development tools for a vast array of controller chips.

I suspect that if Hi-Tech was still a going concern today ASPIC would be better and more useful than the GNU assembler.
</rant>

It also seems that Microchip is not very proud of that. No official announcement, no migration/porting guide. Just behaves like MPASM was long gone by then.

dan1138
IMHO MPASM is being neglected to death.

Do you think there's a demand for better assembler? I think if Microchip drop MPASM they believe that there's no demand. Or perhaps, they don't want this demand.
 
It is sad that we won't be able to use MPASM for newer parts, but if there's no market for MPASM, it's destine to die. Some as with MPLAB 8, which was much better than MPLAB X, especially for assembler programmers. But, for some reason, neophytes like these overbloated, buggy and clumsy IDEs of today. So MPLAB 8 had to die. Nothing we can do about this :(

Perhaps I just don't understand the mechanics that well, but XC8, MicroC, PBP, etc would require an ASM foundation which to build the higher level language upon.  In other words, how can MPASM go away?  How does Microchip & partner companies create the files needed to make the higher level language operate without it?

XC8 uses ASPIC. Not quite compatible with MPASM. It requite tings like explicit result destination, explicit banking etc. MPASM defaults to file destination and access bank doesn't need qualifiers.

There is some documentation available...
 
MPLAB XC8 PIC Assembler
http://ww1.microchip.com/downloads/en/DeviceDoc/MPLAB%20XC8%20PIC%20Assembler%20User's%20Guide%2050002974A.pdf
 
MPASM to MPLAB XC8 PIC Assembler Migration Guide
http://ww1.microchip.com/downloads/en/DeviceDoc/MPASM%20to%20MPLAB%20XC8%20PIC%20Assembler%20Migration%20Guide%2050002973A.pdf
 
If they really mean no more updates to MPASM, this is going to piss off a lot of people and will be a terrible blunder.

Jerry Messina
If they really mean no more updates to MPASM, this is going to piss off a lot of people and will be a terrible blunder.

If we look at what Microchip is doing for the PIC24/dsPIC33 with regard to assembly coding they want to support it only as an extension in a C language program.
 
At present in is not possible to create a project using only assembler source files for new PIC24/dsPIC33 devices. A project is required to have at least one C language source file to initialize the configuration words for controllers with partitioned program flash space like the PIC24FJ1024GB606 or dual code core dsPIC33 devices.
 
It seems Microchip has a plan to do the same for the 8-bit controllers in the PIC and Atmel lines.
 
The Atmel controllers are likely the reason Microchip wants to abandon further MPASM development.

dan1138
...
The Atmel controllers are likely the reason Microchip wants to abandon further MPASM development.

I think you've hit the nail on the head.
Someone has tossed the "maintain two totally incompatible lines of assemblers" need into the "too hard" basket.