Zap Block edit, tabs, not a heap block

One cause of the many many many Not a Heap Block errors Zap 1.47 rick-07 throws on my 5.27rc16 ARMx6 mini.m is attempting to block edit some text which contains tabs. Reproducable every time.

Another similar cause is a search and replace into a line which contains tabs.

So it looks like tab handling is completely fscked.

Ah, so that why I never see these problems.

I hate tabs. Files with tabs are completely fscked.

Is a tab 3? 4? 8? Line-up-with-what’s-above? I’ve seen it all. And in one sorry case, a file where the interpretation differed depending, I guess, upon when that bit of it was edited.

Anybody smarter than me (and with more time) willing to fiddle around inside Zap’s dark dusty corners to see what’s blowing up?

I hate tabs. Files with tabs are completely fscked.

Hear, hear! Tabs belong in tables in WP or DTP or in spreadsheet files (if anywhere), not plain text and certainly not code.

I’ve been eliminating tabs everywhere since I first started using Python, because mixing tabs and spaces there leads to a special type of hell. All my C and C++ is now tab free too, which includes the old 8 indent with tabs, the horrendous 4 indent with half tabs half with spaces, and the recent 4 tab stuff.

However tabs still persist in makefiles for some platforms for historical reasons.

I was using tabs temporarily when I reported this. I was creating obey files with multiple lines of “copy sourcefile destfile” and I wanted the columns of filenames to line up, so used tabs intending to convert to spaces at the end. During this I need to block edit and use search and replace, which Zap threw a wobbly at, so had to untabify immediately.

I can’t replicate this. I copied Copy<tab>SourceFile<tab>DestFile lots of times then did search and replace fine.

Can you see if this still happens
1. on Zap 1.49 (13 Jun 2020) rick-07 (Version currently on PlingStore)
2. on RPCEmu or RPi if either available
3. in text mode rather than obey mode

I am using 1.49 rick-07 from the store.

On the ARMx6 the block edit bug is reproducible, just select a few lines and try to delete the D of DestFile to trigger it, in either obey or text mode. I get not a heap blocks, or various exceptions.

Trying the same thing on the Pi 3B, I don’t get heap blocks or aborts, but block editing anything around the tab is completely weird, the two characters after cant be deleted and editing anything else on the rest of the line is as if the cursor is two characters to the left of where it is shown.

I can’t reproduce search and replace with tabs now, either replacing after the tab or spanning the tab. But I’ll let you know if it happens again.

Incidentally I’d saved a search and replace in a text file, and when I came to use it again by selecting and using ctrl+P in to the dialog, all the backslashes in the search string had become prefixed with backquotes.

I still can’t get anything weird to happen unfortunately :-(

Just to clarify, by block edit you mean literally just selecting text and pressing the backspace key?

If you are able to trigger an exception, then

Set Debbuger$AnnotatedFile $.Dump
Set Debugger$DumpOptions -file annotated

might help us figure it out.

I can confirm the block edit bug, and when it happens it’s very reproducible. It’s caused by an unaligned memory access so will only show when address exceptions are on.

Below is the debug output I collected. The sequence R14,[R10,R2 occurs just once in the Zap module so should be easy to find in the source.

This is with Zap 1.49 (rick-07) on a mini.m running RO 5.27 (09-Jun-2020).

*Where
Address &2051D5F0 is at offset &00019C5C in module 'Zap'

*ShowRegs
Register dump (stored at &20012090) is:
R0  = 00000AAD R1  = 00000AB2 R2  = 00000057 R3  = 00049C50
R4  = 00000AB2 R5  = 00001002 R6  = 0200120D R7  = 000010DE
R8  = 00000009 R9  = 0000000A R10 = 0002C2B4 R11 = 00000AB2
R12 = 204B4894 R13 = 000086E4 R14 = 00000009 R15 = 2051D5F0
Mode USR32 flags set: nzcvqjggggeAift        PSR = 00000110

*MemoryI PC-32 + 64
2051D5BC : ..0á : E1300004 : TEQ     R0,R4
2051D5C0 : .0ƒ. : 00833005 : ADDEQ   R3,R3,R5
2051D5C4 : ..0á : E1300007 : TEQ     R0,R7
2051D5C8 : .àÓ. : 17D3E000 : LDRNEB  R14,[R3,R0]
2051D5CC : ..ۉ : E2800001 : ADD     R0,R0,#1
2051D5D0 : ..>. : 113E0009 : TEQNE   R14,R9
2051D5D4 : .... : 0A000006 : BEQ     &2051D5F4
2051D5D8 : . ŵâ : E2822001 : ADD     R2,R2,#1
2051D5DC : ..>á : E13E0008 : TEQ     R14,R8
2051D5E0 : óÿÿ. : 1AFFFFF3 : BNE     &2051D5B4
2051D5E4 : ...ã : E3160A03 : TST     R6,#&3000
2051D5E8 : ŵàŒ. : 179AE082 : LDRNE   R14,[R10,R2,LSL #1]
2051D5EC : .(ŵ. : 1082282E : ADDNE   R2,R2,R14,LSR #16
2051D5F0 < ïÿÿê : EAFFFFEF : B       &2051D5B4
2051D5F4 : .. á : E1A00002 : MOV     R0,R2
2051D5F8 : ü‡½è : E8BD87FC : LDMIA   R13!,{R2-R10,PC}
2051D5FC : ...ê : EA000006 : B       &2051D61C
2051D600 : logi : 69676F6C : STMVSDB R7!,{R2,R3,R5,R6,R8-R11,R13,R14}^  ; *** ! and ^
2051D604 : cal_ : 5F6C6163 : SWIPL   &6C6163
2051D608 : colu : 756C6F63 : STRVCB  R6,[R12,#-3939]!
2051D60C : mn_o : 6F5F6E6D : SWIVS   &5F6E6D
2051D610 : ffse : 65736666 : LDRVSB  R6,[R3,#-1638]!
2051D614 : t... : 00000074 : ANDEQ   R0,R0,R4,ROR R0
2051D618 : ...ÿ : FF000018 : Undefined instruction
2051D61C : üO-é : E92D4FFC : STMDB   R13!,{R2-R11,R14}

That would make sense, the minim crashes on unaligned access, where the Pi is accessing the wrong location, hence editing two characters away from where the cursor is.

What I don’t understand is I get exceptions on the mini.m with alignment exceptions on or off, and I get funny behavior but no exceptions on the Pi 3B with alignment exceptions on or off.

It would be good to get the Pi crashing in the same way, so it can be reproduced without have to have the far less common mini.m

Thanks!

That’s at the end of logical_column_number in Mode0.

From E-Library

w_tabstops = 260 :REM 16 bit array of columns to next displayed tab stop

Could we change it to

LDRNEH   R14,[R10,R2,LSL #1]

?

The code as it stands doesn’t look correct to me, its loading from either +0 or +2 addresses then using the top 16 bits shifted down in the next instruction. i.e with rotated loads for +0 it getting bits 16-32, and for +2 getting bits 0-15. Where as if you used LDRH you would get for +0 bits 0-15 and for +2 bits 16-31. Is it some hack to avoid using a 16 bit mask by storing the column numbers in the order 1,0,3,2,5,4 ?

My brain might just be too melted to understand this anymore.

Has a fix for this been found yet?

I ask because I came across some scraps with possible solutions – that I drew up after reporting the above debug info – and I’m wondering if they might still be of interest or that they can be tossed.

Has a fix for this been found yet?

I haven’t done it myself.

and I’m wondering if they might still be of interest

Yes please :-)

so need to run ARMv7 mode with alignment exceptions off.

If you are unable to run Rick’s version on v5 or v6 can you let us know what the issue is?

Below are my brief notes. The top section describes what happens on a CPU that supports unaligned loads, followed by the original code. The middle section shows a potential solution using LDRH. This has the drawback of losing RiscPC compatibility as its memory bus doesn’t support halfword transfers.

The final section has a slightly more elaborate solution but it should work on any machine. A quick test showed that the abort is gone but the result of a block edit can be weird, and by weird I mean that the result wasn’t the same as my yardstick (i.e. StrongED ;-).

It happens when you have a file where some lines are indented with spaces and others with visible tabs. The code in logical_column_number doesn’t look right to me. The tab width is read from the wrong column as the tab is already counted as a regular character.

  r2  |  mem  |  reg  |  result
even => dcba => dcba => dc
odd  => dcba => badc => ba

        TST     R6,#3<<12
        LDRNE   R14,[R10,R2,LSL#1]
        ADDNE   R2,R2,R14,LSR#16
        B       lcn$l

---------------------------------------

        TST     R6,#3<<12
        EORNE   R14,R2,#%1
        LDRNEH  R14,[R10,R14,LSL #1]
        ADDNE   R2,R2,R14
        B       lcn$l

---------------------------------------

        TST     R6,#3<<12
        BEQ     lcn$l

        MOVS    R14,R2,LSR #1
        LDR     R14,[R10,R14,LSL #2]
        MOVCS   R14,R14,LSL #16
        ADD     R2,R2,R14,LSR #16
        B       lcn$l

Block edits in !Zap that span a single short line, in BASIC mode, fail already anyway.