THE WELCH COMPANY
440 Davis Court #1602
San Francisco, CA 94111-2496
415 781 5700


S U M M A R Y


DIARY: April 7, 1994 06:30 PM Thursday; Rod Welch

Visited Morris re fixing compiler and memory management.

1...Summary/Objective
2...Morris' Analysis of Compiler Issues
3...Morris Adopted Following approach


..............
Click here to comment!

CONTACTS 
0201 - Chips & Tech.                      408 434 0600
020101 - Mr. Morris E. Jones
020102 - Vice President =Ext. 4283
020103 - Advanced Products =fax 434 0765

SUBJECTS
Medit; Compiler

0403 -    ..
0404 - Summary/Objective
0405 -
040501 - Follow up ref SDS 12 0000, ref SDS 11 0000.
040502 -
040503 - Took CPU #3 so Morris did the work directly on my machine.
040504 -
040505 - On 921024 Morris worked on the compiler, ref SDS 1 4R7F, and at that
040506 - time indicated it was at 60% of its capacity. ref SDS 1 4R7F
040507 -
040508 -
040509 -  ..
040510 - Morris' Analysis of Compiler Issues
040511 -
040512 - Follow up ref SDS 1 NSRY.
040513 -
040514 - The compiler has overflowed the code segment allocated.  It needs to
040515 - be redone in the large memory model from the compact memory model,
040516 - following up work on 921024 when Morris worked on the compiler code.
040517 - ref SDS 1 4R7F
040518 -
040519 - Morris indicated that the compiler can be improved by rewriting jump
040520 - and call code, as well as the macro invocation code.  The macro table
040521 - will double in size.  This will expand the size of the program about
040522 - 1k for the table.  Going to the large model should add about 15% to
040523 - the size of the compiled macros.
040524 -
040525 -    [On 940409 Morris developed another idea that does not require a
040526 -    major effort to re-write the compiler. per ref SDS 16 0001
040527 -
040528 -
040529 -
040530 -
040531 -
0406 -

SUBJECTS
SDS, Medit Improvements,
Memory management (avoid crashing)

0505 - Summary/Objective
0506 -
050601 - Try to do this per analysis at ref SDS 12 line 38.
050602 -
050603 - Seem to have solved the problem with a much simpler and faster way to
050604 - manage memory.
050605 -
050606 -
050607 -
0507 -
0508 -
0509 - Ideas
0510 -
051001 - One idea is to create a function that does this each time we use F2,
051002 - so if RAM is only slightly out of order, the routine can recover it
051003 - quickly the way Norton can compress a disk more quickly, if there is
051004 - only a slight amount of data that has to be moved.
051005 -
051006 - ..
051007 - Morris feels the easiest way to recover RAM is to write the data
051008 - to the disk and then read it back.  I asked about the "dose" command
051009 - that seems to do this already.  He indicated that code is quite a bit
051010 - different from what he has in mind.
051011 -
051012 -     We might like to write to a RAM disk with some special code, so
051013 -     the write and read operation can be done more quickly.
051014 -
051015 -
051016 - Write to disk will not meet the 1 to 2 seconds for Rod
051017 -
051018 -           It will need to save the CC and MM and etc.
051019 -           It will need to save the .tags
051020 -
051021 -
051022 -
051023 -  ..
051024 - Morris Adopted Following approach
051025 -
051026 - Next option is to combine memory elements, and create as many big
051027 - ones as possible when a file is saved.  This would allow us to
051028 - attempt to create a big block when we need one.  If it only works on
051029 - free elements, not much is required...
051030 -
051031 - Changed the memory allocator to select the closest fit.  Initial
051032 - version loaded files too slowly, so used a hashed index table of 256
051033 - entries to speed things up.  [This was modified the next day to make
051034 - it still faster, per ref SDS 15 line 31.]
051035 -
051036 -
051037 - Most of work was done at about line 700, per below.
051038 -
051039 -
051040 -
051041 -
051042 -
051043 -  ..
0511 -
0512 -
0513 - Evaluation
0514 -
051401 - The main indicator of the improvement is the free command.  Typically
051402 - when a menu is called and then closed, the free command returns a
051403 - slightly higher value.  This indicated that the program was consuming
051404 - memory.  Under the new code, this does not seem to occur.
051405 -
051406 -
051407 -
051408 -
0515 -
0516 -
0517 - medit.asm
0518 -
051801 - Line 700 - The memory management routines use a simple push and
051802 - search for allocate.  They do not attempt to find the best fit, only
051803 - the first fit.
051804 - ..
051805 - Change the memory allocator to use a best fit algorithm, and
051806 - ensure that the best fit is found.  If the requested vrs available is
051807 - off by more than 100 bytes, then leave it alone, and get a new one?
051808 -
051809 -
051810 -
0519 -
Distribution. . . . See "CONTACTS"