[Oberon] Explaining Texts.

Jörg joerg.straube at iaeth.ch
Thu Jul 26 08:53:12 CEST 2018

Peter E.

If you implemented Text as ONE contiguous block in memory, then you would have to move a lot of memory around if you insert or delete text.

To overcome this: We introduce the idea of piece; a piece is a contiguous block of text (characters) in memory. A Text is a list of pieces.

So, if you read-in an ASCII text from a file, the Text consist (in the beginning) of only ONE piece; all the ASCII characters are contiguous in memory and represented by one piece.

Now, if you eg delete char 300 to 309 of that text, this one starting piece is spilt in two: first piece points to characters 1..299 the other piece points to 310..end. So, you deleted 10 characters without moving any memory around.

BTW: the two fields "pce" and "org" are not "pointers in a translation cache", they are the cache. This cache is a minor implementation detail (optimization) of "FindPiece" and not so important to understand the idea. When you want to find the 3256th character in the Text, you basically have to go through all pieces in the list one by one and add up the piece's length until the sum is larger than 3256. Then you found the piece, where the 3256th character is in.

As it is very often the case that you move the cursor back and forth or up and down, it is handy not do the whole piece length summation again and again. So, Text has a cache of the last found position (org = 3256, and pce is the piece, where postion "org" is in). If you search for the piece where the 3260th character is in, you start from this cache instead from position 0 again.



Am 26.07.18, 07:57 schrieb "Jörg" <joerg.straube at iaeth.ch>:

    Peter E.




    You have a "strange" approach: On one hand you want to understand high level things like concepts and abstractions and on the other hand you go down to low level things like memory used.


    In my whole career I was only interested in the nbr of bytes and internal element memory alignment rules when I wrote compilers.


    In my point of view, it's not too useful to understand Texts when you know how much memory a Piece occupies. This memory thingy heavily depends on the compiler not on the language and not on the module you want to understand.


    BTW: you always can find the nbr of bytes used by a type T by using  size := SYSTEM.SIZE(T);




    Before going down to this detail, it is more important to understand this model:






    This basic mechanism of separating data from user interface is used by Texts (data model) and TextFrames (user interface).




    And you should read this documentation:




    - Figure 2.2 gives you an view on how the kernel modules are layered.


    - Chapter 5 explains Texts and its piece editor in detail.










    Am 26.07.18, 06:44 schrieb "oberon-bounces at lists.inf.ethz.ch im Auftrag von peter at easthope.ca" <oberon-bounces at lists.inf.ethz.ch im Auftrag von peter at easthope.ca>:








        For me, one the bigger difficulties in understanding the system is 


        from the multiple layers of abstraction. An intention in 




        is to encapsulate abstractions concisely together.




        Understanding the relationship of an abstraction to something concrete 


        can also help.  Hence the "Memory Occupied" column in the tables.  Is 


        that information helpful or distracting or misleading?




        Thanks,                 ... Peter E.






        Message composed and transmitted by software designed to avoid the 


        need, overhead and vulnerability of antivirus software.




        123456789 123456789 123456789 123456789 123456789 123456789 123456789


        Tel: +1 360 639 0202                                                 


        http://easthope.ca/Peter.html              Bcc: peter at easthope. ca




        Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems







More information about the Oberon mailing list