On Fri, Jul 31, 2009 at 7:40 PM, Beckmann, Brad<[email protected]> wrote:
> Thanks Derek and Nate for the replies. Overall, it sounds like no one is
> directly working on the four issues I outlined below, so I'll put them on my
> to do list. The NetDest and DMA controller issues are most pressing, so I'll
> work on those first. Later on I'll work on the SLICC errors and protocol
> folder issues. Below is a more thorough response to your questions.
>
> - Supporting multiple protocol folders.
>
> To answer Nate's question, it is the later reason. Because SLICC generates
> different classes with the same name depending on the protocol, I don't think
> it is possible to former. Could we generate all protocol files outside of
> the build directory and then tell scons to copy only the necessary protocols
> files to the appropriate build directory? For example, have SLICC generate
> the MI_example and MESI_CMP_directory protocols in the respective
> directories: src/mem/protocol/MI_example and
> src/mem/protocol/MESI_CMP_directory. Then have scons copy the MI_example
> directory to the build directory: build/ALPHA_SE_MI_example/mem/protocol and
> copy the MESI_CMP_directory to build/ALPHA_SE_MESI_CMP_directory/mem/protocol
> without copying the other protocol's generated files. Therefore, scons can
> maintain that the m5 executables under the directories
> build/ALPHA_SE_MI_example/ and build/ALPHA_SE_MESI_CMP_directory/ depend on
> only the files listed in those directories. Does that make sense? Will that
> work with scons?
>
> - SLICC generation parsing error support in scons
>
> Of the four issues I listed, this is definitely the lowest priority, so I'm
> happy to put it on the back burner. I just wanted to point out right now the
> ParseError just provides a file name and the LexToken that describes the
> error. If you know that the third parameter of the LexToken is the line
> number, then that is all the information an experience SLICC programmer needs
> to debug. However, I'm concerned for novice SLICC programmers who may need
> more information.
I should point out that I've also run in to this problem, and it is
annoying enough that I'd really like to see it fixed sooner rather
than later. Right now I usually have to copy my changes to GEMS and
compile there to get useful error messages.
>
> - NetDest support in RubySlicc_ComponentMapping.hh
>
> The functionality I'm particularly concerned about is setting the destination
> of a message so that it broadcasts to all L1 caches or all directories.
> Before, all of those helper functions were in RubySlicc_ComponentMapping.hh.
> If we don't want those helper functions on the ruby slide any more, we could
> add them to the generated MachineType.cc file by hacking the "if
> (m_isMachineType)" statement in slicc/symbols/Type.cc. It wouldn't be the
> first hack added to that file or the ugliest hack in SLICC. :) If you have
> a suggestion for a more elegant solution, I'm happy to hear it.
I think the right wat to do this would be to a broadcast(MachineType)
method in RubySlicc_ComponenMapping.hh that looks like:
NetDest broadcast(MachineType type) {
NetDest dest
for (int i=0; i<MachineType_base_count(type); i++) {
dest.add(MachineID(type, i));
}
return dest;
}
Then in SLICC have a line that looks like:
out_msg.Destination := broadcast(MachineType::L1Cache);
The problem is that MachineType::L1Cache is not legal SLICC code.
Adding this would require a change to parser as well as the code
generator. It would be a bit of work, and the question is, is it
worth it to make this fix given that SLICCer will (eventually) happen?
I'm not sure.
Perhaps a comprimise between right and fast would be to pass something
to broadcast that SLICC does know about. For example, you could pass
a string to broadcast and then use string_to_MachineType to get the
MachineType. Obviously, this is slow and you probably don't want to
do it, but something similar could work. (use
MachineType_from_base_level?).
Other ideas?
>
> - DMA assumptions in Ruby.
>
> If you look at line 84 in my version of
> ruby/slicc_interface/RubySlicc_ComponentMapping.hh, you'll see a direct
> reference to DMA. I am confused whether we're still sticking to the strategy
> to use "#define"'s for machine types to handle these errors, or do you have
> plans to deprecate the "#define"'s? I thought part of the motivation to
> remove the NetDest functions in RubySlicc_ComponentMapping.hh was because
> they used the "#define"'s? Even if you add a DMA #define, The
> ruby/system/DMASequencer.cc relies on the DMARequestMsg type and other
> various DMA classes. Could the DMASequencer use the CacheMsg class
> instead...we could rename CacheMsg to SequencerMsg? Or we could just move
> DMARequest and the other DMA support to RubySlicc_Exports.sm?
Yes, you're right. I'll work on getting those DMA assumptions out.
I plan to deprecate the #defines in favor of something more universal.
As for DMARequestMsg, those messages are used in the network as well
as in DMASequencer. Thus, they are really a combination of a normal
RequestMsg and a CacheMsg (e.g., they have a destination field), and
so at least for now I think should be left where they are.
I do like the idea of a generic SequencerMsg class, but am a little
worried that it would ultimately be confusing. We can certianly split
DMARequestMsg into two different types, one for the request to the DMA
sequencer and one for the request to the network, like CacheMsg and
RequestMsg. In fact, this is probably the right thing to do to get rid
of the DMA assumption. The request to the DMA Sequencer wouldn't look
exactly like a CacheMsg, though, because it needs an Offset and Len
field to account for block-unaligned accesses. (The cache Sequencer
doesn't need these because it updates data locally after a request
completes and handles alignment then. The DMA controller doesn't have
that luxury because the update happens at memory, not in the DMA
itself, and so it must propagate those fields to the protocol). Thus,
a generic SequencerMsg would have to have Offset and Len fields as
well, even though they wouldn't be used by the cache Sequencer. The
cache Sequencer *could* use those fields if it let the protocol do the
data update, but that would require changing all the protocols. The
change would be very minor, though. Make sense?
>
> Brad
>
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Derek Hower
> Sent: Thursday, July 30, 2009 10:34 PM
> To: M5 Developer List
> Subject: [m5-dev] Fwd: GEM5 Issues
>
> ---------- Forwarded message ----------
> From: Derek Hower <[email protected]>
> To: M5 Developer List <[email protected]>
> Date: Thu, 30 Jul 2009 23:24:08 -0500
> Subject: Re: [m5-dev] GEM5 Issues
> On Thu, Jul 30, 2009 at 7:46 PM, Beckmann, Brad<[email protected]> wrote:
>> Hi All,
>>
>> Tushar and I have noticed a few issues with GEM5 and we were wondering
>> if anyone had plans to fix them. If not, we'll go ahead and check in
>> fixes to the global repository. I just want to make sure we're not
>> stepping on anyone's toes.
>
> Glad to get some help!!
>
>>
>> - Fix SLICC so that protocol generated files are created in separate
>> protocol specific folders. Currently they are created in the same
>> mem/protocol folder overwriting older files (eg.
>> build/ALPHA_SE/mem/protocol//ControllerFactory.cc).
>
> Go ahead with this one.
>
>> - Fully integrate SLICC parsing errors into scons. Right now the error
>> messages don't give any useful info. Should we hold off on fixing this
>> until SLICCer is added to GEM5?
>
> I wouldn't hold off. SLICCer is still indefinitely postponed, at
> least on my end. I don't expect to work on it until November-ish.
> Even after SLICCer is around, I think it would be wise to maintain
> SLICC support for a while so this would be a good fix.
>
>> - Support broadcast protocols with NetDest ruby functions. I notices
>> that one of Derek's recent checkins removed all the NetDest functions in
>> RubySlicc_ComponentMapping.hh. Most of them were lot old, protocol
>> specific, and needed to go. However there were a few general ones that
>> are needed by any broadcast based protocol. Are there plans to add
>> these back into the tree?
>
> Those weren't just removed because they are old. A lot of them were
> removed because they call a function similar to
> "mapL2toDirectoryNode," which assumes that there *is* an L2 in the
> system. We can put these functions back in (and I was planning on
> doing it as protocols are revisited), but we need to do it in a more
> generic way.
>
> For example, one of the things we are doing to get MESI_CMP_directory
> working again is removing map_L1CacheMachId_to_L2cache and replacing
> it with mapToAddressRange(low_bit, high_bit). Low bit and high bit
> are set at configuration time, and correspond to the address bits that
> select the L2 bank.
>
> If you could be more specific about which functions you're concerned
> about, we could brainstorm and come up with a new way to do the
> mapping.
>
>> - I appreciate that a lot of the controller assumptions on the ruby side
>> have been removed. However, it appears that Ruby now assumes a DMA
>> controller is present. Is there plans to clean this up.
>
>
> I don't think Ruby actually assumes that one is present (if it does
> it shouldn't). The existing configuration files certainly do, though,
> mostly because Rocks can't run without one. If you create a
> configuration that doesn't instantiate a DMA controller, I think
> you'll be OK.
>
> The reason Rocks needs a DMA controller is mostly due to the fact that
> Ruby handles data now and can't just ignore DMA accesses like it used
> to. I don't know enough about what M5 does with DMA to know if that
> is a problem or not.
>
>>
>> Again, we're happy to fix this stuff up ourselves. I just want to be
>> sure there aren't plans already in progress.
>>
>> Thanks,
>>
>> Brad
>>
>>
>>
>> _______________________________________________
>> m5-dev mailing list
>> [email protected]
>> http://m5sim.org/mailman/listinfo/m5-dev
>>
> _______________________________________________
> m5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/m5-dev
>
>
> _______________________________________________
> m5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/m5-dev
>
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
