If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
#61
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
"Paul" wrote
| On the other hand, I'm self taught and could | probably never cooperate with a group myself. | I always understand "willing to be a team player" | as code for "expect to be an abused lackey if | you work at our company". So I guess I'm not | very modern myself. | | Don't knock a work dynamic, until you've tried it. | I've worked on "teams". Though it's been many years. I've been self-employed for a long time. What I know of teams is pecking order. Some people are leaders. Some are followers. Both work well in teams. Both *need* to have that structure. Some are independents. They tend not to work well in teams. As one of those I also don't tolerate pecking order and don't like to hire people who can't take care of themselves and be solely responsible for their work. Either way is OK. As Mr. Eastwood said so well: "A man's just *got* to know his limitations." But I don't accept the idea that teams are "modern". To a great extent they're just a psychological scam of subservience; a euphemism, encouraging people to accept lackeyhood and consider self-interest to be a failing, dedicating themselves to their work far beyond what their pay warrants, partly as devotion to their team. As dedication to "something greater than themselves". Soldiers often talk like that. What gets them to go to the field of mass murder where they're likely to be killed, and to stay there? It's insanity. There's no reason. No one in their right mind would do it. But through patriotism or naivety or sense of adventure or ambition they ended up there and they're stuck. So they do it for their comrades. Anyone who's worked for a large corporation knows the kind of exploitation that's passed off as dedication and not letting the team down. This from Salon.com: "When in December 2012 the Ver.Di representatives in Leipzig called on the management of Amazon's local center to open negotiations on wage rates and an improvement of working conditions, and especially for temporary workers who are badly exploited at Amazon, management refused on the grounds that employees should be "thinking about their customers" and not about their own selfish interests." |
Ads |
#62
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
Richard Kettlewell
Thu, 18 Jan 2018 13:10:01 GMT in alt.windows7.general, wrote: Diesel writes: "Mayayana" news alt.windows7.general, wrote: That would depend. A basic compiled executable (as opposed to .Net, Java, scripting, etc) is compiled to native or machine code -- the actual CPU operations. Actually, most of the time, with the exception of a select few compilers; that's not the case. They compile to pseudo machine language with a runtime present inside the executable that performs the low level translation work. There are some exceptions to this, but the more well known compilers are not taking your c/c++/basic source code and translating it verbatim to machine code inside your executable. Which C/C++ compilers do you think do this rather strange thing? A moment with a disassembler will reveal that GCC, Clang and MSVC do not. Rather strange thing? MSVC certainly does include a runtime...I'm not familiar with Clang, and, my experience with gcc is Linux based, and so rather limited; aside from the few samples I've compiled so far aren't static and require the dependencies to be present to execute... I haven't played with the windows gcc version, so couldn't tell you if it does/doesn't provide additional code inside your executable to deal with various functions that wasn't purely translated to machine code. By pure, I'm talking about assembler to machine code or vice versa here. IE: no runtime. Which also means, if your assembler program has an issue, unless you wrote in error handling routines as well, the crash can be spectacular. If one occurs. I may not have been clear enough in my previous text. So, I'll attempt to fix that, or, sadly, make it worse with this reply. What I meant was that many compilers available to the would be programmer/coder are not taking your source code and translating it to native machine code. There's usually some overhead involved, hence the runtimes. Where as there isn't with pure asm. The result is that although you can typically write the program in an HLL faster, the resulting exe is going to be bigger and consume more resources than it otherwise may have had you written it in pure asm, or machine code instead. I don't find this to be a strange aspect myself, I just consider it part of doing business when using a typical HLL. -- To prevent yourself from being a victim of cyber stalking, it's highly recommended you visit he https://tekrider.net/pages/david-brooks-stalker.php ================================================== = Gravity brings me down |
#63
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
"Mayayana" news
Thu, 18 Jan 2018 14:20:37 GMT in alt.windows7.general, wrote:
"Diesel" wrote | That would depend. A basic compiled executable | (as opposed to .Net, Java, scripting, etc) is compiled | to native or machine code -- the actual CPU operations. | | Actually, most of the time, with the exception of a select few | compilers; that's not the case. They compile to pseudo machine | language with a runtime present inside the executable that | performs the low level translation work. You mean like a python program? I'm talking about compiled software. Compiled to native code. No, those are interpreted languages. I was writing about compiled ones. Take visual basic for example, your language of choice If i'm not mistaken. It has a runtime embedded into your executable, OR, depending on compiler switches, provides a very very small one, but then depends on dlls to be present on the host. Many have "runtimes". All of the VC++ versions have runtimes. But those are companion function collection libraries, also compiled to native code, not interpreters. Yes, they do. Where as pure asm does not. It has no need for a 'runtime' as the code you wrote in assembler was translated byte for byte into machine code;exluding header details as that's for the OS to properly load and execute the following machine code. This has it's drawbacks though, of course. The runtime is also your error handler...It tells your executing program such and such function didn't do as you expected and sets the error condition for you to read. So that whatever you wrote it to do in the event it, couldn't say find a file, prompts the user. Where as in pure asm, unless you specifically check the error flag yourself, you don't know the i/o call you just made failed. Unless you have code down the line that checks to see for the files existance and acts accordingly when it doesn't find it. Case in point, I can't take your vb code as is and translate it directly to machine code; it has some overhead in the way. With a pure asm source code, I actually can convert that to straight machine code and vice versa. It's how a disassembler works, infact. It's able to read the bytes of the file and depending on what they are, show you the assembler it represents. Assembler and machine code have that bond where as an HLL language typically does not. Interpreted languages are another critter, with a lot more overhead; they literally have the interpreter itself included with the pseudo code they 'compiled' for you to execute them. I've seen one funky basic like language that when it compiled your source code, literally generated a fresh exe of itself with your own source code appended to the end section. So when ran, instead of the ide, it interpreted and executed your source code below. Which turned a simple hello world program into 100Kilobytes or so. I realize size/resource consumption isn't as important with modern machines, and some programmers don't even consider those factors anymore, but... I'm old school in the sense, if I know I can do the same thing in 5kilobytes or less, I'm going to. I see no reason for my executables to be bigger and consume more resources than is necessary for them to do what I wrote them to be doing. It's an old habit, granted, from my first computers where space/resources weren't plentiful and if you wrote large programs, you had to keep that in mind. | Looking at inspectre.exe, it contains a digital | signature and it's marked as compressed with UPX. | Decompressing and reading the bytes indicates | that there's embedded RTF text that gets loaded | into a RichEdit window. Not likely to be done with | assembly. Even if it's possible it wouldn't make | sense. | | Native win32 assembly can also make full use of Win api | functions; In fact, you're encouraged to do so. Yes, but why? He's making a GUI program that uses a Richdit window, 3 system button windows, and RTF text. Why not use a tool designed to do that more easily and save the low level code for things that require low level? I can use an old fashioned hand drill to drive drywall screws, at least in theory, but it's going to take an awfully long time. I could learn to start a fire by rubbing sticks together. I could refuse to use "lazy", "high level" technologies like running water and gas stoves and electric lights. And of course, some people do that. It might be an interesting experience or an impressive discipline, but not necessarily the best way to spend one's time. -- To prevent yourself from being a victim of cyber stalking, it's highly recommended you visit he https://tekrider.net/pages/david-brooks-stalker.php ================================================== = I do not know whether I was then a man dreaming I was a butterfly, or whether I am now a butterfly dreaming I am a man. |
#64
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
"Diesel" wrote
| No, those are interpreted languages. I was writing about compiled | ones. Take visual basic for example, your language of choice If i'm | not mistaken. It has a runtime embedded into your executable, OR, | depending on compiler switches, provides a very very small one, but | then depends on dlls to be present on the host. It has an external runtime, msvbvm60.dll, but like the VC++ runtimes, it's something like a function kit or toolbox. The EXE is compiled to native code. | Yes, they do. Where as pure asm does not. It has no need for a | 'runtime' as the code you wrote in assembler was translated byte for | byte into machine code You could say that, but both are native code. The assembly-written executable that creates a RichEdit window and system buttons and calls the Registry is using system DLLs. Unless it *only* makes direct calls to CPU registers to make calculations unrelated to anything external then it has dependencies. My VB6 EXE is the same in that respect: It depends only on DLLs that are on virtually all Windows machines. But it takes about 1 minute to make a button, rather than 2 hours and 2 pages of code. | The runtime is also your error handler...It tells your executing | program such and such function didn't do as you expected and sets the | error condition for you to read. That depends on what function I called and where it's coming from. If your asm and my VB both call RegCreateKeyEx in advapi.dll then we're both getting our error messages from the same place. I think that's my point: For Win32 API and GUI there are much easier ways to go about it than assembly. I'm not criticizing using it. I'm just questioning using it as the main tool to write software on a modern operating system. | Interpreted languages are another critter, with a lot more overhead; The reason I wondered if you were thinking of Python is because that's one example of a language that allows embedding the support files. |
#65
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
Diesel writes:
Richard Kettlewell Diesel writes: "Mayayana" Actually, most of the time, with the exception of a select few compilers; that's not the case. They compile to pseudo machine language with a runtime present inside the executable that performs the low level translation work. There are some exceptions to this, but the more well known compilers are not taking your c/c++/basic source code and translating it verbatim to machine code inside your executable. Which C/C++ compilers do you think do this rather strange thing? A moment with a disassembler will reveal that GCC, Clang and MSVC do not. Rather strange thing? MSVC certainly does include a runtime... I’m talking about “compile to pseudo machine language”, not the presence of runtime libraries. The output is machine code, there is no “pseudo” about and it no further translation step; the CPU executes it directly. -- https://www.greenend.org.uk/rjk/ |
#66
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
Richard Kettlewell wrote:
Diesel writes: Richard Kettlewell Diesel writes: "Mayayana" Actually, most of the time, with the exception of a select few compilers; that's not the case. They compile to pseudo machine language with a runtime present inside the executable that performs the low level translation work. There are some exceptions to this, but the more well known compilers are not taking your c/c++/basic source code and translating it verbatim to machine code inside your executable. Which C/C++ compilers do you think do this rather strange thing? A moment with a disassembler will reveal that GCC, Clang and MSVC do not. Rather strange thing? MSVC certainly does include a runtime... I’m talking about “compile to pseudo machine language”, not the presence of runtime libraries. The output is machine code, there is no “pseudo” about and it no further translation step; the CPU executes it directly. According to Wiki, it's the syntax which isn't quite standard by default. https://en.wikipedia.org/wiki/GNU_Assembler "Those more accustomed to writing in Intel syntax have argued that not supporting the Intel syntax for assembly on the x86 and x86-64 platforms, as many other assemblers do, is a flaw. However, since version 2.10, Intel syntax can be used through use of the .intel_syntax directive. " This article isn't all that helpful. https://en.wikipedia.org/wiki/Intel_syntax But the comparison table here, shows the differences. https://www.ibm.com/developerworks/l...asm/index.html Paul |
#67
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
Paul writes:
Richard Kettlewell wrote: Diesel writes: Richard Kettlewell Diesel writes: "Mayayana" Actually, most of the time, with the exception of a select few compilers; that's not the case. They compile to pseudo machine language with a runtime present inside the executable that performs the low level translation work. There are some exceptions to this, but the more well known compilers are not taking your c/c++/basic source code and translating it verbatim to machine code inside your executable. Which C/C++ compilers do you think do this rather strange thing? A moment with a disassembler will reveal that GCC, Clang and MSVC do not. Rather strange thing? MSVC certainly does include a runtime... I’m talking about “compile to pseudo machine language”, not the presence of runtime libraries. The output is machine code, there is no “pseudo” about and it no further translation step; the CPU executes it directly. According to Wiki, it's the syntax which isn't quite standard by default. Totally irrelevant to the object code. -- https://www.greenend.org.uk/rjk/ |
#68
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
On Sat, 20 Jan 2018 10:58:23 +0000, J. P. Gilliver (John) wrote:
Of course the splitting into modules, with properly-defined interfaces, could be seen as an element of high-level language (-:. Or as an element of assembler. Some sort of "call" instruction was a feature of every assembly language, as far as I know. With Univac assembly language in the 1960s, it was LMJ, "Load modifier and jump". The arguments were an index register (conventionally B11 or X11, though not necessarily -- hence the uber- geek license plate "LMJ B11") and the address of the subroutine. The effect was to load the address of the instruction following the LMJ into that register, and transfer control to the subroutine. At the end of its code, the subroutine would do an indirect jump to the address in the register, corresponding to a "return" in higher- level languages. I can't remember whether there was a specific instruction used for returns in Univac assembler, or just the regular jump instruction, and a quick review of the instruction set[1] doesn't bring it to mind. [1] https://www.fourmilab.ch/documents/u...tructions.html -- Stan Brown, Oak Road Systems, Tompkins County, New York, USA http://BrownMath.com/ http://OakRoadSystems.com/ Shikata ga nai... |
#69
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
In message , Stan Brown
writes: On Sat, 20 Jan 2018 10:58:23 +0000, J. P. Gilliver (John) wrote: Of course the splitting into modules, with properly-defined interfaces, could be seen as an element of high-level language (-:. Or as an element of assembler. Some sort of "call" instruction was a feature of every assembly language, as far as I know. [] At the end of its code, the subroutine would do an indirect jump to the address in the register, corresponding to a "return" in higher- [] (From what I remember, "gosub" and "return" were among the assembly opcodes of any processor I ever used - 6800, 6502, 2901-style bit-slice, 96000 DSP, TMS320xxx DSP, and probably others.) I was thinking of more formalised parameter-passing: in modular code design, it would be normal for the job administrators to lay down how parameters are to be passed to/between modules, by placing them in agreed registers, or even agreed blocks of memory for larger parameters/numbers of parameters. With a later optimisation stage that removed any case where such setting-up and unloading was not necessary where code blocks talked only to one other code block, _if_ such optimisation was necessary/cost-effective. -- J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf I admire him for the constancy of his curiosity, his effortless sense of authority and his ability to deliver good science without gimmicks. - Michael Palin on Sir David Attenborough, RT 2016/5/7-13 |
#70
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
On 20/01/2018 22:57, Diesel wrote:
I may not have been clear enough in my previous text. So, I'll attempt to fix that, or, sadly, make it worse with this reply. worse :P What I meant was that many compilers available to the would be programmer/coder are not taking your source code and translating it to native machine code. There's usually some overhead involved, hence the runtimes. Where as there isn't with pure asm. The result is that although you can typically write the program in an HLL faster, the resulting exe is going to be bigger and consume more resources than it otherwise may have had you written it in pure asm, or machine code instead. The output of HLL compilers (except a few, such as Java and C#) is native machine code. No more, no less. If you are writing in assembly you have the option _not_ to link in standard libraries that do helpful things like parse the command line options and initialise a heap before entering the code of your program. But once you are in that program (main, for C programs) you are running the exact machine code that was generated by the compiler. Heck, when you load an EXE on Windows all it does (sometimes) is map the code section into virtual address space. It doesn't even read it until a page fault happens. Andy -- Sometimes? That's complex... |
#71
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
Vir Campestris wrote:
On 20/01/2018 22:57, Diesel wrote: I may not have been clear enough in my previous text. So, I'll attempt to fix that, or, sadly, make it worse with this reply. worse :P What I meant was that many compilers available to the would be programmer/coder are not taking your source code and translating it to native machine code. There's usually some overhead involved, hence the runtimes. Where as there isn't with pure asm. The result is that although you can typically write the program in an HLL faster, the resulting exe is going to be bigger and consume more resources than it otherwise may have had you written it in pure asm, or machine code instead. The output of HLL compilers (except a few, such as Java and C#) is native machine code. No more, no less. If you are writing in assembly you have the option _not_ to link in standard libraries that do helpful things like parse the command line options and initialise a heap before entering the code of your program. But once you are in that program (main, for C programs) you are running the exact machine code that was generated by the compiler. Heck, when you load an EXE on Windows all it does (sometimes) is map the code section into virtual address space. It doesn't even read it until a page fault happens. Andy Run a compiler and see. In the following exercise, I went to my build VM that has mingw in it. ******* gcc -o filename.exe filename.c -lcomdlg32 Not shown in the trace, is gcc calling the constituents. I wanted to collect as much as possible in one picture, so didn't include all of that. Neither did I try to copy and paste all the relevant shell commands that might have been emitted. This picture is just a teaser to get you interested. There are actually some other EXEs that ran, from the GNU folder, but we don't need to list or spell out what they're doing for a simplified overview. The nice thing about using ProcMon, is if you need to know what happened, I can send you the entire trace, with everything in it. https://s13.postimg.org/ji8a5amvr/compiling.gif In the example photo, gcc calls cc1 first. cc1 takes filename.c and makes %temp%\ccPlc7wC.s That .s file is assembler code with ADD, JMP, MOV etc. It's a text file anyone can easily read. It looks like "an assembler guy wrote it". You'd recognize it immediately if you saw a sample. You can even ask the compiler to "stop" at the assembler source code generation step if you want. Next step, is "as.exe" the GNU assembler, takes %temp%\ccPlc7wC.s and makes %temp%\ccc6dCLM.o That is object code. That's a binary, perhaps with a PE32 header. Compilers actually make different kinds of binaries, such that only gdb can debug gcc object, while windbg can debug Visual Studio object. But the twain shall not meet. Now, because I asked the compiler to please include a system library, I need linking. The GNU ld.exe program takes ccc6dCLM.o plus some object file of a similar nature representing "comdlg32" and makes my final, presumably statically linked filename.exe. Since filename.exe is large compared to the other files, it takes quite a few writes to finish it. Comparatively speaking. So the steps in the example are compiling, assembling, linking And the steps can be done piecewise to, as you'd see in various makefiles. The reason you could get away with just compiling, assembling is the executable calls msvcrt at runtime, for the runtime portion of the environment. In Cygwin, the runtime is two files. Presumably Visual Studio has one or more runtimes as well (sometimes you're required to download and install particular versions or flavors). Dynamic linking to a runtime, gives all the "standard" C calls, as an example of what might be in there. So even when a gcc command line doesn't appear to link anything, when the program runs, it does "suck in stuff". Paul (who is definitely *not* a software developer...) |
#72
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
"Mayayana" on Thu, 18 Jan 2018 23:13:13
-0500 typed in alt.windows7.general the following: I think we're all getting too old. This is turning into one of those long threads where all the geezers jump in: My first computer was an abacus.... That's nothin'. We had an abacus made with stones, and they slid uphill both ways.... Oh yeah, I remember that. My boss made me chip and polish the stones myself.... You had an abacus?... You had stones? All we had was primordial soup. -- pyotr filipivich Next month's Panel: Graft - Boon or blessing? |
#73
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
"pyotr filipivich" wrote
| You had stones? | | All we had was primordial soup. You probably shouldn't tell people that. They might call you a slimeball. |
#74
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
On 2018-01-21 04:50, Paul wrote:
According to Wiki, it's the syntax which isn't quite standard by default. https://en.wikipedia.org/wiki/GNU_Assembler "Those more accustomed to writing in Intel syntax have argued that not supporting the Intel syntax for assembly on the x86 and x86-64 platforms, as many other assemblers do, is a flaw. However, since version 2.10, Intel syntax can be used through use of the .intel_syntax directive. " Intel syntax is broken, I always have trouble handling it - who besides Yoda says "Move into the box this item" ? -- ! _\|/_ Sylvain / ! (o o) Memberavid-Suzuki-Fdn/EFF/Red+Cross/SPCA/Planetary-Society oO-( )-Oo Always proofread carefully to see if you any words out. |
#75
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
On 01/21/2018 9:42 PM, B00ze wrote:
On 2018-01-21 04:50, Paul wrote: According to Wiki, it's the syntax which isn't quite standard by default. https://en.wikipedia.org/wiki/GNU_Assembler *** "Those more accustomed to writing in Intel syntax have **** argued that not supporting the Intel syntax for assembly **** on the x86 and x86-64 platforms, as many other assemblers **** do, is a flaw. **** However, since version 2.10, Intel syntax can be used **** through use of the .intel_syntax directive. *** " Intel syntax is broken, I always have trouble handling it - who besides Yoda says "Move into the box this item" ? "Throw the cow over the fence some hay" :-) Rene |
Thread Tools | |
Display Modes | Rate This Thread |
|
|