Varning isf fel vid ogiltig instruktion i MPASM

[bos]

Nu skrev jag ihop ett enkelt exempel som visar problemet.

Jag förstår vad det är med detta som orsakar såna problem för dig. Som jag skrev i mitt andra inlägg - det här är inga konstigheter alls. Fullt normalt, rationellt och förväntat beteende av MPLAB.

Vad är det du vill MPLAB ska göra istället för det som sker nu?

[mri]

Vad är det här för crap assembler som inte kräver att man har ett kolon ":" efter en label???

[vfr]

bos> Nej, det är absolut inte förväntat resultat. Som det är nu så ger den inte fel, utan bara varning på en fullständigt ogiltig instruktion. Är den ogiltig, så är det ett fel. Vad skall den annars göra med "ddddd" då? Fel ska man få när det inte går att lösa uppgiften. Eftersom den inte kan veta vad jag har avsett med det, så är uppgiften olösbar.

Eller menar du att det faktiskt skulle vara fullt tillåtet med lablar en bit in på raden? Hur sjutton skall man (assemblern) då skilja på en label och en instruktion? Det är ju fullt tillåtet att skriva en rad med bara label såväl som en rad med bara en instruktion.

Sedan kan jag hålla med om att den kan blanda ihop det med lablar på något sätt, av meddelandet att döma. Men inte göra det på ett riktigt sätt, d.v.s ett fel i assemblern.

[vfr]

Vad är det här för crap assembler som inte kräver att man har ett kolon ":" efter en label???

Det är många assemblers som inte gör det. Motorola (Freescale) går t.o.m steget längre och tar bort ";" framför kommentarer.

[bos]

bos> Nej, det är absolut inte förväntat resultat. Som det är nu så ger den inte fel, utan bara varning på en fullständigt ogiltig instruktion. Är den ogiltig, så är det ett fel.

Det där är dina egna åsikter som inte har så mycket att göra med vad som faktiskt gäller.

Eller menar du att det faktiskt skulle vara fullt tillåtet med lablar en bit in på raden?

Ja, vilket jag redan skrivit...

Ta en titt i manualen för MPASM:

Labels should (= bör, INTE "måste") start in column 1. They may (= kan) be followed by a colon (:), space, tab or the end of line. Labels must (= måste) begin with an alpha character or an under bar (_) and may contain alphanumeric characters, the under bar and the question mark.

Labels must not:

* begin with two leading underscores, e.g., __config.
* begin with a leading underscore and number, e.g., _2NDLOOP.
* be an assembler reserved word (see Reserved Words and Section Names).

Med andra ord, och som jag återigen redan skrivit tidigare: " dddddd" är inte ett reserverat ord, börjar inte med __ och börjar inte heller med _(siffra), alltså tolkas det som en label trots att det inte är i kolumn 1 (vilket i sig inte är ett förbud enligt första meningen).

Lägger du till ett mellanslag och ytterligare rappakalja (ej reserverade ord eller makron, eller annat) så kommer kompilatorn att klaga eftersom labeln redan är satt. De båda orden kommer inte att tolkas som en label eftersom en label får innehålla alfanumeriska tecken, "_" samt "?" (sista meningen i det citerade stycket).

Hur sjutton skall man (assemblern) då skilja på en label och en instruktion?

Med hjälp av reserverade ord och preprocessning av kod. Det är inget man själv behöver bekymra sig om, så jag förstår fortfarande inte vad det är som vållar såna problem med det här.

[mri]

Med hjälp av reserverade ord och preprocessning av kod. Det är inget man själv behöver bekymra sig om, så jag förstår fortfarande inte vad det är som vållar såna problem med det här.

Kanske för att du aldrig nånsig skriver en mnemonic fel när du programmerar assembler?

Om man råkar skriva fel på en instruktion i MPASM så att det blir en ogiltig instruktion, så får man bara en varning (found label after column 1) och inte ett fel. Det betyder att ett automatiskt byggverktyg som "make" t.ex inte detekterar att det blev fel.

Menar du att de automatiska verktygen inte alls visar varningarna åt dig på nåt sätt?
Inte skall man ju acceptera att koden komilerar men med varningar.... varje varning bör kollas upp och fixas, på samma sätt som direkta kompilerinsfel!

[vfr]

Jag har uppenbarligen uttalat mig alldeles för tvärsäkert i det här ärendet. Jag hade nog fattat det stycket om lablar lite som jag själv trodde att det var. Jag har, ärligt talat, aldrig stött på någon assembler tidigare som tillåter lablar annat än i kolumn 1. Och egentligen tycker jag det verkar dumt om det kan leda till att assemblern inte detekterar sådant här som verkliga fel. Vad är egentligen nyttan med det? Jag har aldrig sett assemblerprogram skrivna på ett sätt som kräver lablar innanför kolumn 1.

Skit samma. Nu är det ju uppenbarligen så. Ursäkta, bos. Jag fattade inte riktigt att du syftade på att det faktiskt är tillåtet att göra så.

Problemet med det, är att man inte får fel i t.ex en make. Visst får man varningar bland den text som kommer ut, men det kräver att man verkligen ser dom varningarna eftersom den inte stannar. Att använda kolon hjälper ju bara om assemblern kräver kolon. Men är det tillåtet att skriva utan, så hjälper det inte. Dessutom är jag nog tyvärr lite insnöad på att skriva assembler utan kolon, då alla projekt jag jobbat på har varit så. Att då skriva om allting kan bli rätt mycket jobb. Och man vill gärna använda samma programmeringsstil rakt över, oavsett vilket projekt man jobbar med. Annars blir det jobbigt med både vanan och att återanvända kod.

Tack för att ni skickade mig på rätt spår.

Edit: Stavfel

[vfr]

Inte skall man ju acceptera att koden komilerar men med varningar.... varje varning bör kollas upp och fixas, på samma sätt som direkta kompilerinsfel!

Egentligen håller jag med helt och hållet. När jag programmerar C så strävar jag alltid efter varningsfria kompileringar. Problemet är att man vant sig vid varningar här på saker som egentligen inte är någon större sak, t.ex åtkomst av register i annan bank. Där vet inte inte assemblern om vilken bank jag har satt och varnar "bara för att vara säker".

Rent felmässigt så kan jag tycka att det är en viss skillnad på att skriva en fullständigt ogiltig instruktion/direktiv eller att kanske vara i fel bank. Det första borde detekteras. Det är ju lite tråkigt att man definierat lablar på ett sätt så att instruktioner kan missförstås för lablar. Speciellt om det går emot vad andra assemblers använder.

[bos]

> Det är ju lite tråkigt att man definierat lablar på ett sätt så att instruktioner kan missförstås för lablar.

Hur menar du nu?

[vfr]

Att den faktiskt godkänner lablar annat än i position 1. Speciellt om det inte är det vanliga sättet. Fast jag kan ju ha fel där också, och att det faktiskt är vanligare än jag vad tror. Jag har aldrig stött på det.

Å andra sidan kan man ju säga att om jag tolkat andra assemblers manual lika bra som det här, så skulle jag kanske inte sett det där heller. Fast nej, troligen inte. Då skulle jag nog uppmärksammat det någon gång iallafall när man skriver fel.

Hmm. Konstigt att jag inte haft detta problemet tidigare med MPASM. Man skiver ju inte direkt felfri kod... Å andra sidan så har man väl då uppfattat dom varningar som fladdrat förbi och åtgärdat det utan att tänka så mycket på varför det inte blev ett fel av det.