Contribute
Register

Native DSDT/AML IDE & Compiler: MaciASL Open Beta

Status
Not open for further replies.
Like SJ already mentioned, Apple only uses the 4.0 specification so compiling to 5.0 specs does not do anything for you, you don't gain anything by using the 5.0 compiler.
 
Looking into the help output of the iasl4 version (included in MaciASL) reveals:
Code:
-e  [f1,f2]    Include ACPI table(s) for external symbol resolution
This isn't a new feature. Its a requirement for a correct disassembly.

Honestly, I didn't notice anything bad yet after not including SSDTs.
I suspect it might produce malfunctions in some cases, especially when the DSDT relies on many external methods.
 
I tested external resolution a long time ago when I first started and couldn't find any differences. Testing again today still finds no changes.
There are a few issues here, the first being that resolving the table dependency is very difficult for the app to do on its own (is this a draft DSDT?, is it for a different machine?, should it use the system SSDT or the one that was just created and not yet saved?, etc). This is already complex when trying to handle both Chimera and Clover injection (Clover support coming in beta #3), and might be impossible if trying to resolve an SSDT as well. Most document-based apps are meant to have their documents stand alone, without dependencies, and asking the user for each compile, or trying to work up some kind of dependency expression would make it too complex and error-prone.
The second issue is that while SSDTs themselves are content-agnostic (they can contain any kind of addendum necessary for the DSDT), Apple uses its SSDT in a very specific way (for CPU power management), which makes the possibility of an issue rarer. So long as DSDTs and SSDTs made for OSX have this well-defined layout, the most that is necessary in some cases is DropSSDT=Yes in Chimera.
Finally, if you are afraid of an issue extract your DSDT and SSDT, then decompile once `iasl -d DSDT.aml` and again `iasl -e SSDT.aml -p DSDT1 -d DSDT.aml`, then `diff -u DSDT.dsl DSDT1.dsl` and see if you find any differences besides the header.

I have added code folding as a TODO, but that will probably take a long time. I have avoided any solutions which required actually drawing onscreen because of the possibility for memory and drawing errors, in fact you may have noticed that the line numbering is really just a ruler with the correct scale. This is because the ruler is a feature provided by Cocoa which doesn't require writing your own drawing method; the drawing, memory management, and releasing are all handled by the framework, and even then it draws incorrectly from time to time. I doubt my subclass would perform as well or with the same amount of memory. Staying away from CG drawing keeps the number of possible issues low, and lets me focus on the mechanics of features, not appearance.
 
sorry about the wait, I've been trying to compile Clover using clang, and getting nowhere; it looks like we're stuck with GCC 4.7.
At any rate, the newest iasl5 is now up and will be included in the next beta. In the meantime just use Preferences > iASL > Update iASL to download the new version. Once the download is complete the "info" section will update. As always I recommend using ACPI 4.0 instead.

SJ, please, can you explain the differences between iasl4 and iasl5?
When I use Preferences > iASL > Update iASL to download the new version, it appear the compiler summary window with this result: 1 errors, 0 warnings, 0 remarks.
Obviously it doesn't update the iasl.
Any suggestion?

Thanks!
 
  1. whenever you change the current compiler, it must recompile all open documents to maintain the accuracy of the summary
  2. iasl4 is the 4.0 compiler (see Current Compiler for details), and iasl5 is the newest 5.0 compiler
  3. Update iASL updates both compilers, and is modal (hangs) until the download is complete, to prevent incomplete downloads and other corruption
I just tested Update iASL for 4 and 5, and both are working though perhaps a little slow because of SourceForge. Current Compiler will reflect the update once it is complete.
 
Just the external definition changes, in case you meant this part with header.

iMac13,1 has its own SSDTs for the IGPU, GFX0, HDEF section and SATA for instance. It's not just CPU PM.
My Asus has got an SSDT SATA section, too.
In contrast to Asus, Apple keeps the power management methods for SATA in the respective SSDT.
All in all it looks much more organised, you are right.

What about generation of a device map with their addresses for a quick overview?
The current device tree is oriented on the code flow.
Apple structures their DSDTs well. The other ones look like a mess.
This shouldn't be too hard to implement either.

EDIT:
I hope I don't bother you too much with my posts.
I really like your app and the way it is going and just want to propose some hopefully useful features for everyday work with it.
 
pike, IB CPUPM is being actively worked-on by other people, and was at least partially addressed by the last update where SSDT generators are now supported. If you intend to fork revogirl's script, I suggest you use the new mechanism instead of posting scripts to this thread, complicating things needlessly. If you really want to post the script, do it in another thread.
 
I was under the impression that you were using my sisters script, due to this piece of text: "SSDT generation using revoGirl's script". But correct me if I am wrong, in which case I apologise for the confusion.

Note that I am one and only maintainer of just about everything she left behind, and thus I thought to do well by adding an update to her script here. But if that isn't appreciated, then please stop using her work.
 
my point is version 0.9 is what most expect, and what I've done is to extend it infinitely by allowing patching and generation of the APSS. If you read back, I've said (and I believe this), that it isn't appropriate to store new changes to the "script" in the binary, it's the wrong place for it. If you wish to extend it, either post the script somewhere else so others can comment on it and reach consensus as a separate process, or use my method to modify the generated script in a more flexible and possibly future-proof way. I have solidified the basic SSDT generator as a translation of v0.9, and I can't keep updating the app as you or others modify it, it's bad practice and bad programming. I will as always be providing attribution to revogirl in the text of the generated SSDT.
 
I looked at the source code and now I understand your point of view. Please accept my apology.

Note that I wasn't aware of all this, so I was rather surprised. Anyway. Good job. Well done. And yes. Point taken.

-Pike
 
Status
Not open for further replies.
Back
Top