From: robert@nospicedham.prino.org   
      
   On 2017-11-30 08:40, rugxulo@nospicedham.gmail.com wrote:   
   > Hi,   
   >   
   > On Wednesday, November 29, 2017 at 1:00:54 PM UTC-6, Robert Prins wrote:   
   >>   
   >> I realized that while pulling in the actual in-line code this afternoon, and   
   >> while doing so I also found out that some of my UTF-8 to "\Un" conversions   
   break   
   >> the 255-byte limit on the ancient Pascal strings, so I will have to go back   
   to   
   >> the drawing board, not just to figure out how to detect bytes with the two   
   top   
   >> bits set (I guess a variation on Alan Mycrofts "#has_nullbyte") and where   
   they   
   >> are set, and how to check YMM registers for zero, but also how to handle   
   strings   
   >>   > 255 bytes, although that should be pretty straight-forward, given that   
   I'm   
   >> already bypassing Write(Ln) and moving most of my output data directly into   
   >> extended buffer added to the output file.   
   >   
   > I don't have Virtual Pascal installed on this laptop, but a quick online   
   > search of VP21LANG.PDF mentions this:   
   >   
   > "   
   > Virtual Pascal supports two types of strings: short strings and long   
   > strings.   
   > ....   
   > The long string type is a structured type that contains a sequence of   
   > characters, whose length is only limited by available memory. It is   
   > allocated dynamically during program execution. The long string type   
   > is not available in Borland  Pascal or in 16-bit Borland Delphi v1.x   
   > but is supported by 32-bit versions of Borland Delphi and by Virtual   
   > Pascal. The state of the {$H-} compiler directive determines whether   
   > the reserved word string denotes a short string or a long string. In   
   > Virtual Pascal, the default state of the directive is {$H-}.   
      
   I know, but my assembler-ized code mostly bypasses Write(Ln), and moves output   
   data directly into a "huge" "SetTextBuf()" buffer replacing VP's default   
   128-byte file buffer. It relies on short strings, and adding a (quite likely)   
   near duplicate procedure to do the same for AnsiString is not on my To-Do list.   
      
   > Irrespective of the state of these compiler directives, the predefined   
   > identifiers ShortString and AnsiString (defined in the System unit)   
   > can be used to explicitly select the desired string type.   
   > ....   
   > Long strings do not have their length stored as a single byte at   
   > offset 0 (as do  short strings); to get the length of a long string,   
   > the Length function should be used. To set the length of a long string   
   > string explicitly, the SetLength standard procedure should be used.   
   > ....   
   > [and it further mentions more low-level details, if you're curious]   
      
   I've read the manual. ;)   
      
   > N.B. Free Pascal just released 3.0.4, and yes, they too support the   
   > longer ANSI strings, among others.   
      
   But it lacks TP/VP compatibility in at least one, for me essential, area,   
   grouped "Const"s, and, looking at the code generated by 3.0.2 (the last one I   
   tried and subsequently zapped again), it's, as I have mentioned before, not   
   much   
   better than what TP/BP/VP (used to) generate. And, although never tried, I fear   
   that directly calling RTL routines, which is dead easy in VP, would be a hell   
   of   
   a lot harder. The one plus of using it would (probably) be the ability to   
   directly use YMM instructions, rather than, as I have to do now, having to code   
   them as db/dd sequences.   
      
   Anyway, looking at the 3.0.4 change log tells me that I should not bother to   
   install FPC again...   
      
   The fact is, I would really like to convert all my programs to pure assembler,   
   and, at least for the main program, most of the Pascal I started writing way   
   back in the mid 1908'ies has been replaced by in-line assembler, which in some   
   cases no longer bears any resemblance to the TP/BP/VP generated code, and which   
   is, needlessly to say not just significantly faster than the original code, but   
   also around 36% smaller, I grew up with a TI-59, and that had only 960 bytes of   
   RAM, so getting programs to fit into that limited space (default 480 bytes of   
   code, 60 8-byte registers holding 13-digit (+/- 1E-99 to +/-9.999999999999E99,   
   and 0 decimal numbers) was a challenge.   
      
   Robert   
   --   
   Robert AH Prins   
   robert(a)prino(d)org   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)