On 21 Aug 2011, at 13:47, John Clymer wrote:
> Actually, I removed the hard coded stack_top, and put in a line to place
> stack_top at the very top of RAM - dependent up on the settings in the
> controller structure.
>
> + Add('_stack_top = 0x' + IntToHex(sramsize+srambase-4,8) + ';');
>
> This sets stack_top to the very top of the SRAM space minus 4 bytes. So long
> as the srambase and sramsize are correct, the stack pointer will get set to
> the top of SRAM.
>
> Not sure how you are making your conclusion. Any line with
> "stack_top=0x20fffc" is being deleted with this patch.
ok, it should have been 0x2000fffc to start with if it is for a 64k device.
Somebody also posted that stack_top could be ram_size+ram_base, I suppose
because the sp is decremented before writing. But I am no expert on this. I
have had obscure warnings from Keil MDK when linking (from C, yes it works) to
units compiled with FPC, and I have wondered whether it is stack alignment, but
not got much further with it.
>
> However, if I might ask - which controller are you using this on ?
LM3S9B92 is what I used to test the existing stellaris startup on. I am now
using LM3S9B95 and LM3S5D51, the latter being 512k flash/96k ram. These are
'tempest' class devices I think; I would suggest not bothering about the
earlier classes of device. And that is another reason I don't think detailed
device info should go in the compiler. As there is no OS I think the minimal
RTL and info essential to the compiler/as/ld ie. flash, ram size, should be
there as compiler user options, but nothing device specific.
Geoffrey
>
> Thanks,
>
> John
>
> From: Geoffrey Barton <[email protected]>
> To: FPC developers' list <[email protected]>
> Sent: Sun, August 21, 2011 2:46:55 PM
> Subject: Re: [fpc-devel] ARM patch to switch to controller records rather
> than arrays
>
>
> On 21 Aug 2011, at 00:35, John Clymer wrote:
>
>> DIFF attached for comment and review. Provides the following features /
>> difference:
>>
>> 1) Switched operation of cpuinfo.pas - there is still a SET containing the
>> ct_ constants, but that now indexes an array of structures rather than a
>> collection of arrays. The array contains the info from the old arrays, PLUS
>> FLASH, SRAM and EPROM memory definitions i.e. BASE and SIZE for each.
>> NOTE: Switched for both ARM and AVR. AVR changes will compile the cross
>> compiler, but choke while building the RTL (complaining about a function
>> being too complex). However, the SVN and daily build exhibit the same
>> behaviour - so I do not believe I have broken the AVR any further than it
>> was broken.
>>
>> 2) Added LM3FURY controller unit file - this will be built up into a base
>> unit file for all the Fury class Stellaris controllers.
>>
>> 3) I intend to leave the "Stellaris" controller class with the intention
>> that those that don't want a full set of system defines can use this class
>> and will receive nothing more than the bare minimum to boot a chip into
>> PASCALMAIN. The Flash and SRAM sizes will be set very large - so caveat
>> emptor to the user if, as they will need to ensure the programs do not
>> require more resources than their chip require.
>
> It actually renders it unusable if the ram size is bigger than that in the
> device you are using as the stack top will be set outside the available ram.
> It has only ever worked before with the correct ram/flash sizes as I pointed
> out to you. It should be for specific known combinations, the ct_stellaris
> was incorrect before you diff'ed it, and now you have introduced another
> error (stack_top=0x20fffc?).
>
> Personally, as somebody using this compiler on real projects, I think there
> are too many changes proposed here in one hit, completely untested.
>
> festina lente
>
> _______________________________________________
> fpc-devel maillist - [email protected]
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
