gnupic: gpasm-0.18.1


Previous by date: 6 Mar 2000 22:25:10 -0000 Re: Optimiziing Forth compiler for mid-range PICs, Wojciech Zabolotny
Next by date: 6 Mar 2000 22:25:10 -0000 Re: Optimiziing Forth compiler for mid-range PICs, Francisco Rodrigo Escobedo Robles
Previous in thread: 6 Mar 2000 22:25:10 -0000 Re: gpasm-0.18.1, Ralf Forsberg
Next in thread:

Subject: Re: gpasm-0.18.1
From: "Robert Stanton" ####@####.####
Date: 6 Mar 2000 22:25:10 -0000
Message-Id:

On Tue, 29 Feb 2000, you wrote:
>On Tue, 29 Feb 2000, Ralf Forsberg wrote:
>
>> 
>> On Mon, 28 Feb 2000, you wrote:
>> >On Mon, 28 Feb 2000, Ralf Forsberg wrote:
>> >
>> >> >> Does anyone have any suggestions on how 1) to present the contents of
>> >> >> program memory 2) to convey changes in the program memory?
>> >> >> 
>> >> >
>> >> >Show adjusted program memory values in a new colour, and perhaps have an
>> >> >option available to auto-scroll the window to show the memory block
>> >> >containing the recently adjusted memory location. obivously you can't
>> >> >display all at once ,but can we select multiple and not neccessarily
>> >> >adjacent blocks of memory to display.. that would be useful, for
>> >> >instance, when picc locates some code around the reset vector and some
>> >> >near 7FFh and some more at the end of the memory bank (1FFFh for the
>> >> >16F877)....
>> >> 
>> >> How would you want to define memory areas to display?
>> >
>> >The .cod file has this information encoded in it. But you'd still have
>> >this problem if the memory you wish to view is modified by your program
>> >but not specified in your assembly file (e.g. suppose you want to use the
>> >whole upper half of the program memory to store data acquired from some
>> >measurement. You wouldn't necessarily define this area in your code.)
>> 
>> I don't think we can add all of memory (in the case of a large
>> program), that would make the sheet really slow. We need a way to
>> select memory.
>
>Have you heard anything from Adrian recently about gtksheet's efficiency
>problems?

I mailed him the other day and nobody else had complained about it
:-). The problem is that we set different attributes for every cell.
I have experimented with using a hash table for the attributes in
gtksheet.

Timing for starting the p18c252 using a P233:
18 seconds using gtk+extra-0.99.0 (I have a slow graphics card)
9 seconds using gtk+extra-0.99.1 ((non-released) has redraw fix plus
some other stuff) 
1 second using gtk+extra-0.99.1 + hash patch

I wonder how it scales up to the 2000 rows in the imagined program
memory viewer, but at least this improvement makes it _thinkable_ to
add all memory in one sheet.

 / Ralf

---------------------------------------------------------------------
To unsubscribe, e-mail: ####@####.####
For additional commands, e-mail: ####@####.####

Robert Stanton
Plessey Asia Pacific Pty Ltd
mailto: ####@####.####

Previous by date: 6 Mar 2000 22:25:10 -0000 Re: Optimiziing Forth compiler for mid-range PICs, Wojciech Zabolotny
Next by date: 6 Mar 2000 22:25:10 -0000 Re: Optimiziing Forth compiler for mid-range PICs, Francisco Rodrigo Escobedo Robles
Previous in thread: 6 Mar 2000 22:25:10 -0000 Re: gpasm-0.18.1, Ralf Forsberg
Next in thread:


Powered by ezmlm-browse 0.20.