• (cs) in reply to modifiable lvalue
    modifiable lvalue:
    The low-level languages are the first and second generation programming languages. C is a third generation programming language, described by the standard in the context of an abstract machine. C isn't a low-level language....

    The point is that it is LOWER level than a lot of other languages (e.g. the languages commonly used by the majority of people here, and in general, the majority of people worldwide, Java, C# and a variety of bullshit web related languages).

    Given the audience, it is appropriate to use the word low, because C is definitely lower than anything they've ever seen, with the probable exception of some assembler they once saw on a colleagues desk which made them poo themselves with its intimidating impenetrability.

  • foo (unregistered) in reply to Steve
    Steve:
    Many are saying that this is fine in Linux, but static array declarations are initialized to 0 in C. Won't this declaration require the OS to actually write zeros into all 64 MB?
    No, pages are 0-initialized by the OS on allocation. It needs to do this anyway to prevent data leaks.
  • instigator (unregistered) in reply to gnasher729
    gnasher729:
    And there is a slow process on the way convincing the very last retards that when you copy data at a speed of 2 Megabit per second for eight seconds, you'll have copied eight Megabyte. Not some strange number of pseudo-Megabytes.
    Not in anyway normal people think about data transfer. bps usually describes the wire. When people talk about Bytes per second, they are usually referring to the interesting data that was transferred. E.G. how fast am I downloading my file. So you would need to subtract all the overhead.
  • Kasper (unregistered) in reply to Martin
    Martin:
    You people do not understand the beauty of this because YOU DO NOT UNDERSTAND Linux.

    Linux will gladly assign you 64MB of VIRTUAL memory on a 32MB platform.

    Now if you only store 10KB worth of data on this, Linux will dirty several pages, but most of the virtual memory will not be affected! Therefore, this code will work fine unless somebody starts to increase the density of the storage, leading to using more pages than available.

    Nice to see that somebody got it right. Why is that comment not featured?

  • Norman Diamond (unregistered) in reply to foo
    foo:
    Steve:
    Many are saying that this is fine in Linux, but static array declarations are initialized to 0 in C. Won't this declaration require the OS to actually write zeros into all 64 MB?
    No, pages are 0-initialized by the OS on allocation. It needs to do this anyway to prevent data leaks.
    Static array definitions are initialized to 0 in C, unless the program specifies a different initialization. This requires the C implementation to write zeroes into all 64 MB. The C language does not require the existence of an OS or security, but it requires hosted implementations to include a library and a little bit of other stuff.

    The idea of security requires an OS to initialize pages to 0, or initialize pages to random numbers, etc. The idea of debugging requires a C implementation to initialize pages to something that wouldn't be expected by a careless programmer. But the C standard doesn't require such useful features.

    C was invented as a low level language. But the way the standard is worded, standard C became a high level language. Not very high, just enough to stop being low level where it was needed.

  • Bill C. (unregistered) in reply to Norman Diamond
    Norman Diamond:
    C was invented as a low level language. But the way the standard is worded, standard C became a high level language. Not very high,
    Yeah, it didn't inhale.

    Also it's not the size that matters, it's what gets caught handled.

  • modifiable lvalue (unregistered) in reply to VinDuv

    @VinDuv Don't confuse storage duration with linkage. Here's a quote I pulled from the C11 standard, for your benefit:

    An object whose identifier is declared without the storage-class specifier _Thread_local, and either with external or internal linkage or with the storage-class specifier static, has static storage duration. Its lifetime is the entire execution of the program and its stored value is initialized only once, prior to program startup.

  • modifiable lvalue (unregistered) in reply to eViLegion

    Someone has already mentioned Lisp machines in this comments section... Just how much LOWER level is Lisp than C?

    Consider that there are also chipsets that make execution of Java bytecode possible, without a software Java VM; The bytecode is processed by the CPU! Doesn't this make Java LOWER level than C?

    What I want to know is, on the Lisp machine, which is LOWER level: Java or C?

    A low level programming language is a programming language with very few abstractions from a specific architectures instruction set. Java was designed, like Lisp, C, C# and many other programming languages, to be portable. They're defined by standards, absent of any actual architecture.

    Having said that, there are some architectures that happen to implement one these programming languages as low level, in their context only. That doesn't impact at all upon the discussion in the general context.

    In the general context, Intel x86 assembly is not portable, though it is considered low level. Which is LOWER level: Lisp, Java or x86? Why is that? If I were to develop a virtual machine to emulate x86 on a PPC, would it still be low level? Why? Think about the definition of "low level" for a moment...

    It doesn't make sense to use the term low level in any capacity to describe a portable programming language. They are all high level, because they're described by standards absent of any actual architectures. Similarly, it doesn't make sense to use the term absolute zero to describe any temperature greater than 0°K... "But 0°F is absolute zeroer than 0°C", is what you're telling me... and it makes no sense!

  • jfb (unregistered) in reply to Nagesh
    Nagesh:
    Obvious WTF is programming in low level languages. Best stick to language like Java and you see less and less WTF every day.

    Based on some of the articles I read here...not really.

    I like the ideas of Java and C#, but the implementations of them, not so much. The lack of an unsigned integer type in Java gave me some grief when trying to decode and display DTED files on one project. Java and C# eliminate several classes of bugs found in C and C++, but introduce whole new classes of bugs in the bargain. Not a net win, in my opinion.

    And as someone who got his CS degree in the '80s, the whole argument over kilo/kibi and mega/mibi isn't just silly, it's tiresome. Whether you're using 2^10 vs 10^3 is usually clear from context. "Mega" is especially overloaded in everyday conversation; I doubt anyone argues about whether "megavitamins" contain 1000000 or 1048576 times the content of regular vitamins.

    Most of us are smart people, and can translate between units. No, we shouldn't have to, but that ship sailed a long time ago.

  • Timmeh (unregistered) in reply to alexgieg
    It is inaccurate to say HDD makers do this for marketing purposes alone, unless they were extremely prescient back when only huge corporations' technical departments (people who knew what they were doing) used to purchase MB-sized, rack-sized disk cabinets, bidding their time for the age, decades later, when clueless non-technical folk would start purchasing their stuff. That's because -- AFAIK at least -- HDDs have always been measured in powers of ten.

    Actually, it is EXACTLY for marketing reasons alone. Back in the day, hard drives were advertised based on their Base 2 capacities. For instance, Seagate advertised the ST-419 as a 15 megabyte drive. Once formatted, nominal capacity was 15,980,544 bytes (minus a little bit if there were bad sectors on the label that you had to key in.) That's 15,606KB or 15.24 "MiB". Similarly, 360KB floppy disks had a formatted capacity of 362,496 bytes.

    It wasn't until some hard drive manufacturer couldn't quite reach the big one point oh that they redefined the industry standard terminology so they could market their 953 megabyte drive as "one gigabyte."

    While that mentality has started to creep into other areas (cough, networking), you'll notice that a gigabyte of RAM is still 1,073,741,824 bytes.

  • psuedonymous (unregistered) in reply to Brendan
    Brendan:
    I agree - the idea that we could actually improve anything is just plain silly. Instead of merely being inaccurate and/or ambiguous morons, we should strive towards complete meaningless by reviving the traditions of our Neanderthal forefathers and express all measurements by the duration of grunts!

    I mean honestly, the idea of using a system of numbers is just too new and too hard. The human race used grunts without any problem for gruuuuuurrrrm years and numbers have only existed for exactly uurgh years, ug months and ook minutes.

    • Brendan
    Sure, we'll get right round to that once the US switches to SI units in line with the rest of the planet.
  • Jeff Grigg (unregistered)

    Hey; it works on my machine!!!

  • luolimao (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    Um, no, a 2 megabit ADSL line was always 2048000 bits per second
    Steve The Cynic:
    And don't forget the mighty 1.44MB floppy, which was 1.44 kilokibibytes (KKiB) (2880 = 2.88 decimal kilo of 0.5 binary kilobyte sectors). This is a different prefix to that found on the telecoms kibikilobit (KiKB).

    Bah.

    And here I was thinking that multiplication was commutative. Silly me...

  • Scott (unregistered)

    I'm Johnny come lately as usual, and as usual TRWTF is 4 pages of comments talking about MB vs MiB.

    Let's assume 1. this embedded device needed to be delivered in a hurry to perform some menial and well defined task; 2. the data occupies the table not too sparsely (not too evenly distributed); 3. the data is not on the stack (although that probably wouldn't matter much either). 4. MMU present, reasonably standard configured Linux, etc. 5. The array is not initialized or touched until it's loaded with data from the USB stick 6. This code does indeed load and execute on the device. All reasonable assumptions according to the story.

    I'm not a complete authority here, but as mentioned by a mere few here, the Linux kernel will allocate a good 4GB of address space for you to work with, regardless of how much physical RAM is available, actually pulling it from the 32MB in 4k chunks as needed. If Linux starts running out of physical memory, it'll simply sleep your process hoping some other process eventually frees up a 4k chunk it can give to your process.

    The only thing that's suspect here to me is that if the array has to be that huge, then the data is probably being put into it sparsely, and you'll ask for a lot of 4k chunks. Again, if it's not a mission critical embedded device and it's been tested and works, and has to be delivered like right-freakin'-yesterday, then I might do the same.

  • Bill C. (unregistered) in reply to luolimao
    luolimao:
    Steve The Cynic:
    Um, no, a 2 megabit ADSL line was always 2048000 bits per second
    Steve The Cynic:
    And don't forget the mighty 1.44MB floppy, which was 1.44 kilokibibytes (KKiB) (2880 = 2.88 decimal kilo of 0.5 binary kilobyte sectors). This is a different prefix to that found on the telecoms kibikilobit (KiKB).
    And here I was thinking that multiplication was commutative. Silly me...
    It is. The prefixes are different, but the result of multiplication is the same no matter which one comes first.
  • Gibbon1 (unregistered) in reply to Loren Pechtel
    Loren Pechtel:
    Pero perić:
    In the QBASIC, an ancient languages targeting 16 bit environment, one could specify an array with up to 60 dimensions. Is it even possible to use half of that (without trivial, one element dimensions) withing 64 kB?

    If you don't have trivial dimensions it's not possible to use that on any modern system, period.

    I know nothing about QBASIC. But vaguely remember reading the docs on an older version of basic where they mentioned you could define a sparse array type. So yeah it could handle an array that was 100X100X100X100X100X100X100 in a 96k address space no problem. Iterating through it would be a problem since that old machine would still be working probably.

  • Anonymous Will (unregistered) in reply to modifiable lvalue
    modifiable lvalue:
    Similarly, it doesn't make sense to use the term absolute zero to describe any temperature greater than 0°K... "But 0°F is absolute zeroer than 0°C", is what you're telling me... and it makes no sense!

    The abbreviation for the kelvin is K, not °K. As for temperature, let's agree on -40°.

  • testwithus (unregistered) in reply to Ama

    SWIFT Interview questions on

    http://testwithus.blogspot.in/p/swift.htm

    For selenium solution visit http://testwithus.blogspot.in/p/blog-page.html

    QTP Interview Questions. http://testwithus.blogspot.in/p/qtp-questions.html

    www.searchyourpolicy.com
    
  • (cs) in reply to cellocgw
    cellocgw:
    Now, then, #km^2 to mm^2 696200*1000^2 * 1000^2 # i.e. 6.962e17 mm^2

    Um... my unit converter says 1km^2 = 1e12 mm^2. One square kilometer is a square one million millimeters on a side. Where did you get 696,200 from?

  • urza9814 (unregistered) in reply to nasch
    nasch:
    cellocgw:
    Now, then, #km^2 to mm^2 696200*1000^2 * 1000^2 # i.e. 6.962e17 mm^2

    Um... my unit converter says 1km^2 = 1e12 mm^2. One square kilometer is a square one million millimeters on a side. Where did you get 696,200 from?

    Gotta follow the discussion. This whole subject has been about the land area of Texas compared to the size of a flea (hence converting to mm) -- Texas is approximately 696,200 square kilometers.

  • Riffraff (unregistered) in reply to Obviously

    A flea that size would also weigh approximately 1 million metric tons (estimated based on a square flea composed entirely of water, then rounded down. Call if 500,000 metric tons, even, that's still a whole heck of a lot.

  • (cs) in reply to psuedonymous
    psuedonymous:
    Sure, we'll get right round to that once the US switches to SI units in line with the rest of the planet.
    Most sensible comment so far.
  • blah (unregistered) in reply to Timmeh

    No. A gigabyte of RAM (as is a gigabyte of anything) is exactly 1,000,000,000 bytes.

    It's unfortunate that products are sometimes mislabeled, but that doesn't affect gigabyte in any way.

  • ares (unregistered) in reply to Nagesh

    if you approach it from the angle that the more you know about Java and its ecosystem, it reduces from thounsands of wtf's into just one: WTF are some apes so hyped up wrt. this pile of crap ???

  • Sebastian Ramadan (unregistered)
    In languages like C, they’re low level structures, which represent direct access to memory.

    No, they're not. C is a language defined in the context of an abstract (keyword: abstract) machine.

    When a processor that supports x86 protected mode is powered on, it begins executing instructions in real mode, in order to maintain backwards compatibility with earlier x86 processors. How many C implementations do you know that require switching from real mode to protected mode before they can make use of more than 1MB of memory?

    Very few. Even if a C implementation were built to run the moment control is passed over by the BIOS, the implementation would most likely handle this for you, much like most OSes would. In addition to this task, OSes that implement C tend to implement paging and virtual address spaces. When your C program modifies the value (say, in an array) pointed to by the virtual address 0x2000000, your OS translates that virtual address to a physical address...

    TRWTF is using "C" and "low-level" in the same sentence.

Leave a comment on “It's not the size that matters”

Log In or post as a guest

Replying to comment #:

« Return to Article