Kprintf serial output and Sashimi

[Thomas Richter]

There are good reasons to use RawDoFmt(), and one of them is that it is localizable, such that the output is compatible to the conventions of the locale. Argument reordering is particularly useful when localizing applications.

As said, in most cases, this patch from locale does only good. There are some rare cases we you need to avoid it, and this is if stack is sparse or the Os is not in a stable state.

[patrik]

Originally Posted by Olaf Barthel

The patch reserves space for up to 128 parameters which might need to be reordered, plus some 200 characters for numbers with grouping characters/strings inserted. That accounts for some 850+ bytes of stack space which is bound to be filled with data even if you merely call it with an empty string as the format specification.

I generously rounded this up to a minimum of 1000 bytes of stack space you should have available to safely call RawDoFmt(). Also included in the warning is a caution that functions which indirectly invoke RawDoFmt(), such as dos.library/VPrintf, also expect to draw that much stack space.

Wasn't this fixed for 3.2.1, so that the space for the 128 reordered variables is only allocated if reordering is detected?

[Mafi]

Originally Posted by thomas

This one works:

LVORawDoFmt	EQU	-522
LVORawPutChar	EQU	-516

	move.l	4.w,a6
	move.l	a6,sysbase

	lea	string,a0
	lea	putchproc,a2
	jsr	LVORawDoFmt(a6)

	moveq.l	#0,d0
	rts

putchproc:
	move.l	sysbase(pc),a6
	jsr	LVORawPutChar(a6)
	rts

sysbase:	dc.l	0

string:	dc.b	"Hello Sashimi!",$a,0

Just wanted to say this worked perfectly, thank you so much! Now that I’ve fixed my 4000 I’m back into the coding. Kprintf wasn’t even working when I linked with debug.lib (I was hoping to avoid doing that anyway, and now I can).

Cheers,
-Matt

[Olaf Barthel]

Originally Posted by patrik

Wasn't this fixed for 3.2.1, so that the space for the 128 reordered variables is only allocated if reordering is detected?

Indeed, we researched and fixed this in AmigaOS 3.2, with further bug fixes added in AmigaOS 3.2.1

The overhead of preparing for positional arguments such as "%2$s" was significant and hard to ignore once you saw it.

As a preview of what will likely land in NDK 3.2R4, here is an excerpt from the "WARNING" section attached to the exec.library/RawDoFmt function (equivalent warnings have been added to the locale.library and dos.library Autodocs):

The "locale.library" (introduced with Workbench 2.1) will install its
own replacement sprintf()-like formatting code via SetFunction(). This
replacement has significantly higher stack size requirements than
the original exec.library version of RawDoFmt(). You are best advised
to only call RawDoFmt(), even indirectly such as through the
dos.library/VPrintf function, if there are more than 1000 bytes of stack
space available. The stack size requirements apply to all locale.library
versions up to and including V46.8 (AmigaOS 3.1.4), which all default to
prepare for positional arguments such as "%2$s", regardless of whether
these are used in the format specification string. Starting with
locale.library V47.26 (AmigaOS 3.2) will prepare for positional arguments
only if the format specification string calls for it. As a general
precaution, you should always assume that preparations for positional
arguments are being made.

If you have trouble staying awake at night, even with the help of double espressos prepared and consumed in 15 minute intervals, I recommend you check out the long list of changes, bug fixes and limitations found in the locale.library/FormatString Autodocs